Embian Blog

객체지향 설계 기법의 많은 부분이 사실 객체들 사이에 Coupling을 줄이고 Coherent을 증가시키는데 집중한다.

이를 위해서 패턴, 리팩토링, TDD 등 여러 이론이나 방법론 혹은 기법을 사용하고 Clean Code를 만들기 위해서 많은 개발자들이 신경쓰고 노력하고 있다. 그럼에도 불구하고, 실제 프로젝트를 진행하다보면 점점 코드는 스파게티 모습으로 변하고 더이상 유지되기 힘든 형태로 쉽게 변질되곤 한다. 그러한 코드를 code review를 통해 다시 보더라도 바쁜 일정과 관대한 타협에 의해 좋은 객체지향 디자인을 포기하곤 한다.

이때 유용하게 적용할 수 있는 하나의 기준이 SOLID이고 각 객체들의 디자인이 SOLID를 위반하면 나쁜 냄새가 나는것을 감지하여 다시 디자인을 수정하는 기준이 될 수 있다.

SOLID는 로버트마틴이 2000년대 초반에 명명한 OOD의 다섯가지 기본원칙 마이클 페더스가 첫글자를 조합하여 알기쉽게 소개한 용어이다. 이는 다음의 다섯가지 원칙을 나타낸다.

• SRP: Single Responsibility Principle
• OCP: Open/Closed Principle
• LSP: Liskov Substitution Principle
• ISP: Interface Segregation Principle
• DIP: Dependency Inversion Principle

• SRP: 단일 책임의 원칙
• 한 클래스는 한개의 역할을 가져야한다.
• 여러 역할을 지니는 클래스는 단일 역할을 갖도록 분리하는게 명확하고 유지보수에 좋다. (방법적인 접근으로는 ISP와 밀접한 관계를 갖는다.)
• OCP: 개방/폐쇄의 원칙
• 소프트웨어 요소는 확장에는 열려있어야하고, 변경에는 닫혀있어야 한다.
• LSP: 리스코프 치환의 원칙
• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면 하위타입의 인스턴스로 바꿀수 있어야 한다.
• ISP: 인터페이스 분리의 원칙
• 클라이언트들을 위한 범용 인터페이스보다는 특정 클라이언트가 사용하는 여러개의 인터페이스가 낫다.
• DIP: 의존관계 역전의 원칙
• 추상화에 의존해야지 구체화에 의존하면 안된다.
• 요즘 Spring Framework를 많이 사용하는데 그 주된 이유는 Container에 의한 IoC(Inversion of Control)를 제공하는 기능 때문이다.
• 이는 객체의 Dependency Inversion을 비교적 깔끔하게 Framework Level에서 제공하여 객체의 역할에 집중하여 설계할 수 있기 때문이리라...

각각의 원칙들은 그 의미를 이해하기에 좀더 실증적인 의미를 알기 위해서는 약간의 훈련과 노력이 필요하다. 위의 원칙들은 객체설계에서 Coupling을 줄이고 Coherent을 증가하는 방향으로 관통하고 있고 이는 좀더 나은 객체지향 디자인을 위해 도움을 줄 수 있다.

다만, 우선은 위의 원칙에 대해서 개략적인 내용을 알고 있는 것 만으로도 도움이 될 것이라 생각되어 이번 글에서는 소개 정도로 마감하려한다.(다음 포스팅에서는 좀더 자세한 내용을 담아보고자 한다.)

오늘부터 엠비안 블로그에 참가합니다.

기념으로 간단한 글 하나 올립니다.