일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 리버스프록시
- java
- 스프링트랜잭션
- 코틀린뽀개기
- 알고리즘
- subprocess에러
- 코틀린기초
- 객체지향생활체조
- 테코톡
- Google Place Photo API
- KotlinInAction
- kotlin
- 무중단배포
- mysqld.sock
- 우아한테크코스
- 트랜잭션
- servlet프로젝트
- GithubOAuth
- tomcat설정
- 레벨로그
- 코틀린
- S2139
- 트랜잭션성질
- 자바비동기
- 데이터베이스락
- 트랜잭션속성
- DynamicWebProject
- 백준
- ObjectCalisthenics
- jsp프로젝트
- Today
- Total
초이로그
객체지향 생활체조 9가지 원칙 본문
1. 한 메서드에서 한 단계 들여쓰기만 사용하자
2. else 예약어를 쓰지 말자
3. 모든 원시값과 문자열을 포장하자
4. 일급 컬렉션을 사용하자
5. 한줄에 한개의 점만 사용하자
6. 축약하지 말자
7. 모든 엔티티를 작게 유지하자
8. 클래스는 변수 두개를 넘지 않게 하자
9. getters, setters, properties를 사용하지 말자
객체지향 생활체조(Object Calisthenics)란, Jeff Bay가 The ThoughtWorks Anthology(SW공학 에세이 모음집)에서 처음 소개되었다. 원칙들은 만병통치약이 아니므로 모든 디자인 문제점들을 해결해줄 수는 없다. 하지만 객체지향 생활체조의 주요 목적이 특정 SOLID 원칙을 적용하기 위함이기 때문에, 이를 적용하면 보다 clean, flexible, agile, reusable 한 코드를 작성할 수 있다.
1. 한 메서드에서 한 단계 들여쓰기만 사용하자
Use only one level of indentation per method
메서드는 하나의 역할만 담당해야한다. 코드 라인 수가 줄어드는 것은 아니지만 가독성이 향상된다.
(Extract Method 패턴)
2. else 예약어를 쓰지 말자
Don’t use the else keyword
조기 반환(early return)을 사용하자.
if-else에 해당하는 모든 로직을 수정하는 것보다, 조건을 추가하는 것이 리팩토링 시 더 쉽다.
(Null 객체 패턴, 상태 패턴, 전략 패턴)
3. 모든 원시값과 문자열을 포장하자
Wrap all primitives and strings
DDD(Data Driven Design). 원시값 변수에 동작(ex. 유효성 검사)이 있다면, 클래스로 포장하여 의도를 나타낼 수 있다.
안티패턴인 Primitive Obsession을 피할 수 있다.
4. 일급 컬렉션을 사용하자
Use first-class collections
일급 컬렉션: 컬렉션 외에 다른 멤버 변수를 포함하지 않은 클래스.
중요한 데이터 Set을 하나의 클래스에서 관리 가능 + 캡슐화
5. 한 줄에서 한개의 점만 사용하자
Use only one dot per line
메서드 체이닝을 제거하여 가독성 있는 코드를 만들 수 있다. (디미터의 법칙)
그러나 Fluent Interfaces와 Method Chaining Pattern 구현에는 적용되지 않는다.
6. 축약하지 말자
Don’t abbreviate
"왜 축약하려고 하는가?"
같은 이름이 반복되어 사용되서? ➡️ 메서드가 여러번 재사용되고 있을 수 있다. 중복되는 코드가 있는지 의심해보자.
이름이 너무 길어서? ➡️ 너무 많은 일을 하고 있을 수 있다. (단일 책임의 원칙)
적당한 이름을 찾기 힘든 경우, 잘못된 무언가가 없는지 생각해봐라.
7. 모든 엔티티를 작게 유지하자
Keep all entities small
클래스는 50줄을, 패키지는 파일 10개를 넘기지 않아야한다. (기준은 바뀔수 있다)
중요한 점은, 긴 파일은 읽고, 이해하고, 재사용하기 매우 힘들다는 것이다.
8. 클래스는 변수 두 개를 넘지 않게 하자
Don’t use any classes with more than two instance variables
가장 지키기 힘든 원칙이지만, 더 높은 응집력을 갖고 더 나은 캡슐화가 가능하다.
여기서 "두 개"는, 클래스를 많이 분리하도록 강요하기 위한 임의의 숫자이다.
9. Getter / Setter / Properties를 사용하지 말자
Don’t use any getters/setters/properties
"말을 건네라. 묻지 말고"
객체의 상태에 따라 결정이 된다면, 그것은 객체 바깥이 아닌, 내부에서 해야한다. (개방/폐쇄의 원칙)
다시 말해, 객체의 상태를 결정하지 않는다면(ex.단순한 값 출력), getter는 외부에서 사용될 수 있다. setter는 안된다.
이렇게 객체지향의 원칙을 지킬 수 있도록 도와주는 원칙이 있다니.. 정말 감동적이라 눈물이 좔좔좔...^_ㅠ
참고로 Calisthenics는 보통 "맨몸 운동"이라는 뜻으로 사용되는거 같은데
번역가 분이 친근하면서도 기본기의 느낌을 살려 센스있게 잘 번역해주신거 같다 👍👍
참고자료)
- https://williamdurand.fr/2013/06/03/object-calisthenics/#2-dont-use-the-else-keyword
- https://blog.avenuecode.com/object-calisthenics-principles-for-better-object-oriented-code
- 최신 칼럼으로 규칙 1-3, 5-6, 9를 강조
- 티스토리 Woogear's Blog (한글): https://devwooks.tistory.com/59