UML로 정리한 Design Pattern 2024-07-06 Korean
•
0 likes•29 views
디자인 패턴은 익히기 어려운 편이다. 쓰지 않으면 잊어버리기 쉽상이다. 따라서 UML class diagram으로 정리해 놓으면 이해도 잘 되고, 기억도 오래 남으리라 생각한다.
Report
Share
UML로 정리한 Design Pattern 2024-07-06 Korean
- 1. UML로 정리한 Design Pattern 수정일자: 2019-06-17 작성자: 황대영
- 2. 목차 • Design Pattern • Creational • Structural • Behavioral • Reference
- 3. Design Pattern • 정의: 일반적인 설계문제를 해결하기 위하여 짜여진 상호 협력하는 객체들과 클 래스들에 대한 기술 • 사용 이유: 설계에 관한 의사소통 • 기대 효과 • 융통성 있는 설계의 재사용 • 코드를 일반화 • 다른 클래스에 의존하는 것을 최소화 • 모듈화 된 설계 • 신뢰성 있는 부품을 재사용
- 4. 설계의 품질 • 나쁜 설계의 냄새 • 경직성 • 부서지기 쉬움 • 부동성 • 끈끈함 • 쓸데 없이 복잡함 • 필요 없는 반복 • 불투명성 • 스파게티 코드
- 5. 객체지향설계 5대 원칙 • Single Responsibility Principle • 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐 이어야 한다. • Open-Closed Principle • Interface에 대해서는 개방되어야 하지만, 변경에 대해서는 폐쇄되어야 한다. • Liskov Substitution Principle • 서브타입(Sub Type)은 언제나 자신의 기반 타입(Base Type)으로 교체할 수 있어야 한다. • Interface Segregation Principle • 클라이언트는 자신이 사용하지 않는 메서드는 의존 관계를 맺으면 안된다. • Dependency Inversion Principle • 고차원의 모듈은 저차원의 모듈에 의존하면 안된다.
- 7. Factory Method 이유: 생성부가 너무 복잡함 해결책: 객체 생성부를 따로 클래스로 뺀다.
- 8. Abstract Factory 이유: 생성부가 너무 복잡함 해결책: Factory Method와 유사해 보이지만 추상화된 factory 클래스를 상속 받아 생성부 클래스를 구현한다.
- 9. Builder 이유: 함수의 인자가 너무 많다. 해결책: 함수의 여러 인자를 클래스로 빼서 객체를 생성한다.
- 10. Prototype 이유: 똑같은 객체를 생성하는 코드가 있다. 해결책: new가 아닌 clone() 메서드로 객체 복제
- 11. Singleton 이유: 두 개 이상 생성할 필요도 없고 그래서는 안 되는 상황 해결책: 오로지 하나만 존재 주의사항: 멀티 스레드 처리 시에 동기화 필요
- 12. Structural
- 13. Adaptor 이유: JSON이 아닌 XML 데이터가 있어서 혼란스러울 때 해결책: 전원 아답터를 생각하면 이해하기 편하다. 맞는 아답터를 설정해서 레이어 하나를 더 생성한다.
- 14. Bridge 이유: 클래스 관계 복잡함. 강결합 되어 있음. 코드를 사용하는 Client와 실제로 사용할 클래스 간에 레이어를 하나 둔다.
- 15. Composite 이유: 몬스터 클래스 (모든 걸 혼자서 다하는) 난무함 해결책: 컴포넌트, 구성품으로 보면 될 것이다. 이 컴포넌트를 여러 개 모아서 객체를 만든다.
- 16. Decorator 이유: 지나치게 복잡하고 많은 상속 관계 해결책: 피자에 올리는 토핑을 decorator라고 이해하면 쉽다. Composite와 유사하다.
- 17. Facade 이유: 알아야 할 클래스가 너무 많다. 해결책: Client 코드에서 복잡한 클래스 관계에 접근하지 않도록 중간 창구를 만든다.
- 18. Flyweight 이유: 지나치게 많은 멤버 변수들 해결책: Context는 가벼운 클래스 하나를 가지고 있어 부하를 줄인다.
- 19. Proxy 이유: 예를들어 느린 DB 전송 해결책: 여기서 말하는 프록시는 프록시 서버의 그것과 유사하다. 중계자이고 권한을 가지고 접근 제한을 할 수 있다.
- 20. Behavioral
- 21. Chain of Responsibility 이유: 요청하는 객체와 처리하는 객체 사이의 결합도가 높음 해결책: 요청을 해결하는 객체를 만날 때까지 객체 고리를 따라서 요청을 전달
- 22. Command 이유: 이벤트가 발생했을때 실행될 기능이 다양함 해결책: 실행될 기능 또는 명령을 캡슐화
- 23. Iterator 이유: 리스트 객체와 방문하는 프로세스 사이의 결합도가 높음 해결책: 반복을 집합의 요소를 포인트하는 객체 안에 캡슐화
- 24. Mediator 이유: 부품 객첵들 간의 강결합 해결책: 각 부품 객체들간의 상호작용을 도맡아 처리하는 객체를 둔다.
- 25. Memento 이유: 객체의 상태를 저장해두었다가 복원해야 할 경우 해결책: 객체의 아이디를 기억하고 있고 꺼내 쓴다.
- 26. Observer 이유: 통보하는 쪽과 통보 받는 쪽의 결합도가 높음 해결책: 객체 상태의 변화가 다른 의존 객체에 통지되고 자동으로 업데이트
- 27. State 이유: 상태에 따라 if문이 많아지고 상태가 많아지면 객체의 구현이 복잡해짐 해결책: 열거체로 정의해서 쓰는 것이 아니라 상태 별로 클래스를 따로 생성해서 쓴다.
- 28. Strategy 이유: 클라이언트와는 독립적으로 알고리즘 변경 필요 해결책: 같은 기능을 하지만 알고리즘이 다른 클래스를 생성한다. 그래서 이를 바꿔서 설정할 수 있다.
- 29. Template Method 이유: 구체적인 구현은 다르나 기본적인 골격이 비슷한 클래스들 해결책: 템플릿처럼 하나의 추상 클래스를 생성해서 상속 받아 구현한다.
- 30. Visitor 이유: 객체의 구조와 기능 분리 필요 해결책: 데이터 구조 안을 돌아다니는 “방문자 객체＂를 준비해서 그 객체에게 처리를 맡김
- 31. Reference • https://refactoring.guru/ • KOSTA EDU 자바 디자인패턴
- 32. 감사합니다