A snapshot from an article--
http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html Tell,Dont Ask
Sure, you may say, that's obvious. I'd never write code like that. Still, it's very easy to get lulled into examining some referenced object and then calling different methods based on the results. But that may not be the best way to go about doing it. Tell the object what you want. Let it figure out how to do it.
Think declaratively instead of procedurally!
----------------
Now,in a case where employee can be either bargainable or officer,and depending on his type his salary is caculated.So,i should tell an employee object to calculate its own salary.So,employee object will create a salary object.right?
Another situation---
Now,I have an entry form to update employee information-before updation I need to check that EmployeeID entered by user exists.What kind of object should have this responsibility,not an employee object,I assume.If employeeid exists,then I create an employee object with the EmployeeID entered,and call the update method.Am I thinking right?