본문 바로가기

Programming/SW Engineering , Architecture, etc.

Perfecting OO's Small Classes and Short Methods. 완벽한 객체지향의 작은 클래스와 짧은 메소드, Book:ThoughtWorks Anthology, Java,cpp,자바,oop,좋은코드,객체지향프로그래밍 (1)

Perfecting OO's Small Classes and Short Methods. 완벽한 객체지향의 작은 클래스와 짧은 메소드, Book:ThoughtWorks Anthology, Java,cpp,자바,oop,좋은코드,객체지향프로그래밍 (1)


Origin ( Here )
원문 ( 여기 )


난해한 내용 (8, 9번) 추가 포스팅 링크함
Stuff difficult to understand, (#8, 9), added more info posting




 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. 


1. 각 메소드마다 딱 한번의 인덴테이션 (들여쓰기) 만 쓴다. 만약 한칸 이상의 들여쓰기가 필요하면, 새로 다른 메소드를 만들어서 호출한다. 이건 이 연습에서 가장 중요한 제약사항이다.



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...?




2019/01/29 - [Programming/Programming Language] - 클린코딩/더 나은 코딩을 하는 10가지 방법, 10 Tips for clean code/ better code/ quality code.


2019/01/30 - [Programming/Software Architecture] - What is Object Oriented Design/Artchitecture? 객체지향 디자인/설계란? java,c++,softwareArchitecture,designPattern



2019/02/03 - [Algorithm/Leet Code] - LeetCode #393 UTF-8 Validation. Algorithm,알고리즘,LeetCode,Codefights,CodeSignal,코드파이트,코드시그널,예제,문제해결능력,example,c++,java,재귀,recursive,datastructure,techinterview,coding,코딩인터뷰,기술면접

2019/02/03 - [Algorithm/Leet Code] - LeetCode #398 RandomPickIndex. Algorithm,알고리즘,LeetCode,Codefights,CodeSignal,코드파이트,코드시그널,예제,문제해결능력,example,c++,java,재귀,recursive,datastructure,techinterview,coding,코딩인터뷰,기술면접

2019/02/01 - [Algorithm/Leet Code] - LeetCode #905 SortArrayByParity. Algorithm,알고리즘,LeetCode,Codefights,CodeSignal,코드파이트,코드시그널,예제,문제해결능력,example,c++,java,재귀,recursive,datastructure,techinterview,coding,코딩인터뷰,기술면접



2018/12/26 - [Algorithm/Code Fights (Code Signal)] - Aracade Intro #48 isDigit. Algorithm, 알고리즘, Codefights, CodeSignal, 코드파이트, 코드시그널, 예제, example, c++ java c# scalar

2018/12/26 - [Algorithm/Code Fights (Code Signal)] - Aracade Intro #47 isMAC48Address. Algorithm, 알고리즘, Codefights, CodeSignal, 코드파이트, 코드시그널, 예제, example, c++ java c# scalar

2018/12/25 - [Algorithm/Code Fights (Code Signal)] - Aracade Intro #46 electionsWinners. Algorithm, 알고리즘, Codefights, CodeSignal, 코드파이트, 코드시그널, 예제, example, c++ java c# scalar

2018/12/21 - [Algorithm/Code Fights (Code Signal)] - Aracade Intro #45 buildPalindrome. Algorithm, 알고리즘, Codefights, CodeSignal, 코드파이트, 코드시그널, 예제, example, c++ java c# scalar

2018/12/20 - [Algorithm/Code Fights (Code Signal)] - Aracade Intro #44 findEmailDomain. Algorithm, 알고리즘, Codefights, CodeSignal, 코드파이트, 코드시그널, 예제, example, c++ java c# scalar



2018/12/16 - [Life/Health care] - L-Arginine 아르기닌 usage/side effects/dosage 효능/부작용/성인,소아 용법(2)

2018/12/26 - [Life/Health care] - Selenium 셀레늄 usage/side effects/dosage 효능/부작용/성인,소아 용법



2018/11/28 - [Programming/Image Processing] - OpenCV How to get min/max value from matrix, 매트릭스 최소값/최대값. Java,c++,cpp,imageprocessing


2018/11/28 - [Programming/Image Processing] - OpenCV How to handle single channel image matrix each pixel, add/subtract/multiply/division (1), 이미지 매트릭스 각 픽셀단위 값 조정하기 (영상처리, image processing) (1)


2018/11/27 - [Programming/Image Processing] - OpenCV Java complexNumber mat conjugation, 자바 켤레복소수 example code 예제코드


2018/11/22 - [Programming/C++] - Visual Studio console closing problem after running main function 비주얼스튜디오 메인 실행 후 콘솔 꺼지는 문제