Sorry if my (simplified) example is too broad.Given this model (written in C#):class Ball{}Let's assume that a ball can be launched.To implement this feature, I can define something like:class Ball{    void Launch();}or something like:class BallLauncher{    void Launch(Ball ball);}In which situations is better use first approach and which the second one?In fact, this example tries to simplify an actual real underlying model. In that model, I need to upload files (Package) to a repository.Then, I don't know if the repository should upload (physical copy) a package (files) to itself or it is the package who should upload itself to a repository.
Design of active or passive class domain
domain driven design
Basic example: launch a ballAnalyzing business logic helps. Can the ball possibly launch itself? Probably not. It's just a ball, and can't move by itself. This means that you'll create a BallLauncher in order to launch it.What would Ball class contain? Mostly properties of the object, such as radius, color and texture.Two objects example: launch a rocketA Rocket may be launched itself, or may require a launcher. Sometimes, looking at the logic, it may not be obvious where to put the method. A rocket is not passive, but may need a launcher. A launcher is required to launch a rocket, but the rocket participates in the launching as well.When the logic is not obvious, here's a hint: implement the Launch method and watch how Rocket and Launcher are used.Example:class Rocket{    public void Launch()    {        this.ControlTower.RequestTakeoff().WhenAuthorized(launcher =>        {            launcher.Prepare();            if (launcher.Status == LauncherStatus.ReadyForLaunch)            {                launcher.Launch();                launcher.PrepareNewRocket();            }            else            {                throw new BrokenLauncherException();            }        });    }}over-relies on Launcher and should be moved to Launcher class. On the other hand:class Launcher{    public void Launch(Rocket rocket)    {        rocket.Ignite();        rocket.IncreasePressureTo(Rocket.RecommendedPressureOnLaunch);        rocket.PrepareForTakeoff();        if (rocket.IsReady)        {            this.Release();            rocket.Takeoff();        }        else        {            rocket.CancelTakeoff();            rocket.Engines.ShutDownEmergency();            throw new BrokenRocketException();        }    }}is illustrative of a method which finds itself in a wrong class: it should be moved to Rocket.Three objects example: package, repository, uploaderIn the same way, if you have a Package and a Repository:Should the package be uploaded to a repository,Should a repository upload a package to itself,Or should there be an Uploader which deals with packages and repositories through Upload(package, repository)?Again, business logic prevails, and as in the previous example, watching how Package and Repository are used inside the method may help.If Upload over-relies on Package, this may be a hint that it should be Package.Upload.If Upload calls the methods from Repository practically all the time, move it to Repository.If Upload has a logic which simply doesn't fit in Package or Repository, this is a good opportunity for creating an Uploader.