상세 컨텐츠

본문 제목

Design Pattern

Python

by techbard 2016. 5. 17. 10:30

본문

반응형

http://python-3-patterns-idioms-test.readthedocs.io/en/latest/PatternConcept.html


So the goal of design patterns is to isolate changes in your code. If you look at it this way, you’ve been seeing some design patterns already in this book. For example, inheritance can be thought of as a design pattern (albeit one implemented by the compiler). It allows you to express differences in behavior (that’s the thing that changes) in objects that all have the same interface (that’s what stays the same). Composition can also be considered a pattern, since it allows you to change-dynamically or statically-the objects that implement your class, and thus the way that class works.


Another pattern that appears in Design Patterns is the iterator, which has been implicitly available in for loops from the beginning of the language, and was introduced as an explicit feature in Python 2.2. An iterator allows you to hide the particular implementation of the container as you’re stepping through and selecting the elements one by one. Thus, you can write generic code that performs an operation on all of the elements in a sequence without regard to the way that sequence is built. Thus your generic code can be used with any object that can produce an iterator.


Classifying Patterns

The Design Patterns book discusses 23 different patterns, classified under three purposes (all of which revolve around the particular aspect that can vary). The three purposes are:


Creational: how an object can be created. This often involves isolating the details of object creation so your code isn’t dependent on what types of objects there are and thus doesn’t have to be changed when you add a new type of object. The aforementioned Singleton is classified as a creational pattern, and later in this book you’ll see examples of Factory Method and Prototype.


Structural: designing objects to satisfy particular project constraints. These work with the way objects are connected with other objects to ensure that changes in the system don’t require changes to those connections.


Behavioral: objects that handle particular types of actions within a program. These encapsulate processes that you want to perform, such as interpreting a language, fulfilling a request, moving through a sequence (as in an iterator), or implementing an algorithm. This book contains examples of the Observer and the Visitor patterns.


"""


:패턴 분류


1. 생성 그룹

- 새로운 객체 유형을 추가해도 객체 생성과 관련된 코드 변경은 최소화

- 싱글톤, 팩토리 메써드, 프로토타입 패턴


2. 연결 그룹

- 연결된 객체 간의 관계를 통해 구현된 내용이 시스템이 바뀌어도 그 관계를

  변경하지 않아도 됨


3. 동작 그룹

- 특정한 동작을 담당하는 객체가 있을때 변경 사항 때문에 객체를 변경하지

  않아도 됨

 - 옵저너, 비지터 패턴


"""


"""

Design Patterns


- Same problem yields same solution with minimal midofication of code

- Same problem yields different solutions with unnecessarily extensive modification of code


Benefits of Promoting Consistency


- Decrease in errors

- Increase in detecting errors

- Cost savings


: No need to reinvent the wheel and waste your time


Scaling Up


Software architecture

- Identifying a pattern to be used throughout software consistently


Frameworks

- A collection od design patterns

- Software security

- Web


Coupling and Cohesion


Coupling

- The degree to which your software elements are connected


Cohesion

- The degree of independence


Simplicity and Generality Trade-Offs


Wider adoption

- More functionality

- Too complex


Simplicity

- Learning curve

- Practitioners

"""








"""

Factory: 객체 생성의 캡슐화


- 객체를 생성하는 부분을 한 곳으로 모은다.

- 만일 코드 전체에 객체를 생성하는 코드가 퍼져있다면

- 새로운 타입을 추가할때마다 전체 코드를 뒤져서

- 새로운 타입이 어떤 영향을 줄 것인지 확인해야 할 것


- 해결책은 코드 전체에 생성하는 코드를 두지 말고

- 공통의 팩토리에서만 객체를 생성하도록 강제하는 것


- 시스템 내의 모든 객체 생성 코드가 이 팩토리를 쓰도록 강제한다면

- 새로운 객체 추가는 팩토리 변경으로만으로도 가능하다.

"""


































Decorator


-    New features to an existing object

-    Dynamic changes

-    Not using subclassing



















반응형

관련글 더보기

댓글 영역