imported>Unknown at 05:28, 7 February 2021

2021-02-07T05:28:11Z

New page

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

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" 이라는 최근의 책에서는 아주 값어치있는 교훈을 강조한다.

'''절차적인 코드에서는 정보를 얻고 난 뒤 할 일을 결정한다. 개체 지향 코드에서는 객체에게 행동을 하도록 시킨다.'''

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.

요는, 당신은 객체들로 하여금 당신이 원하는 일을 하도록 노력해야 한다. 객체들의 상태에 대해 객체들에게 묻지 말고, 결정하라. 그리고 객체들에게 원하는 일을 하도록 하라.

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 에 위반된다.

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 책에도 나올것이지만.
switch (person.gender) {
case IS_MALE:
____
case IS_FEMALE:
____
}
이런식의 코드들. 보통 이런건 Polymorphism 으로 해결해야 할 문제들이지요.

하지만, 이는 좋은 방법이 아니다. 당신이 원하는 일에 대해서 object 에게 시켜라. (즉, 저 행위에 대한 결정은 object 내에서 해결하게끔) object 로 하여금 어떻게 해야 할지 해결하도록 하라. 절차적이려하기 보단, 서술적이려고 하라. (이는 OOP 에서 이야기하듯, Object 들 간의 행동들에 대해서.)

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 [http://www.owlnet.rice.edu/~comp212/99-fall/handouts/week1/person 개체지향vs절차지향] - 지금 여기 서버가 죽은것 같은데 서버 살아나면 페이지 뜰껍니다...;; - 임인택

TellVsAsk - Revision history

imported>Unknown at 05:28, 7 February 2021