'don't ask, tell' feasble for services ?

[emaayan]

i keep reading in mock artible how one should not use getters for objetcs like for example instead of

dog.getBody.getTail();

one should do

dog.wagTheTail

however it occurs to me this the is a wrong seperation of concerns here, becouse as i see it, you have a division of model beans (dog,body etc..) and a division of services performing actions on said beans, such services, that are maybe created by spring, and that wagTheTail method should actually belong to K9Activties class, a buisness services class.

another issue with a mock article i read, also states that creational activities should not appear in the method performing buisness logic, but should be seperated into a single metod (which could be overidden later for mock tests) rather then being transfered for factory object which may complicates matters.
while i agree that they should not appear in the method itself, i believe that they SHOULD appear in factory objects, as i see them as infrastructure usage, not logic.
just as there CRUD for data, there is CRUD for objects, we allready have DAO patterns performing abstractions for persistence, and basically what we do with object persistence is that we tell the application to either save, load or delete it, how and to where is not an issue, we could save it to db/file/xml or load it from a file etc..,doesn't matter. what is creational stuff if not basically making room in memory for objects, how we would it shouldn't matter, it's just another CRUD operation, so like a DAO class collabrator which handles objects into data, a factory objects should be treated the same.

a pure businsess method should in my view be something like :

public void Process(DataInteface interParamter){

Model model= inter.getrelvantData
if (model.shouldCreateNew)
newObject= creationalCollabrator.createNewObject();
newObject.setName=model.getName();
persistenceCollabrator.save(newObject)

}

[manifoldronin]

Why shouldn't a dog wag his own tail - both literally and metaphorically? The "Master grabs Bobby's tail and shakes it" kind of design leads right into an anemic domain model, and is not a proper separation of concerns. The concerns proper for the service layer would be things like "nobody tries to grab Bobby's tail when he wags it" (transaction), "only I can see Bobby wagging his tail" (authentication), and "Bobby wags tail along with the other 3 puppies" (collaborative logic).

[tatvamasi]

Why shouldn't a dog wag his own tail - both literally and metaphorically? The "Master grabs Bobby's tail and shakes it" kind of design leads right into an anemic domain model, and is not a proper separation of concerns. The concerns proper for the service layer would be things like "nobody tries to grab Bobby's tail when he wags it" (transaction), "only I can see Bobby wagging his tail" (authentication), and "Bobby wags tail along with the other 3 puppies" (collaborative logic).

Wait a minute! isn't "don't ask, tell other guy" is one of the fundamental principle of OO? I wonder how it leads to Anemic domain model (whatever that is! or say "my $$)?

[manifoldronin]

IIUC, "tell, don't ask" only says - in this context - to give the dog what he needs to be able to wag the tail, but not wag it for him.

[tatvamasi]

IIUC, "tell, don't ask" only says - in this context - to give the dog what he needs to be able to wag the tail, but not wag it for him.

sure but dog has to tell "something" to wag it for him as a dog. its like dog can wag his tail but tail also can wag itself. so who is responsible for wagging?

[manifoldronin]

sure but dog has to tell "something" to wag it for him as a dog. its like dog can wag his tail but tail also can wag itself. so who is responsible for wagging?

It depends on at which level the question is asked. If you are presenting a tail-wagging dog to people for 5 bucks a show, to your patrons, you are responsible for wagging your dog's tail. But - and this is the essential distinction - that does not mean you have to grab the dog's tail and wag it yourself. Your tasks would include setting up a proper environment for your dog to wag his tail in, and signal him to do so when everybody is ready. At that point, the dog is responsible to you for wagging the tail. Then, the dog "tells", or coordinate, whatever muscles necessary to wag the tail.

[tatvamasi]

It depends on at which level the question is asked. If you are presenting a tail-wagging dog to people for 5 bucks a show, to your patrons, you are responsible for wagging your dog's tail. But - and this is the essential distinction - that does not mean you have to grab the dog's tail and wag it yourself. Your tasks would include setting up a proper environment for your dog to wag his tail in, and signal him to do so when everybody is ready. At that point, the dog is responsible to you for wagging the tail. Then, the dog "tells", or coordinate, whatever muscles necessary to wag the tail.

So if Dog "tells" muscles to wag the tail, at that point muscle really has no behavior but has only attributes (Anemic domain model perhaps?). in order to avoide the duplication of the behavior, either dog has behavior or muscle has. so now if master wags the tail for dog or dog wags tail for mucle or muscle wags itself, does not make a difference. at some point and time your domain model has to carry stateless services. Well I think so, I am not sure what do you think.

[manifoldronin]

So if Dog "tells" muscles to wag the tail, at that point muscle really has no behavior but has only attributes (Anemic domain model perhaps?). in order to avoide the duplication of the behavior, either dog has behavior or muscle has. so now if master wags the tail for dog or dog wags tail for mucle or muscle wags itself, does not make a difference. at some point and time your domain model has to carry stateless services. Well I think so, I am not sure what do you think.

I'm not sure what you meant by "your domain model has to carry stateless services." My understanding is, each muscle would maintain its own state, and provides behavioral methods for the state to be changed. For the sake of the discussion, let's say Muscle has a method called twitch(), which allows to change the contraction state for this muscle for a given amount. The Dog would have a wagTail() method that wags the tail by twitching a number of its Muscle instances with various contraction values.

On the other hand, in an architecturally nightmarish scenario of the anemic domain model, the Muscle would only have a setContraction() method that in a pass-through manner changes the muscle contraction value, and the Dog would only have a getAllMuscles() that simply returns a List of Muscles. In order to wag the tail, The Master would get the instance to the Dog, then gets the full collection of the Dog's Muscle instances, iterates through them, figures out which one needs to twitch for how much, and imposes the values onto the Muscles.

I called it nightmarish because, a few contractors and a couple of interations of new requirements (such as "let's make the Cat wag her tail too") later, the Master usually ends up a God class with a million type checking branches.