[회고]오브젝트 OOP

http://www.yes24.com/Product/Goods/74219491

오브젝트 - YES24

 

설계란 코드를 배치하는것 그렇다면 왜 좋은 설계를 해야할까 생각한다면 그것은 현재 기능은 온전히 수행하면서 추가되거나 변경되는 내용을 수용할 수 있게 설계해야한다.

 

이 책을 읽으면서 정리한 생각은 결국 변경에 유연하게 대처를 어떻게 해야할까 고민한다면 결합도를 낮추고 응집도를 증가시킴으로써 변경의 취약하지 않게 될 수 있다.

 

왜 응집도가 높으면 변경에 유연할까 고민했을 때 한 곳의 관련 변경내용이 몰려있으면 어떠한 대상 기능이 변경되었을 때 최소한으로 코드가 변경되기 때문에 사이드이펙트가 덜 발생할 것이다.

 

결합도가 높으면 뭐가 문제일까? 예를들어 어떤 상위 클래스 또는 어떤 구현을 바라보고있다면 구현에 변경으로 그 구현을 바라보는 모든 클라이언트(클라이언트 서버 구조)는 모두 변경이 되야 할것이며 결국 이것은 많은 코드 변경으로 인해 무수히 많은 사이드 이펙트가 발생할 것이다.

 

결국 최소한의 기존 코드 변경으로 변경에 유연하게 대처 할 수 있는 코드를 설계를 해야한다.

 

OOP를 얘기하면 항상 같이나오는 SOLID 원칙은 결국 어떻게 변경에 유연하게 대처할 수 있는 코드를 설계를 할까에서 출발한 이렇게 짜면 유연하지 않을까? 라는 원칙들을 모았다고 생각한다.

 

OOP에서 항상 중요하게 말하는 협력 역할 책임, 어떠한 협력을 이끌어내기 위해 역할에 책임이 바뀌며 본인에 책임을 다하는 코드 캡슐화는 객체를 하나의 책임을 가질 수 있게하는 방법이며 결국 구현을 외부에 감추고 인터페이스만 공개함으로써 클라이언트와 객체간의 결합도 를 떨어뜨리고 응집도를 높여줌으로써 이건 즉 단일책임원칙(Single Responsibility Principle)를 이끌어주게 된다. 또한 인터페이스만을 외부에 공개함으로써 내부코드변경에는 닫혀있어야 되고 기능확장에 대해서는 열려있어야하는 개방폐쇠원칙(Open Close Principle)로 이끌게 된다.

 

또한 크게 느낀게 서브 타입과 서브클래스에서 대해서 상속은 2가지 이유로만 사용되어야하고 그 두가지는 1. 코드의 재사용인경우 2. 서브타이핑이어야한다.(즉 행동호환성이 같은경우 만을 서브타이핑이라 할 수 있으며 이건 클라이언트 관점에서의 행동호환성을 보장해주어야한다.) 단순이 fly라는 operation을 method로 구현한다 해서 서브타이핑이 아니라 fly라면 정말 날아야지 내부 구현이 걸으면 안된다는 것이다. 이 때 부모클래스를 상속받은 서브타이핑 구현클래스는 부모클래스로 바꾸더라도 문제없이 작동되어야한다. 이것은 리스코프 치환원칙과 연결된다.(The Liskov Substitution Principle) 이로인해 리스코프 치환원칙은 코드를 좀 더 유연하고 확장가능하게 만들어준다.

 

객체가 책임을 단일로 가져가야 하는 것처럼 하나의 인터페이스가 너무 많은 책임을 가지고있다면 이것은 특정 오퍼레이션만 필요한 객체가 굳이 구현하지 않아도 될 오퍼레이션을 구현해야하기 때문에 문제가 되며 이로 인해 인터페이스는 최소한의 책임만을 가져가야한다. 인터페이스 분리 원칙(Interface Segregation Principle) 

 

의존성 역전원칙(Dependency Inversion Principle)은 코드의 결합도를 떨어트려 준다. 클라이언트가 구현이 아닌 인터페이스를 의존함으로써 단순히 클라이언트는 메시지만 보내기만 하면 되고 메서드는 런타임 시점에서 정해지게 되면서 확장성있는 코드가 될 수 있다. 협력 역할 책임 아래 OOP 디자인 패턴은 코드를 좀 더 복잡하지만(컴파일시점과 런타임 시점이 괴리가 생긴다. 이것이 그리고 목표이다) 결합도를 떨어트리고 응집도를 올리면 변경에 유연하게 대처할수있게 되는 트레이드 오프이다.