Very often I run into code that logic that should be within business object is repeated everywhere as such:
if ( !string.IsNullOrEmpty( Employee.Name ) ) Display( Employee.Name );
where as it should be like this :
if ( Employee.IsNameSpecified ) Display( Employee.Name );
and the Employee.IsNameSpecified has the logic of value being specified.
This is just one example, many others come to mind that are reverse of OOP , procedural code being used to make logical decisions about business objects.
When Logic is encapsulated in the BusinessObject then it is just normal OOP practice (or doeas that have a different name? ), what is the opposite called ? Decapsulation ?
You can see that as one flavor of TDA (tell, don't ask).
What you are doing here: the client code retrieves a "property" owned by another class to then make a decision based on that value.
TDA implies exactly what your question is about: that other class should make that decision for you - your client code should not know the rules to make that decision.
But please note the "recursion" here: the proposed "solution" still violates TDA. You are still fetching a value from another class, so that the client code can make a decision on it.
The only difference: in the first case, you fetch a string, and the client checks if that string is null/empty; in the second case, you fetch a boolean that tells you what to do.
So, the "ideal" OO solution would be more like:
employee.display();
and the employee doing the correct thing completely on its own. But sure, this implementation can quickly turn into a violation of SRP for example - should an Employee class really know about "displaying" itself?!