소프트웨어 설계 원칙

1. 계층 원칙

분류, 일반화, 대체, 배치 등의 기법을 이용하여 추상화의 계층적인 조직을 생성하기 위한 원칙

 

2. 단일 책임 원칙

한 클래스에 책임이 여럿 있으면 각 책임과 추상화에 대해 이해하는데 시간이 걸린다. 또한 변경과 개선에 있어서 어떤 멤버 변수를 변경해야 하는지 파악하기 힘들다. 즉 유지보수 또한 어렵게 된다. 따라서 한 클래스에서는 하나의 책임을 가지는 원칙

 

3. LSP 원칙

 부모 클래스의 인스턴스가 사용된 자리에 자식 클래스의 인스턴스를 집어 넣어도 코드의 맥락이 변하지 않아야 한다는 원칙

 

4. OCP 원칙

모듈은 확장에서는 열어야 하지만, 변경에서는 닫아야 한다는 원칙

모듈은 코드 변경 없이 새로운 요구 사항을 지원할 수있어야 한다. 즉 코드 수정 없이 클래스를 확장하는 방식을 사용해야 한다는 원칙

 

5. 모듈화의 원칙

지역화, 분해 등의 기법을 사용하여 응직렵이 높고 결합도가 낮은 추상화 생성을 하는 원칙

-다른 클래스의 변화에 민감하지 않으며 재사용이 가능하기 위한 원칙 

 

6. 비순환 의존성의 원칙

특정 클래스나 패키지에 변경이 일어나면  순환 고리에 있는 다른 클래스들도 변경해야 하는 일을 방지하기 위해서

클래스나 패키지 사이의 직간접적인 순환 발생을 회피하자는 원칙

 

7. 캡슐화 원칙 

추상화의 세부 구현과 변형을 감추는 방식으로 관심사 분리와 정보를 은닉한다. 

 

8. 정보 은닉 원칙

설계에서 어렵거나 변경하기 쉬운 부분을 파악하고, 적절한 모듈이나 타입을 생성하여 다른 모듈이나 타입에서 그 부분을 감추는 방식

- 어렵거나 변경하기 쉬운 부분을 수정하였을 때, 프로그램의 다른 부분에서 연쇄적인 변경이 일어나지 않게 막아준다. 즉, 소프트웨어의 설계의 변경 가능성과 확장 가능성을 개선한다.

 

9. 추상화의 원칙

불 필요한 세부사항을 제거하고, 중요한 공통 특징을 파악하고 명세하여 추상화한다.

 

10. Keep It Simple Silly 원칙

아주 단순하게 만들어 의존성이 없게 만들거나 아주 복잡하게 만들어 의존성이 없게 만드는 원칙