Principles of SW Design

SOLID

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

• 정의 : 작성된 클래스는 하나의 기능만 가지며 클래스가 제공하는 모든 서비스는 그 하나의 책임을 수행하는데 집중되어야 한다는 원칙
• 장점 : 책임을 적절히 분배함으로써 코드의 가독성 향상, 유지보수 용이, 응집도는 높아지고 결합도는 낮아짐
• 단점 : 하나의 책임이라는 게 모호할 수 있음

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

• 정의 : 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원리
• 장점 : 기존 구성요소를 쉽게 확장하여 재사용 가능, OCP를 가능케 하는 중요 메커니즘은 추상화와 다형성, 객체지향의 장점을 극대화하는 가장 중요한 원리
• 단점 : 확장되는 것과 변경되지 않는 모듈을 분리하는 과정에서 오히려 관계가 더 복잡해질 수 있다.

The Liskov Substitution Principle(LSP) : 리스코브 치환의 원칙.

• 정의 : 서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다.
• 장점 : 관련 검사를 통해 올바른 하위 계층을 보장, 새로운 클래스의 확장이 쉬워진다, 코드의 유지 관리가 매우 쉬워진다. 
• 단점 : 종종 새로운 확장을 지원하기 위해 기본 클래스도 업데이트해야 한다.

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

• 정의 : 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다. 즉 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용해야 한다.
• 장점 : 재사용 가능하고 확장 가능하며 전혀 경직되지 않고 무엇보다도 구성 가능함(Composable)을 제공
• 단점 : 인터페이스 수가 많아져서 코드보기가 힘들어질 수 있다.
• 기타 : SRP가 클래스의 단일책임을 강조한다면 ISP는 인터페이스의 단일 책임을 강조, Composable에 대한 비유는 레고. (어떤 모양이나 형태로든 결합할 수 있는 1000개의 작은 조각으로 복잡한 작업 시스템을 만든다)

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

• 정의 : 상위 모듈은 하위 모듈에 의존해서는 안된다, 변화하지 않는 것에 의존하라.
• 장점 : 확장성이 용이, 객체간의 관계를 느슨하게 만듦.
• 단점 : 
• 기타 : 훅 메서드(슈퍼클래스에서 디폴트 기능을 정의해두거나 비워뒀다가 서브클래스에서 선택적으로 오버라이드 할 수 있도록 만들어둔 메소드)

Abstraction

복잡한 자료, 모듈, 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것.

Refinement

Refinement(정제)는 단순히 불순물이 있으면 제거하고 품질을 높이기 위해 무언가를 정제하는 것을 의미한다. 소프트웨어 디자인의 정제 개념은 실제로 시스템이나 소프트웨어를 정교하게 만드는 것을 의미하는 세부적인 방식으로  소프트웨어나 시스템을 개발하거나 제시하는 과정이다. 오류가 있는 경우 이를 찾아 이를 줄이기 위해 많은 수정이 필요하다. 

Separation of Concerns

• 관심사의 분리. 애플리케이션을 서로 겹치지 않는 개별 단위로 나누는 과정. 하드웨어적인 것부터 클래스 인스턴스까지 개별이 될 수 있는 모든 요소를 통칭함. 잘 나누어진 관심사는 각각 재사용이 가능하고 개발 및 유지 관리를 단순화할 수 있다.
• 프로그램을 별개의 섹션으로 분리하여 각 섹션이 개별적인 문제를 해결하도록 하는 설계 원칙
• 개발 및 유지관리를 단순하게 해 준다. 잘 나뉘어 있는 관심사(concern)는 개별 섹션을 재사용할 수 있을 뿐 아니라 다른 섹션의 세부 사항을 알지도 변경하지 않고도 개발된 코드를 재사용할 수 있게 함.

Modularity

모듈화는 시스템의 계층을 나누고 기능별로 분해하여 소프트웨어의 성능, 유지보수성, 재사용성 등을 향상하는 설계 기법

 

장점 :

• 프로그램의 효율적인 관리
• 이해하기 쉬운 소프트웨어
• 소프트웨어 시험, 통합, 수정 시 용이, 모듈 재사용성 가능

단점 :

• 실행 시간은 더 길 수 있지만 확실하진 않음
• 스토리지 크기는 증가할 수 있지만 확실하진 않음
• 컴파일 및 로딩 시간이 더 길어질 수 있다
• 모듈 간 통신 문제가 증가할 수 있음
• 더 많은 연결이 필요하고 런타임이 더 길어질 수 있으며 더 많은 소스코드를 작성해야 하며 더 많은 문서를 작성해야 한다.

모듈화의 목표 :

• 모듈 간 결합도의 최소화 & 모듈 내 요소들 간 응집도의 최대화

Functional Independence

기능적 독립성은 한 종류의 작업만 수행하고 다른 모듈과 과도하게 상호작용하지 않는 함수를 개발함으로써 달성됩니다. 독립성은 구현의 접근성과 속도를 높여주기 때문에 중요합니다. 독립 모듈은 유지보수, 테스트 및 오류 전파 감소가 더 쉽고 다른 프로그램에서도 재사용할 수 있습니다. 따라서 기능적 독립성은 소프트웨어 품질을 보장하는 좋은 설계 기능입니다.

Cohension (응집도)

• 모듈의 내부 기능이 얼마나 연관되어 있는가?
• 모듈 내에 관련성이 없는 기능들이 포함되어 있으면 모듈화 정도가 낮은 것이다.

Coupling (결합도)

• 모듈 간 얼마나 구분이 되어 있는가?
• 모듈간 결속이 강하고 영향도가 크다면 모듈화 정도가 낮은 것이다.

Information Hiding (정보은닉)

정보은닉(information hiding)이란 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통해 접근을 허용하는 것으로, 클래스 외부에서 특정 정보에 접근을 막는다는 의미이다

 

캡슐화와의 차이점

캡슐화는 관련된 요소들을 묶음으로써 캡슐 내부와 외부를 구별 짓기 때문에 캡슐 내에 속한 부분과 캡슐 외에 속한 부분들에 대해 구분이 명확하게 돼있다. 즉, 특정 객체 속에 있는 데이터와 함수들을 다른 객체 속에 있는 데이터와 함수들과 구별이 이뤄진다는 의미이다.

하지만 정보은닉은 캡슐 내의 요소들에 대한 세부 구현 사항들을 외부로부터 숨기는 것이다. 즉, 캡슐화가 되어있는 데이터와 함수에 대해서 외부에 해당 함수가 어떻게 구현되어 있는지에 대한 세부 사항을 숨기는 것이다.

 

정보은닉의 개념이 캡슐화 개념 안에 포함되긴 하지만, 캡슐화가 되어있다고 해서 반드시 정보은닉이 되는 것은 아니다.

https://m.blog.naver.com/wowzzin/221467947512
https://www.nextree.co.kr/p6960/
https://bkmoon81.wordpress.com/2018/03/01/cep-%EB%A9%B4%EC%A0%91%EC%A4%80%EB%B9%84/
http://wiki.hash.kr/index.php/%EC%A0%95%EB%B3%B4%EC%9D%80%EB%8B%89