Tell Vs Ask - ZeroWiki

�� : http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html �� 'Tell vs Ask'

~cpp 
Alec Sharp, in the recent book Smalltalk by Example [SHARP], points up a very valuable lesson in few words: 
  
Procedural code gets information then makes decisions. Object-oriented code tells objects to do things. 
   --- Alec Sharp

then �� than �� 하�� ? �� 함�� 힘��.

�� . �� then ��. �� 해�� than �� 했��. Thanks.~

�� "Smalltalk by Example" �� 훈�� 한��.

�� 할 �� 한��. �� 향 �� 행�� 하�� 킨��.

~cpp 
That is, you should endeavor to tell objects what you want them to do; do not ask them questions about their state, 
make a decision, and then tell them what to do.

��, �� 하�� 하�� 하�� 해�� 한��. �� 태�� 해 �� , ��하��. �� 하�� 하�� 하��.

~cpp 
The problem is that, as the caller, you should not be making decisions based on the state of the called object 
that result in you then changing the state of the object. The logic you are implementing is probably the called object's 
responsibility, not yours. For you to make decisions outside the object violates its encapsulation.

�� caller ��, �� called object �� 태�� 한 �� .
�� 하�� logic �� 호�� , �� . (�� you �� 해�� object �� 하�� client. caller) �� object �� 해�� object �� encapsulation �� .

~cpp 
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!

�� 할�� . "�� 한 �� !" 하��, referenced object �� 해�� 호��하�� 히 ��하�� 흔하��.

exam) �� Refactoring �� .

~cpp 
switch (person.gender) {
	case IS_MALE:
		____
	case IS_FEMALE:
		____
}

�� . ��통 �� Polymorphism �� 해��해�� 할 ��.

하��, �� . �� 하�� 해�� object �� . (��, �� 행�� 한 �� object �� 해��하��) object �� 하�� 해�� 할�� 해��하�� 하��. ��하�� , �� 하��. (�� OOP �� 하��, Object �� 행�� 해��.)

~cpp 
It is easier to stay out of this trap if you start by designing classes based on their responsibilities, 
you can then progress naturally to specifying commands that the class may execute, as opposed to queries 
that inform you as to the state of the object.

�� 클�� 한 �� 했�� 한 함�� 탈��하�� .
(ResponsibilityDrivenDesign) ��한 ��, �� 태�� 하�� (�� getter �� 해�� ), class �� 행할 �� command �� .

�� (��)�� 해�� 클�� 한�� 한 �� .

Reference - Smalltalk By Example �� 'Tell, Don't Ask' (http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html �� .)

See also ��향vs��향 - �� 페�� ...;; - ��택