Re: Re: Re: Re: Short Refactoring Tip: let the object do it for you

[dws]

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.

A predicate method (or a query method, for that matter) defends encapsulation. The existence of the method says nothing about how the target object derives an answer. It could have the answer in a hash, it could calculate it lazily, it could delegate to another object. Whatever. The point is that the client doesn't know. Coupling is kept down. And, assuming that the question lies within the province of the target object to answer, cohesion is kept up.

I see that what you're really arguing for is reducing the need for "can you do this? yes? then do it" types of protocols. Fine; I agree. But in arguing that point, you're either misunderstanding or misrepresenting encapsulation.

[mvc]

1. You are correct that reducing the need for "can you do this? yes? then do it" was what I was trying to say. This was the problem with the original solution.
2. When I think about it (why always AFTER I post?!) you are correct in saying that I am misrepresenting encapsulation. Query methods are a tool to defend encapsulation. Getters break encapsulation. Query methods (any methods actually) increase coupling- of course the ultimately independent object has no methods, and is ultimately useless. What I was trying to say was that in our example (although it is sketchy) we can decrease coupling by dispensing with the query methods.

So a predicate function is a boolean query method.