본문 바로가기

프로그래밍/디자인패턴

디자인패턴

728x90
반응형

일정하게 반복되는 패턴의 프로그래밍 설계

디자인패턴의 목적성과 필요성

- 가독성과 유지보수가 편하다.

- 검증된 패턴을 사용하면 빠르고 높은 완성도의 코드를 구현할 수 있어 비용을 아낄 수 있다.

- 본인 혼자만의 코드가 아닌, 검증되고 널리 알려진 패턴들을 이용한 코드는 협업자로 하여금 이해하기가 쉽다.

- 일반적으로 프로그래밍을 하는 사람마다 코딩 스타일이 너무나도 달라 협업하거나 레퍼런스를 참고하는데 어려움이 있다. 디자인패턴은 이러한 문제를 해결하는데 큰 도움을 준다.

- 또한, 디자인패턴들은 이미 그 성능이 검증된 방법이라 웬만하면 본인이 대충 생각해서 작성한 코드보다는 안정성 면에서 보장되어 있다.

(우리가 겪고 있는 어려움은 대체적으로 다른사람들도 겪었고 그것을 해결하기 위한 방법들을 패턴으로 고안한것이기에.. 그렇다고 너무 디자인패턴을 맹신하진 말자. 문제가 제기되어 계속해서 개선되는 패턴들도 있으니.. (MVC-MVP. . . )

- 참고 사이트에서 보면 패턴을 공부한다는 것은 '숙련된 개발자가 오랜 경험을 통해 발견한 노하우를 배우는 것' 이라고 표현한다.

디자인의 원칙(객체 지향 설계 다섯가지 원칙)

a. 단일 책임 원칙 (Single Responsibility Principle)

- 한 클래스는 하나의 책임만 가져야 한다.

('클린코드' 라는 책에도 '단일 책임 원칙'에 대해서 강조하고 있다. 실제로 한 클래스에 여러가지 기능들이 있으면 해당 클래스의 내용이 길어지고 파악하기가 점점 어려워진다. 협업자들은 알기 어렵고, 한두달 뒤에 봤을때 개발 당사자도 모를 수 있다.)

- 하나의 책임만을 갖기 위해서는 네이밍도 굉장히 중요하다.

- 해당 클래스가 책임지는것에 대하여 명확하게 네이밍을 선정해야 한다.

(if, and, or, but과 같은 단어를 사용하지 않고 25단어 내외가 좋다)

b. 개방-폐쇄 원칙 (Open/Closed Principle)

- 확장은 쉬우나 변경은 어려워야한다.

(대다수의 시스템들은 지속적인 변경이 가해지고 이로 인하여 의도대로 동작하지 않는 위험이 따르게 된다. 게임으로 치면 컨텐츠 업데이트, 폴리싱 등으로 인한 버그가 발생할 수 있다.)

- 보통은 구체적인 클래스와 추상 클래스로 나뉘는데, 구체적인 클래스에 의존하는 클라이언트 클래스는 구현이 바뀌게 될 경우 위험도가 높아진다.

- 인터페이스와 추상클래스를 사용하여 구현으로부터 받을 수 있는 위험을 낮춰야한다.

c. 리스코프 치환 원칙 (Liskov Substitution Principle)

- 상속관계를 생각하면 된다.

예시)

1. 부모 a = new 자식(); // 부모 a가 자식일 수는 없다.

2. 부모 a = new 아버지(); // 부모 a는 아버지일 수 있다.

3. 부모 a = new 할아버지(); // 부모 a는 할아버지일 수 있다.

d. 인터페이스 분리 원칙 (Interface segregation principle)

- 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다

- 어중간하게 범용 인터페이스를 상속 받아서 사용하지도 않는 기능들을 덕지덕지 붙이지 말아야한다.

- 인터페이스에 책임을 분리하여 필요한 인터페이스만 상속 받아 사용해야 한다는 의미.

(범용 인터페이스보다 전용 인터페이스가 낫다)

e. 의존관계 역전 원칙 (Dependency Inversion Principle)

- 고차원 모듈은 저차원 모듈에 의존하면 안된다. 그리고 이 둘 모두 다른 추상화된 것에 의존해야 한다.(사람 홍길동과 직업 의적이 있는데 홍길동은 의적이지만 의적은 홍길동여서는 안된다.)

- 추상화된 것은 구체적인 것에 의존하면 안된다.

(구체적인 클래스에서 추상화된 클래스를 의존해야하는 것이지 반대가 되서는 안된다.)

- 변화가 쉬운(구현부) 것보다 변화하기 어려운(추상) 것에 의존하라는 원칙이다.

패턴의 종류

a. 생성 패턴

- 객체 인스턴스 생성을 위한 패턴

b. 행동 패턴

- 객체들의 상호작용 및 역할을 분담하는 패턴

c. 구조 패턴

- 클래스 및 객체들을 일정한 규칙에 맞는 구조, 큰 틀을 만드는 패턴

d. 객체 패턴

- 객체들의 관계를 다루를 패턴

e. 클래스 패턴

- 클래스 사이의 관계가 상속을 통해서 어떤 식으로 정의되는지를 다루는 패턴

디자인 패턴 참고 출처

 

프로그래밍 디자인 패턴

안녕하세요. 소프트웨어 개발자 김은찬 입니다. 이번주 부터 프로그래밍 디자인 패턴에 대한 게시물을 지속...

blog.naver.com

 

디자인 패턴 (책) - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 《디자인 패턴》(Design Patterns, ISBN 0-201-63361-2)은 소프트웨어 설계에 있어 공통된 문제들에 대한 표준적인 해법과 작명법을 제안한 책이다. 이 분야의 사인방(Gang of Four, 줄여 GoF)으로 불리는 에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides)가 같이 썼고, 한국어 판은

ko.wikipedia.org

디자인의 원칙 참고 출처

 

객체 지향 설계 5원칙 -(1) SRP 「단일 책임 원칙」

「"어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다"」​쉽게 말해 작성된 클래스는...

blog.naver.com

 

 

다람쥐와 포동포동이

 

RememberCook 9월 28일 정식 출시!

두번째 게임인 RememberCook이 출시되었습니다. 귀여운 캐릭터들이 나오는 간단한 게임이며 플레이어의 공간인지능력을 테스트하는 게임입니다. 아래 링크를 통해 다운 받으실 수 있으니 많은 관��

chipmunk-plump-plump.tistory.com

반응형

'프로그래밍 > 디자인패턴' 카테고리의 다른 글

Strategy (스트레티지)  (0) 2020.04.09
FSM (유한 상태 머신)  (0) 2020.04.08
Factory (팩토리)  (0) 2020.04.08
Observer (옵저버)  (0) 2020.04.07
Singleton (싱글톤)  (0) 2020.04.07