객체지향 설계: Difference between revisions
From IT Wiki
No edit summary |
No edit summary |
||
Line 7: | Line 7: | ||
;Single Responsiblity Principle; SRP | ;Single Responsiblity Principle; SRP | ||
* 소프트웨어의 컴포넌트는 단 하나의 책임만을 가져야 한다. | * 소프트웨어의 컴포넌트는 단 하나의 책임만을 가져야 한다. | ||
==== 예시 ==== | |||
; AS-IS | |||
* 자동차 Class | |||
** 자동차 모델, 차대번호 등 고정 정보 | |||
** 자동차 오일 상태, 외관 상태 | |||
; TO-BE | |||
* 자동차 Class | |||
* 자동차 상태 Class | |||
=== 개방 폐쇄 원칙 === | === 개방 폐쇄 원칙 === | ||
Line 12: | Line 20: | ||
* 확장에 대해선 열려 있어야 하고 수정에 대해선 닫겨 있어야 한다. | * 확장에 대해선 열려 있어야 하고 수정에 대해선 닫겨 있어야 한다. | ||
* 기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수 있도록(Open) 해야 한다. | * 기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수 있도록(Open) 해야 한다. | ||
==== 예시 ==== | |||
* 자동차 Class | |||
** method drive() | |||
* 변경엔 폐쇄: method drive() to method fly() '''(X)''' | |||
* 확장은 허용: override drive() { additional function } '''(O)''' | |||
=== 리츠코프 치환 원칙 === | === 리츠코프 치환 원칙 === | ||
;Liskov Substitution Principle; LSP | ;Liskov Substitution Principle; LSP | ||
* 자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다. | * 자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다. | ||
==== 예시 ==== | |||
=== 인터페이스 분리의 원칙 === | === 인터페이스 분리의 원칙 === |
Revision as of 19:23, 26 January 2020
- Object Oriented Designing; Object Oriented Architecting
5원칙
- 줄여서 SOLID라고 부른다.
단일 책임 원칙
- Single Responsiblity Principle; SRP
- 소프트웨어의 컴포넌트는 단 하나의 책임만을 가져야 한다.
예시
- AS-IS
- 자동차 Class
- 자동차 모델, 차대번호 등 고정 정보
- 자동차 오일 상태, 외관 상태
- TO-BE
- 자동차 Class
- 자동차 상태 Class
개방 폐쇄 원칙
- Open Close Principles; OCP
- 확장에 대해선 열려 있어야 하고 수정에 대해선 닫겨 있어야 한다.
- 기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수 있도록(Open) 해야 한다.
예시
- 자동차 Class
- method drive()
- 변경엔 폐쇄: method drive() to method fly() (X)
- 확장은 허용: override drive() { additional function } (O)
리츠코프 치환 원칙
- Liskov Substitution Principle; LSP
- 자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다.
예시
인터페이스 분리의 원칙
- Interface Segregation Principle; ISP
- 자신이 사용하지 않는 메서드는 구현하지 않도록 해야 한다.
- 이런 경우 인터페이스는 쪼개져야 한다.
- 하나의 일반적인 인터페이스 보단 여러 개의 구체적인 인터페이스가 낫다.
의존관계 역전의 원칙
- Dependency Inversion Principle; DIP
- 의존 관계를 맺을 때, 변화하기 쉬운것 보단 변화하기 어려운 것에 의존해야 한다.
- 고차원의 모듈은 저차원의 모듈에 의존하면 안된다. 이 두 모듈 모두 다른 추상화된 것에 의존 해야 한다.
- DIP를 만족한다는 것은 의존관계를 맺을 때, 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺는다는 것을 의미