객체지향 설계 5원칙 (SOLID)

안녕하세요

앵과장입니다.

 

한때는 한참 객체지향 설계에 대해서 물어보는 회사들이 많이 있는데 꼭 알아야만 하는 건 아니지만 

알면 정보에 하나가 될 수 있으니 가볍게 정리만 해보도록 하겠습니다.

아시죠 말보다는 실천과 행동이 중요하며 서비스를 지속적으로 성장시킬 수 있는 구조와 꾸준한 리펙토링이 동반되어야 합니다.

 

설계의 원칙 지금은 다양한 방법들이 존재하며 서비스에 상황 그리고 목적에 따라 변할 수 있습니다.

서비스는 항상 일관성이 유지되어야 하며 직관적이며 협업하는 관계에서는 더 좋은 방법도 중요하지만 모두가 동일한 도메인에 대한 지식과 커뮤니케이션 가능한 코드가 우선인 점 항상 유념해주시면 좋을 것 같습니다.

 

이밤에끝을잡고 있는 나에...

 

책임(Responsibility)

• 특정 액터의 요구사항을 만족시키기 위한 일련의 함수의 집합
• 변경의 원인을 의미하는 지점
• 각 책임에 대한 분류를 의미

 

SRP(Single Responsibility Principle) : 단일 책임 원칙

• 이 단계의 목적은 모듈들을 분리하고 반드시 하나의 액터만을 위해 존재 하도록 구성
• Use Case를 분해하여, SRP를 준수하는 모듈로 격리(isolate)

단일 클래스는 단 하나의 책임(변경 사유) 을 가져야 한다는 원칙

 

solution

• Inverted Dependencies : 의존성이 존재하는 Actor들에게 Interface를 제공하여 간접적인 참조를 할수 있도록 수정
• Extract Classes : 각각의 Actor들에게 단일 책임을 갖는 클래스로 분리하여 의존성을 갖도록 구성
• Facade : Actor들이 사용하고 기능을 완벽하게 제거할수 없다면 하위 클래스에 위임하는 facade를 구현하여 적용(레거시 시스템을 지원하기 위해서 사용되는 경우가 많음)
• Interface Segregation : 각 Actor 별로 의존된 기능을 각각의 인터페이스로 분리하고 이렇게 분리된 모든 인터페이스를 단일 객체가 구현하는 방식

 

OCP(Open Closed Principle) : 개방 폐쇄 원칙

확장에 대해서는 개방 되어 있지만, 수정에 대해선 폐쇄 되게 해야 한다는 원칙

 

LSP(Liskov Substitusion Principle) : 리스코프 치환 원칙

SubClass는 언제나 SupperClass를 교체 할수 있다는 원칙

즉, 부모클래스(SupperClass) 자리에 자식클래스(SubClass)를 넣어도 계획대로 잘 동작해야 되는 것을 의미함

 

DIP(Dependency Inversion Principle) : 의존성 역전 원칙

상위모듈(기능모듈)은 하위모듈(구현모듈)에 의존해서는 안된다는 원칙(중간에 추상 모듈을 끼워 넣어 분리)

첫째, 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 둘째, 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다.

 

ISP(Interface Segregation Principle) : 인터페이스 분리 원칙

Client에서 전달될 Interface method 들 중 사용되지 않는 method는 전달 되지 않아야 한다는 원칙

인터페이스 기능 단위를 최소화 하여 client에 전달해야 하며, 먄약 하나의 인터페이스에 여러 기능을 담아 전달 해야 되는 경우, 여러개의 기능별 분리된 인터페이스로 나누고 이를 상속하여 하나의 인터페이스를 전달하여 구성