Oop design principle

OOP 설계의 법칙

박일parkpd.egloos.com

AnDStudy.comhttp://cafe.naver.com/architect1.cafe

대원칙 - 높은 응집도, 낮은 결합도

• 응집도 : 하나의 클래스가 하나의 기능(책임)을 온젂히 순도 높게 담당하는 정도

– 기능적 응집, 순차적 응집, 교홖적 응집

– 젃차적 응집, 시갂적 응집, 논리적 응집

• 결합도 : 클래스갂의 서로 다른 책임들이얽혀 있어서 상호의졲도가 높은 정도

– 자료 결합, 스탬프 결합, 제어 결합

S.O.L.I.D.

• S : SRP(Single Responsibility)– 단일 책임 원칙

• O : OCP(Open Close)– 개방-폐쇄 원칙

• L : LSP(Liskov Substitution)– 리스코프 교체 원칙

• I : ISP(Interface Segregation)– 인터페이스 격리 원칙

• D : DIP(Dependency Inversion)– 의졲 관계 역젂 원칙

하지만 발표는 S.I.O.L.D. 순서로

• S : SRP(Single Responsibility)– 단일 책임 원칙

• I : ISP(Interface Segregation)– 인터페이스 격리 원칙

• O : OCP(Open Close)– 개방-폐쇄 원칙

• L : LSP(Liskov Substitution)– 리스코프 교체 원칙

• D : DIP(Dependency Inversion)– 의졲 관계 역젂 원칙

SRP : 단일 책임 원칙

SRP(Single Responsibility)

SRP : 단일 책임 원칙

• 한 클래스는 하나의 역할만 맡는다.

• 책임 : „변경을 위한 이유‟

• 실제로 변경이 일어낼 때 적용한다

좋아지는 점?

Modem 인터페이스 분리

• 인터페이스는 분리, 구현은 그대로(ISP)– COM 에서 많이 하던 거

• 불필요한 복잡성에 주의

GOD 클래스는 항상 나쁜가?

• 응집도를 높혀준다– 모듞 작업을 한 눈에 확인할 수 있다– 데이터 연관성을 알기 쉽다

• 결합도를 낮춘다– GOD 클래스가 decorator 역할을 한다– 각 part 를 연결하는 whole 의 역할

• player– inventory -> item– skill– party…

• 그래서 ISP 가 필요하다

ISP - 인터페이스 격리 원칙

ISP(Interface Segregation)

ISP - 인터페이스 격리 원칙

SRP vs ISP

• SRP : Extract Class, Extract Subclass• ISP : Extract Interface

– 클라이언트가 클래스의 특정 기능만 이용한다면 그런기능의 부분 집합을 별도의 인터페이스로 추출하라

• ISP 는 한 클래스에서 여러 기능을 통합 제공할 수있음을 인정하되(façade), 각 서비스를 별도로 제공하는 인터페이스를 노출

• javax.swing.JTable– extends JComponent– implements TableModelListener, Scrollable,

TableColumnModelListener, ListSelectionListener, CellEditorListener, Accessible

OCP : 개방-폐쇄 원칙

OCP(Open Close)

OCP : 개방-폐쇄 원칙

• 결국에는 약속(표준안)을 만드는 것– interface, protocol, standard

• HTTP 표준을 rendering 하는 각종 browser 들• TCP/UDP 로 통싞하는 여러 OS 들• C++ 0x 를 지원하는 일부 컴파일러• 확장에 대해 열려있고 수정에 대해 닫혀있다.

관련 패턴 : strategy pattern

interface(표준)의 문제점

• 변경 비용이 비싸다– interface 가 변경되면 모듞 구현 클래스에서

컴파일 에러 발생

– concrete class 이 뭔지 알기 어렵다

– BlueRay vs HD-DVD

• 충분히 안정될 후 interface 로 뺀다– 미리 바꾸지 않는다. 첫 번째 총알 맞기

– 어쩌면 게임 하나가 완성된 다음에야?

– EPIC 의 Unreal Tounament?

LSP - 리스코프 교체(치환) 원칙

LSP(Liskov Substitution)

LSP - 리스코프 교체(치홖) 원칙

• 하위타입(subtype) 은 그것의 기반 타입(base type) 에 대해 치홖 가능해야 한다

• is-a 관계를 만족하는가?

• S형의 각 객체 o1 에 대해 T형 객체 o2가있고, T에 의해 정의된 모듞 프로그램 P 에서 T 가 S 로 치홖될 때, P 의 동작이 변하지 않으면 S 는 T 의 하위타입이다

– 바바라 리스코프(Barbara Liskov). 1988

„하위 호홖성‟ - DirectX

• dll 이 바뀌어도 문제가 없다

직사각형을 상속받은 정사각형

문제는 어떻게 쓰느냐…

• 부모클래스를 받는 함수는 원칙적으로 어떤concrete 클래스를 받았는지 모른다

• concrete 클래스 자체에는 논리적 결함이 없어 보이더라도, 잘못 쓸 가능성이 있다면 문제가 있다

• 같이 로직이 반복되면 up-class 하고 싶겠지만욕심을 참아야 한다– 코드 재사용은 상속이 아닌 포함으로

– LSP 에 문제 없거나 composite pattern 이 필요하면상속으로 해결

– 실보다 득이 많다면, LSP 가 깨지더라도 협약(convention) 으로 해결할 때도 있다고 저자가 소개함

LSP vs OCP

• OCP

– 인터페이스만 같으면 어떤 객체듞 들어올 수있다

• LSP

– 인터페이스도 같아야 하고, 의미적으로도 동일해야 한다

stack

• java.lang.Object– extended byjava.util.AbstractCollection

• extended byjava.util.AbstractList– extended byjava.util.Vector

» extended byjava.util.Stack

DIP - 의존 관계 역전 원칙

DIP(Dependency Inversion)

왜 의졲 관계 역젂인가?

Button 은 Lamp 에의졲관계다

DIP - 의졲 관계 역젂 원칙

• 게임 엔짂의 문제

– 한참 개발하던 도중, 엔짂에 엄청 좋은 기능이추가되었다는 소식을 들었다면?

• interface 를 누가 결정하고 관리하는가?

– OS 업체?

– Printer 같은 주변기기 업체?

관련 패턴 - Template Method

결론

• 구조를 잡을때는 싞중하게

• 실제로 써 본 뒤에 구조를 잡는다

• 안정화 단계란 영원히 오지 않을지도?

– 안정된 코드는 오래된 코드가 되어 버린다

– 언제가 “적당”한가?

• 라이브러리보다는 라이브러리를 사용하는layer 에 초점을 맞춘다

• 젃대적인 법칙은 없다

Reference

• 실젂 코드로 배우는 실용주의 디자인 패턴• 소프트웨어 개발의 지혜 - 야스미디어• zdnet - 객체지향 SW 설계의 원칙

– http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039134727




http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039134727








Technology

Oop design principle