Perfecting OO's Small Classes and Short Methods. 완벽한 객체지향의 작은 클래스와 짧은 메소드, Book:ThoughtWorks Anthology, Java,cpp,자바,oop,좋은코드,객체지향프로그래밍 (1)
In The ThoughtWorks Anthology a new book from the Pragmatic Programmers, there is a fascinating essay called “Object Calisthenics” by Jeff Bay. It’s a detailed exercise for perfecting the writing of the small routines that demonstrate characterize good OO implementations. If you have developers who need to improve their ability to write OO routines, I suggest you have a look-see at this essay. I will try to summarize Bay’s approach here.
He suggests writing a 1000-line program with the constraints listed below. These constraints are intended to be excessively restrictive, so as to force developers out of the procedural groove. I guarantee if you apply this technique, their code will move markedly towards object orientation. The restrictions (which should be mercilessly enforced in this exercise) are:
1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.
2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.
'else' 키워드를 쓰지 않는다. if 문으로 조건을 확인하고, 조건에 맞지 않으면 빠져나간다. 이건 if-else 연환을 방지하고, 모든 루틴은 한개의 일만 한다. 곧 이해할 것이다.
3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.
모든 기본자료형과 문자열들을 랩핑해라. 이건 "primitive obsession" 이라 직접적으로 다룬다. 만약 네가 정수형을 쓴다면, 실제 역할을 알아보게하는 클래스를 만들어라 (내부 클래스로라도). 예를들면, 우편번호는 정수가 아니라 객체이다. 이건 훨씬 깔끔하고 테스터블한 코드를 만들어 준다.
4. Use only one dot per line. This step prevents you from reaching deeply into other objects to get at fields or methods, and thereby conceptually breaking encapsulation.
한줄에 1개의 점을 찍어라. 이건 네가 각 객체의 속성이나 메소드에 깊이 들어가는 것, 그리하여 캡슐화를 깨는 것을 막아준다.
5. Don’t abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name. And you’ll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship().
이름을 생략하지마라. 이 제약은 중복의 특정한 형태에 의해 만들어지는 점층적인 변형을 피하게 한다. 만약 네가 풀네임이나 풀메소드명, 풀변수명을 타이핑해야한다면, 넌 아마 이름에 대해 더 많은 시간을 쓰게 될 것이다. 그리고 너는 shipOrder() 라고 명명된 메소드를 호출하여 객체를 만드는 것을 피하게 될 것이다. 대신에 너의 코드는 Order.ship() 과 같은 호출을 더 많이 할 것이다. (클래스를 많이 만들게 될 것이다. 로 해석하면 될 듯)
6. Keep entities small. This means no more than 50 lines per class and no more than 10 classes per package. The 50 lines per class constraint is crucial. Not only does it force concision and keep classes focused, but it means most classes can fit on a single screen in any editor/IDE.
객체들을 작게 유지해라. 이건 패키지당 10개 이하의 클래스 / 클래스당 50줄 이하를 의미한다. 50줄 이하의 클래스는 중요하다. 간결하고 클래스에 집중도를 유지하게 할 뿐만 아니라, 모든 클래스들이 한 화면안에 (어느 에디터나 IDE에서) 들어오게 할 수 있는 것이다.
7. Don’t use any classes with more than two instance variables. This is perhaps the hardest constraint. Bay’s point is that with more than two instance variables, there is almost certainly a reason to subgroup some variables into a separate class.
어떤 클래스던 두개 이상의 인스턴스 변수를 사용하지 말아라. 이건 아마 가장 어려운 제약사항이다. Bay의 요점은 인스턴스가 두개 이상이 되면, 분리된 클래스 안에 몇 인스턴스들을 하위그룹으로 묶는 이유가 되는 것이 대체적으로 확실해진다. (좀 봐얄듯)
8. Use first-class collections. In other words, any class that contains a collection should contain no other member variables. The idea is an extension of primitive obsession. If you need a class that’s a subsumes the collection, then write it that way.
첫클래스 콜렉션을 사용해라. 다시말하면, 콜렉션을 포함하는 어느 클래스든 다른 멤버변수를 포함하지 말아야 한다. 이 아이디어는 "primitive obsession"(기본자료형의 클래스 랩핑) 의 확장형이다. 만약 네가 콜렉션을 포함하는 클래스가 필요하면, 그런식으로 써라.
9. Don’t use setters, getters, or properties. This is a radical approach to enforcing encapsulation. It also requires implementation of dependency injection approaches and adherence to the maxim “tell, don’t ask.”
세터/게터/프로퍼티 를 사용하지 말아라. 이건 캡슐화를 강제적으로 하는 원초적인 접근이다. 이건 또한 의존성 주입의 접근과, "말해라, 묻지말고" 라는 격언에 맞는 구현을 요구한다. (그래서 어찌라고?)
-> 부연설명 ( 여기 )
-> additional info ( Here )
Taken together, these rules impose a restrictive encapsulation on developers and force thinking along OO lines. I assert than anyone writing a 1000-line project without violating these rules will rapidly become much better at OO. They can then, if they want, relax the restrictions somewhat. But as Bay points out, there’s no reason to do so. His team has just finished a 100,000-line project within these strictures.
다 해보면, 개발자들의 엄격한 캡슐화 규칙을 부과하고, 객체지향에 대해 생각하게 한다. 1000줄의 프로젝트를 이 규칙들을 깨지않고 구현하면, 빠르게 객체지향을 잘하게 될 것이라 확신한다. 만약 원한다면 다소 널널하게 제약을 주면서 할 수 있다. 하지만 Bay는 그럴 이유가 없다고 지적한다. 그의 팀은 10만줄 이상의 프로젝트를 이 규제 하에서 마쳤다.
Something you might like...?
2018/12/16 - [Life/Health care] - L-Arginine 아르기닌 usage/side effects/dosage 효능/부작용/성인,소아 용법(2)
2018/12/26 - [Life/Health care] - Selenium 셀레늄 usage/side effects/dosage 효능/부작용/성인,소아 용법
