MyObject.DoSomething() vs MyService.DoSomething(MyObject)

Question

Is one better than the other?

Is that even a valid question?

I've been advised recently that the MyObject.DoSomething() is quite dated and the service way of doing it is preferred. Is that right?

Example:

public class Policy : ICancellable
{
    public void Cancel()
    {
        // Code to cancel working with 'this'.
    }
}

vs

public class PolicyCancellationService
{
    public void Cancel(Policy policy)
    {
        // Code to cancel working with 'policy'.
    }
}

If the service way of doing it is used - can the object be responsible for any functionality or should it just be dumb?

Answer 1

I've been advised recently that the MyObject.DoSomething() is quite dated and the service way of doing it is preferred. Is that right?

Both ways are valid; you should choose whichever leads to high cohesion and low coupling.

As a rule of thumb, you should begin by trying to put it in the class itself, i.e. MyObject.DoSomething().

You should only use a separate (service) class if:

• the functionality of DoSomething does not directly relate to the responsibility of MyObject. If you put an unrelated method into MyObject, it leads to low cohesion.
• MyObject does not have all the information required to perform DoSomething. If you give this additional information to MyObject, it leads to high coupling.

In your example, if cancellation is an important feature of a policy and the policy has all the required information to perform this operation, you should keep it in the Policy class.

If the service way of doing it is used - can the object be responsible for any functionality or should it just be dumb?

Quite the contrary: you should keep as much functionality as possible in the domain objects themselves. Services should be limited to coordinating activities between multiple domain objects; they should preferably not contain any business logic.

Answer 2

Perhaps the most significant argument for calling it Service is that inter-process communication tends to be slow, and this is usually what is meant by using a service. If not managed correctly, this may lead to chatty interfaces with poor performance.

So it is good to model this boundary explicitly, which will make people aware of possible issues which are present when calling external service, and so they will make better decisions of when to call the service.

Now if the logic has no external dependencies, I would probably leave it inside the object, and not call it "service" altogether.

Answer 3

I think in my opinion the first approach you are using is around main of OOP principals like abstraction, encapsulation and etc.

However, the second approach is focusing on design changes principals to allow easier rebuild/retest and redeploy of applications such as interface segregation, dependency inversion and etc.

In my opinion, There is not outdated way of which methods are preferred.