객체지향 설계 편집하기
IT위키
편집을 취소할 수 있습니다. 이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 게시해주세요.
최신판 | 당신의 편집 | ||
1번째 줄: | 1번째 줄: | ||
[[분류:소프트웨어 공학]] | [[분류:소프트웨어 공학]] | ||
;Object Oriented Designing; Object Oriented Architecting | ;Object Oriented Designing; Object Oriented Architecting | ||
== | == 5원칙 == | ||
; 줄여서 SOLID라고 부른다. | |||
=== 단일 책임 원칙 === | |||
;Single Responsiblity Principle; SRP | |||
* 소프트웨어의 컴포넌트는 단 하나의 책임만을 가져야 한다. | |||
==== 예시 ==== | |||
== | ; AS-IS | ||
* 이동체 Class | |||
** drive() | |||
*소프트웨어의 컴포넌트는 단 하나의 책임만을 가져야 한다. | ** fly() | ||
** swim() | |||
; TO-BE | |||
* 자동차 Class { drive() } | |||
* | * 비행기 Class { fly() } | ||
* | * 배 Class { swim() } | ||
* | |||
* | |||
* | |||
''' | === 개방 폐쇄 원칙 === | ||
;Open Close Principles; OCP | |||
* 확장에 대해선 열려 있어야 하고 수정에 대해선 닫겨 있어야 한다. | |||
* 기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수 있도록(Open) 해야 한다. | |||
==== 예시 ==== | |||
* 자동차 Class | |||
** 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를 만족한다는 것은 의존관계를 맺을 때, 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺는다는 것을 의미 |