엘레강트 오브젝트 5/5

 

객체를 살아있는 유기체라고 생각하고 이야기를 시작해 보겠습니다.

 

실전 코드로 배우는 실용주의 디자인 패턴이란 책에서 Allen Holub는 gett와 sett를 쓰기 말라고 이야기한다. 쓰는 걸 지양하자가 아니고 악이니 쓰지 말라고 단호히 말한다. 지금은 맞는 말이지만 당시에는 좀 논란이 된 것으로 안다.

 

이 책의 저자도 시원하다. 하라와 하지 마라, 맞고 틀리다가 명확하다. 모두 동의하는 것은 아니지만 대부분 맞는 말 같다. 읽은 후 평소 애매했던 것들에 대한 궁금증이 많이 해소되었다. 두께에 비해 비싼 편이지만 제값 하는 것 같다.

 

---

- 클래스의 이름은 무엇을 하지는지가 아니라 무엇인지에 기반해야 합니다. 여기에 숨어있는 악마는 바로 접미사 -er입니다.

- 생성자에 코드를 넣지 마세요

class StringAsInteger implements Number {
	private String text;
    public StringAsInteger(String text) {
    	this.text = text;
    }
    
    public int intValue() {
    	return Integer.parseInt(this.text); // 매번 호출하지만 아래 코드 보다 더 빠름
    }
 }
 
 ------------------------------------------------
 
 class StringAsInteger implements Number {
	private int num;
    public StringAsInteger(String text) {
    	this.num = Integer.parseInt(text); // 최적화 불가능. 실행 여부 제어 불가
    }
    
    public int intValue() {
    	return this.num;
    }
 }
 

- 가능하면 적게 캡슐화 하세요. 4개 또는 그 이하의 객체를 캡슐화하세요 (4개라는 숫자보다는 생각보다 작다는 게 놀랐다.)

- 메서드 이름을 빌더는 명사로 조정자는 동사로 지으세요. 일반적으로 제과점에 들러 "브라우니를 요리해 주세요"라거나 "커피 한잔 끓여 주세요"라고 말하지 않습니다. "브라우니 주세요" 또는 "커피 한 잔 주세요"라고 말합니다( 논란의 여지가 있을 것 같다. 보통 메서드는 동사로 시작하는데, 리턴하는 객체가 존재한다면 명사가 되어야 된다고 한다)

- Boolean값을 반환하는 메서드는 형용사로 지어야 합니다.(나는 is가 더 읽기 좋다고 생각한다.)

 

// 좋은 예
float speed()
Employee employee(int id);
String parsedCell(int x, inty);

void save(String content);
void put(String key, Float value);
void remove(Employy emp);
void quicklyPrint(int id);

// 나쁜 예
int save(String content); // 저장된 전체 바이트를 반환
boolean put(String key, Float value); // map이 변경된 경우 TRUE 반환
float speed(float val); // speed를 저장한 후 값을 반환


// 잘못된 예 -> 좋은 예로 수정
InputStream load(URL url) -> InputStream stream(URL url)
String read(File file) -> String content(File file)
int add(int x, int y) -> int sum(int x, int y)
boolean IsEmpty() -> boolean empty()

- Java에서 허용 가능한 클래스는 주석 포함 250줄이라 생각합니다. 5개 이하의 public 메서드만 노출하세요(생각보다 아주 작다)

- 객체를 다른 객체로 완전히 분리하기 위해 new 연산자를 사용하지 말아야 합니다.

- 싱글톤은 안티 패턴이자 형편없는 개념일 뿐입니다.

- 함수형 프로그래밍은 훌륭한 패러다임이지만, OOP가 더 낫습니다. 표현력이 더 뛰어나고 강력하기 때문입니다.

 

필자는 심지어 연산자도 절차적인 문장이 포함되어 있으므로 객체화되어야 된다고 한다.

flat rate = new If(
	new GraterThan(new AgeOf(client), 65),
    2.5, 3.0
);

- NULL은 사용하지 않기를 바랍니다.(강려크하게 동의한다. 코드가 훨씬 단순해진다.)

- 항상 예외를 체이닝 하고 절대로 원래 예외를 무시하지 마세요

 

 

---

180 페이지 정도 되는 책인데 버릴 내용 없이 알차다. 몇몇 내용은 실무에 적용해봤는데 만족한 결과였다. 너무 단정적이고 공감되지 않는 부분도 있으나 필자가 추구하는 개념과 원칙을 받아들인다면 오브젝트에 대한 시야는 분명 넓어질 것이다.