|P is for Practical|
Comment onby gods
|on Feb 11, 2000 at 00:06 UTC||Need Help??|
Do you define "predicate function" here as "method that returns a boolean value"? If so, then it reveals something about the object state- information that should be encapsulated.
What if you decide that "you can always send!". Then you have to remove the conditionals from all clients of your object. Or what if there are now 3 states for sending, each requiring a different send method? We want the clients to know as little as possible about the object. Knowing only one method, is better than knowing a method, its return type, and another method.
"...The key question is: How much of one module must be known in order to understand another module?..."
Yourdon, Ed and Larry L. Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. (1979) On Coupling, p.85
Breaking encapsulation here increases coupling between the clients of the object and the object itself. Note I am not saying: never use boolean methods. There may be other design forces besides "encapsulate hermetically", so we do not know which solution is best here.
Code like: "if an object can do this, tell it to do it" smells.
In reply to Re: Re: Re: Short Refactoring Tip: let the object do it for you