객체 지향과 디자인 패턴 (Part 1.객체지향)

객체 지향과 디자인 패턴 국내도서 저자 : 최범균 출판 : 인투북스 2013.07.05 상세보기

 

유지보수를 하면서 불편한 점이 이만저만이 아니다.

1) 추가 요구사항이 있으면 여기저기 추가해야한다.

2) 수정사항이 있으면 연계된 다른 곳도 손봐야한다.

이렇게되면!

연계된 모든 곳까지 고려해야해서 신경쓸게 많아진다. → 신경쓸 곳이 늘어나면 결국 실수를 하게 된다.

그래서 요즘 '객체 지향과 디자인 패턴' 책을 읽으며 나름의 리팩토링을 시도하고 있다.

초보개발자인 나도 굉장히 쉽게 이해할 수 있었고, 따라하고 싶은 의지가 활활 타오르는 책이라서 정리해놓고 봐야겠다.

(개인적으로 다시 보면 좋을 것들이라고 생각한 것들을 정리해서 내용이 부실 그 자체일 수 있습니다!)

 

---

객체가 갖는 책임(기능)의 크기는 작을수록 좋다. (=단일책임원칙)

캡슐화를 위한 규칙 : Tell, Don't Ask, 데미테르의 법칙(Law of Demeter)

> Tell, Don't Ask : 데이터를 물어보지 않고 기능을 실행해 달라고 요청

//As-is
String userId = user.getId();
if(userId.length()!=0 && userId.equals("") && userId!=null) {
    return true;
}
 
//To-be
if(hasId) {
    return true;
}
 
private boolean hasId() {
    String userId = user.getId();
 
    if(userId.length()!=0 && userId.equals("") && userId!=null) {
        return true;
    }
    return false;
}

> 데미테르의 법칙 : 메소드로 생성한 객체, 파라미터로 받은 객체, 필드로 참조하는 객체의 메소드 호출

   - 데미테르 법칙을 지키지 않는다면 ?

      1) 연속된 get 메소드 호출

value = user.getA().getB().getValue();

      2) 임시 변수의 get 호출이 많음

A a = user.getA();
B b = a.getB();
value = b.getValue();

 

추상화를 잘하려면 ?

여러 상황에서 유연한 설계를 만들어 보는 경험이 중요함.

경험이 없다면, 변경되는 부분 추상화 (한번 변경된건 또 변경될 가능성이 높아서) / if-else 블록 추상화

 

인터페이스에 대고 프로그래밍하기 (program to interface)

기능을 정의한 인터페이스를 사용해서 프로그래밍하기.

인터페이스는 최초 설계에서 바로 도출되기 보다는, 요구 사항의 변화와 함께 점진적으로 도출 됨.

하지만 유연함을 얻자고 모든 곳에 인터페이스를 사용한다면, 불필요하게 프로그램 복잡도만 증가시킬 수 있음.

(변화 가능성이 높은 곳에만 사용하자!)

 

상속을 통한 재사용의 단점

1) 상위클래스 변경 어려움 : 상위클래스를 변경하면 하위클래스까지 변경의 여파가 전달되기 때문

2) 클래스의 불필요한 증가

3) 상속의 오용 : 상위클래스가 상속받은 클래스의 메소드를 사용해서 의도와는 다르게 사용 가능

(상속은 IS-A 관계일 때만)

따라서, 상속보다 객체 조립을 먼저 고민해보는 것도 좋은 방법!