Learn/Architecture
-
[Design Pattern] Template Method PatternLearn/Architecture 2022. 8. 28. 10:19
# 개요 프레임워크를 구성하는데 사용되는 패턴으로 특별한게 아니고 개발하면서 늘 하던 자연스러운 패턴 공통적인 부분은 상위 클래스에 구현 상위 클래스에 concrete method로 구현 (final을 붙여서 override를 막을 수 있음) --> Encapsulation 하위 클래스마다 달라질 수 있는 부분은 abstract method로 구현 예시 공통적인 부분은 prepareRecipe에 모아서 구현 (template method pattern) 음료 종류에 따라 공통적인 부분만 여기에 정의 음료에 따라 달라지는 부분은 하위 클래스에 구현 public abstract class CaffeineBeverage { final void prepareRecipe() { boilWater(); brew()..
-
[Design Pattern] Observer PatternLearn/Architecture 2022. 8. 27. 22:55
# 개요 한 쪽의 오브젝트가 변화가 있을 때, 다른 오브젝트들이 노티아야 할 때 사용하는 패턴 Observer Pattern은 아래와 같은 상황을 해결하기 위해 사용된다. 아래의 예시에서 WeatherData는 WeatherStation으로부터 날씨 데이터를 받아서 Device에 전달한다. WeatherStation으로부터 날씨 변화를 받기 위해서는 아래 구조에서 measurementChanged 부분을 구현해야 한다. > 날씨 데이터의 구성 요소가 변하는 것에도 대응할 수 있어야 하고 확장성도 고려해야 한다. 이를 위해 아래와 같이 update함수를 고려해 볼 수 있다. 하지만 변수가 늘어나거나 Display에 변경이 있을 때 마다 매번 코드를 수정해줘야 한다. public class WeatherDa..
-
[Design Pattern] Strategy PatternLearn/Architecture 2022. 8. 26. 00:34
# 개요 특정한 상황에서 swap될 수 있는 encapsulate된 알고리즘의 집합 (교수님 무슨말입니까 이게??) > 변경에 더 잘 대처하기 위해 인터페이스를 중심으로 소통하도록 알고리즘들을 encapsulation하는 방식 [예시] - 오리의 울음소리(quack)는 같으며 같은 방식으로 수영한다고 가정 > 공통된 부분이므로 abstract에 구현 - display는 오리마다 다름. > 구현하지 않고 abstract method로 남겨둠 요구사항이 변하지 않으면 위 방식으로 디자인해도 충분히 훌륭하다. 문제는 새로운 behavior인 fly를 새로 정의해야한다면... (요구사항 변경!) > 상위 클래스에 fly를 구현하면 모든 오리가 날게 되어버린다. (심지어 rubber duck도) > rubber ..
-
[Design Pattern] GRASP PrincipleLearn/Architecture 2022. 8. 24. 00:22
General Responsibility Assignment Software Patterns 어떤 클래스에게 어떤 책임을 줘야하는지에 대한 가이드를 제시 # Modularity 좋은 디자인이란 시스템을 모듈별로 잘 나누고 적절한 책임을 부여한 것. 모듈성을 높이려면 1. 비슷한 기능들끼리 잘 묶고 (Sereration of Concerns) 2. 작고 잘 정의된 인터페이스로 서로 잘 연동되지만 내부 내용은 모르게 한다. (Information Hiding) 모듈성을 측정하는 방법은 coupling, cohesion이 많이 쓰인다. Coupling - 모듈간의 상호 의존성 측정 - 낮을수록 좋음 - 높으면 변경에 영향을 받는게 많고 이해가 어려우며 재사용도 어렵다. Cohesion - 하나의 모듈안에 있는..
-
[Design Pattern] SOLID PrincipleLearn/Architecture 2022. 8. 21. 17:04
Design smell : 나쁜 디자인의 징후 --> 잘못된 의존성 때문에 나타남 # SOLID Principle - The Single-Responsibility Principle (SRP) - The Open-Closed Principle (OCP) - The Liskov Substitution Principle (LSP) - The Interface Segregation Principle (ISP) - The Dependency Inversion Principle (DIP) # The Single-Responsibility Principle (SRP) 클래스는 단 하나의 변화할 이유(책임)만 있어야 한다. 책임이란? - 해야하는 일 - 많으면 많을수록 더 자주 변한다 > 버그가 생길 확률이 높아진다..
-
[Design Pattern] Object Oriented ParadigmLearn/Architecture 2022. 8. 20. 22:18
# Abstract Data Type (ADT) - 데이터를 밖으로 노출하지 않고 operation 구현을 보여주지 않는 방식 장점 1. 내부 방식을 바꿔도 클라이언트가 영향을 받지 않음 > 시스템을 관리하고 수정하는데 용이함 장점2. Encapsulation # Object-Oriented Paradigm Class = ADT + Inheritance (reusability) + Polymorphism (flexibility) 클래스 재사용 뿐만 아니라 클라이언트 코드의 재사용도 중요 위 그림을 위의 코드와 같이 코딩하는건 좋은 설계가 아니다. > 새로운 타입이 들어오면 아래와 같이 추가해야되는데 수천 수만개가 들어오면 어렵다. 아래와 같이 코딩해서 클라이언트가 정의하도록 하는게 polymorphic이..
-
[Design Pattern] IntroductionLearn/Architecture 2022. 8. 17. 23:33
# Category of GoF Patterns - Creational: 생성에 관련된 작업을 클라이언트가 직접 갖는게 아니라 다른 객체 주는 것 (new없이도 객체 생성 가능) - Structural: 이미 있는 클래스, 객체를 조합해서 더 복잡하게 만들거나 Structure을 나눠야 하는 경우 - Behavioral: 어떤 클래스가 어떤 책임을 가질 것인가 또는 어떻게 커뮤니케이션 할 것인가를 표현한 패턴 # Key Features of Design Pattern - Pattern name: 패턴 이름 (커뮤니케이션에서 중요) - Intent: 목적 - Problem: 어떤 문제를 해결하려 하는가 - Solution: 문제를 어떤 식으로 해결하는지 서술 - Participants and collabo..