서문에:
학습 과정에서는 기술을 숙련되게 장악하는 것뿐만 아니라, 이론의 소화 흡수도 필수적입니다. 개인적으로는 기술적인 것을 배우는 것을 선호합니다 (단시간의精力 투입으로 곧 성과를 볼 수 있습니다...). 하지만 많은 선배의 경험 요약을 보고 나서야 이론적인 것은 절대 무시할 수 없다는 것을 알게 되었습니다. 이론은 실천에 중요한 지도 의미를 가지기 때문입니다. 「설계」관련 내용을 이해하는 것은, 「구현」에 대해 잠재적인 영향을 미칩니다. 단시간에 기쁜 변화를 볼 수는 없지만, 어느 날 뒤돌아보면「哦~, 原来我这个不错的小习惯은当年 그 책에서 배운 것이구나」라고 생각할 수 있습니다
一。디자인 패턴이란 무엇인가?
한 바퀴 돌아서 다시 이 주제로 돌아갑시다 (책을 읽기 전에 자신에게 한 번 묻고, 읽은 후 다시 자신에게 한 번 묻습니다.答え의 차이가 感悟입니다)
이전:
자문:디자인 패턴이란 무엇인가?
자답:시스템 설계의 지도 원칙이겠죠. 하지만 저는 매일 코드를 쓰고 있으니, 설계 레벨의 것은 필요 없을 것입니다.
자문:哦, 그럼 구체적으로 무엇인가?
자답:清楚하지 않습니다. 하지만 선배의 코드를 본 적이 있습니다. 구조가 매우 복잡하고,一看就很上档次的那种. 그것은 디자인 ���턴을 사용한 것이겠죠. 그러니 코드가 디자인 패턴을 적용했는지 여부가高手와 초보자의 차이일 것입니다. 제가高手가 되면,这种东西还不信手拈来。嗯，不说了、코드를 쓰러 갑니다. 프로젝트 경험을 잘 쌓겠습니다.
이후:
자문:디자인 패턴이란 무엇인가?
자답:디자인 패턴은 코드 구조 최적화 경험에서 추출된 이론 지식입니다. 성숙한 디자인 패턴을 적용하면 코드의 재사용성, 확장성, 유지보수성을 강화할 수 있습니다.
자문:매우 전문적으로 보이는군요. 좋습니다. 디자인 패턴에这么多장점이 있다면, 디자인 패턴을 적용한 설계는 모두 좋은 설계입니까?
자답:물론 아닙니다. 패턴을 사용하기 위해 패턴을 사용해서는 안 됩니다. 디자인 패턴은 남용해서는 안 됩니다. 디자인 패턴을 적용하려면 반드시 몇 가지 희생을 치러야 합니다 (예를 들어 클래스 구조의 복잡성을 증가시키는 등...). 그러니 디자인 패턴을 남용하면 문제가 생깁니다. 게다가, 망치를 가져도 모든 문제를 못으로 볼 수는 없겠죠?
P.S. 정규식을 배운 요약을 기억하십니까: 사용하지 않아도 되면 최대한 사용하지 않기 (최대한 남용을 피하기). 디자인 패턴도 이와 유사합니다.什么问题도 패턴에 기대어서는 안 됩니다. 현재 상황에서 확실히 디자인 패턴으로 설계를 최적화할 필요가 있다고 매우 확신할 때에만, 디자인 패턴 사용을 고려합니다 (사용할지 말지는, 리팩토링 비용과 최적화 수익을衡量해야 합니다...)
二。디자인 패턴을 사용해야 하는가?
이는 생각할 가치가 있는 문제입니다. 지금 우리는 망치를 가지고 있습니다. 그것을 사용해야 하는지는 문제가 됩니다. 모든 문제가 망치로 해결될 수 있는 것은 아니기 때문입니다. 한 발 양보해서, 모든 문제가 망치로 해결될 수 있다고 해도, 망치를 사용하는 것이 최선의 해결책인지 확신할 수 없습니다 (못을 뽑는다면, 펜치가 더 나을지도 모릅니다...)
어떤 디자인 패턴을 코드에 넣으려 할 때,最好는利弊를衡量しましょう. 확실히, 디자인 패턴이 가진 설계상의 탄력성은 이후의 유지 변경에 몇 가지 편리함을 가져옵니다. 하지만 이익과 단점 중 어느 쪽이 더 많은지는, 몇 가지 질문에 답한 후 결정해야 합니다:
- 우리의 프로젝트는 거의 유지와 관련이 없거나 후속 버전이 없다면, 디자인 패턴을 도입할 필요가 있습니까?
- 우리 프로젝트의 규모는 디자인 패턴을 사용하지 않으면 안 될 정도로 큽니까?
- 이 디자인 패턴은 여기서 사용하는 데 적합합니까? 더 적합한 것은 없습니까?
- 반드시 디자인 패턴을 사용해야 합니까? 몇 가지 간단한 설계 원칙으로 대체할 수 없습니까?
- 디자인 패턴을 도입한 후, 코드 구조의 복잡도가 크게 증가합니다. 리팩토링 비용을 받아들일 수 있습니까?
깊이 생각한 후, 여전히 디자인 패턴을 사용하는 것이 좋다고 생각한다면, 안심하고 사용하세요. 그 후 디자인 패턴이 가져오는 이점을 즐기세요
三。설계 원칙 요약
설계 원칙은 모두 간단한 지도 의견으로, 고정된 구현이 없습니다. 따라서 설계 원칙은 더 유연합니다. 일반적인 설계 원칙은 다음과 같습니다:
- 변화를 캡슐화하라 (변하기 쉬운 부분을 추출하여 다른 부분에 대한 영향을 줄인다)
- 상속보다 컴포지션을多用하라 (컴포지션은 상속보다 탄력성이 있다)
- 인터페이스에 대해 프로그래밍하고, 구현에 대해 프로그래밍하지 말라 (인터페이스를 사용하면 구체적인 클래스에 대한 직접 의존을 피할 수 있다)
- 상호작용 오브젝트 간의 느슨한 결합 설계를 위해 노력하라 (더 느슨한 결합은 더 많은 탄력성을 의미한다)
- 클래스는 확장에 대해 열리고, 수정에 대해 닫혀야 한다 (open-close 원칙)
- 추상에 의존하고, 구체적인 클래스에 의존하지 말라 (구체적인 클래스에 대한 직접 의존을 줄인다)
- 친구와만 대화하라 (친우 원칙)
- 나를 부르지 마라, 내가 너를 부르겠다 (Don't call me, I will call you back. 안드로이드 개발의 대원칙)
- 클래스는 변경할 이유가 하나만 있어야 한다 (단일 책임 원칙)
설계 원칙으로 해결할 수 있는 문제는 디자인 패턴을 사용하지 마세요 (닭을 잡는 데 소 잡는 칼을 쓸 필요는 없습니다...). 설계 원칙은 구현이 더 유연하고, 더 가볍기 때문입니다 (패턴의条条框框을 고려할 필요가 없습니다...)
四。디자인 패턴 요약
| 이름 | 특징 |
| 전략 패턴 (Strategy) | 교체 가능한 알고리즘 스텝을 하나씩 알고리즘 패밀리로 캡슐화하여, 실행 시 동적으로 선택 |
| 옵저버 패턴 (Observer) | 오브젝트 간의 1 대 다 관계를 정의하고 유지 |
| 데코레이터 패턴 (Decorator) | 공통 슈퍼클래스를 가진 데코레이터와 피데코레이터를建立하여, 기능의 동적 확장을 실현 |
| 팩토리 패턴 (Factory) | 오브젝트 생성 프로세스를 캡슐화. 팩토리 메서드 패턴과 추상 팩토리 패턴을 포함 |
| 싱글톤 패턴 (Singleton) | 유일한 오브젝트를 생성하는 데 사용 (데이터베이스 연결 오브젝트, 스레드 풀 오브젝트 등) |
| 커맨드 패턴 (Command) | 메서드 호출 상세를 캡슐화. 리퀘스터와 이그제큐터를 디커플링 |
| 어댑터 패턴 (Adapter) | 서로 다른 인터페이스 간 전환을 실현하는 데 사용 |
| 파사드 패턴 (Facade) | 복잡한 서브시스템에 대해 간단하고 사용하기 쉬운 고수준 인터페이스를 제공 |
| 템플릿 메서드 패턴 (Template Method) | 알고리즘의 골격 (플로우) 을 캡슐화하는 데 사용. 몇 가지 스텝은 서브클래스가 구현 |
| 이터레이터 패턴 (Iterator) | 트래버스 상세를 캡슐화하는 데 사용 |
| 컴포지트 패턴 (Composite) | 계층 구조를 제공. 오브젝트와 오브젝트 컬렉션 간의 차이를 무시��고, 일시동인하게 다룰 수 있게 함 |
| 스테이트 패턴 (State) | 모든 액션을 스테이트 오브젝트에 캡슐화. 스테이트 홀더는 동작을 현재 스테이트 오브젝트에 위임 |
| 프록시 패턴 (Proxy) | 제 3 자 (프록시 오브젝트) 를 삽입하여 호출자와 피호출자를 분리 (이그제큐터와는 다름) |
| 복합 패턴 (Compound) | 여러 패턴을 조합하여 1 개의「프레임워크」를 형성하고, 일반적인 문제를 해결 |
| 브릿지 패턴 (Bridge) | 추상적인 제어 클래스와 구체적인 구현 클래스를 컴포지션을 통해 디커플링. 추상층 클래스와 구현층 클래스가 서로에 대해 독립적으로 변화할 수 있게 함 |
| 빌더 패턴 (Builder) | 컴포지션 구조 (트리 구조) 의 구축 프로세스를 캡슐화하는 데 사용. 이터레이터 패턴과 유사하게, 컴포지션 구조의 내부 구현을 은폐하고, 컴포지션 구조를 생성하기 위한 한 조의 인터페이스만 제공 |
| 책임의 사슬 패턴 (Chain of Responsibility) | 하나의 리퀘스트를 한 조의 수신자가 순차적으로 처리할 수 있게 함. Android 의 리퀘스트 처리 방식과 유사: 하나의 수신자가 리퀘스트를 캡처한 후, return true 로 리퀘스트를 소비하거나, return false 로 수신자 큐 중의 다음 수신자 (옵저버) 에게 전달 |
| 플라이웨이트 패턴 (Flyweight) | 오브젝트 관리층을 추상화하여 대량의 동타입 오브젝트를 통일 관리. 실행 시 오브젝트 인스턴스 수를 줄이고, 메모리 소비를 감소 |
| 인터프리터 패턴 (Interpreter) | 심플한 언어를 위해 인터프리터를 생성하는 데 사용. 문법 규칙을 직접 각 클래스에 매핑. 구조는 심플하지만, 효율은 낮음 |
| 메디에이터 패턴 (Mediator) | 메디에이터를 도입하여 여러 오브젝트 간의 복잡한 상호작용을 캡슐화. 동급 (클래스 구조의 통일 레벨상의) 오브젝트 간의 의존을 감소 |
| 멘토 패턴 (Memento) | 오브젝트 스테이트의 저장과 회복을 지원. 오브젝트 스테이트 데이터를 캡슐화하고, 고객 코드로부터 독립하여 보호를 제공 (Java 에서는 시리얼라이제이션·디시리얼라이제이션 기술과 결합하여 이 패턴을 구현 가능) |
| 프로토타입 패턴 (Prototype) | 기존 오브젝트를 프로토타입으로 하고, clone 을 통해 새로운 오브젝트를 취득 (새로운 오브젝트 생성 프로세스를 간소화) |
| 비지터 패턴 (Visitor) | 컴포지션 구조에 새로운 조작을 추가. 컴포지션 구조를 빈번하게 변경할 필요가 없음 |
五。오브젝트 지향 설계 (Object Oriented Design)
OOD 에 항상 동반되는 문제는「절충」(또는「取舍」) 입니다. 가장 심플한 예——디자인 패턴을 사용해야 하는가?
- 사용: 복잡한 클래스 관계, 다층의 추상을 생성함을 의미. 가독성을 희생하여 확장성, 유지보수성或者其他특성을 획득
- 사용하지 않음: 기존 코드를 리팩토링할 필요가 없음 (또는 복잡한 설계에过多의 시간을 소비할 필요가 없음) 을 의미. 하지만 디자인 패턴의 모든 이점을 얻을 수 없음
이중에서 하나를 선택, 이것이「取舍」입니다. 또는 제 3 의 옵션을 생성 (예를 들어 설계 원칙 사용). 이것이「절충」입니다
후기에:『Head First 디자인 패턴』에 대하여
서평을 쓰는 일은 드뭅니다. 사람마다 취향이 다르기 때문에, 추천하기 어렵기 때문입니다 (때로는 책을 좋아하는 것이 저자의 문장 스타일을 좋아하는 것뿐일 수도 있고, 무의식적으로 서적 내용이 좋다고 생각할 수도 있습니다...)
이 책은 선배에게 추천받았습니다. 읽은 후 대부분의 장은 매우 잘 쓰여졌다고 느꼈습니다. 세밀하고 통속적입니다. 하지만 몇몇 장은 그렇게 좋지 않다고 느꼈습니다 (예를 들어 제 1 장 전략 패턴의 예는 그렇게 적절하지 않고, 뒤의 원격 프록시 부분의 상세 전개가不合理한 등)
전체적으로 말하면, 입문 서적으로서, 『Head First 디자인 패턴』은还是不错的. 개인의 감상입니다. 참고용으로
아직 댓글이 없습니다