Learn
-
[Design Pattern] Mediator PatternLearn/Architecture 2022. 8. 29. 00:41
# 개요 다양한 객체들의 커뮤니케이션을 Encapsulation하는 패턴 예시 각 비행기들은 서로 직접 통신하지 않고 Mediator인 관제탑을 통해서 통신한다. 일반화하면 다음과 같다. Colleague들은 각각의 함수를 가지고, 상태가 변하면 Mediator에 알려준다. Colleague들은 서로 메시지를 직접 주고받지 않는다. # Mediator Pattern Mediator을 중심으로 상호작용한다. 클래스들간의 커플링을 낮춰준다. colleague들이 많이 생겨도 이해가 쉽다. mediator는 어플리케이션에 종속적일 수 밖에 없으므로 재사용이 힘들다. # QUIZ 다음 중 Mediator Pattern의 시퀀스 다이어그램으로 잘못된 것은? 정답 d. Colleague간에 직접 커뮤니케이션이 일어..
-
[Design Pattern] State PatternLearn/Architecture 2022. 8. 29. 00:26
# 개요 객체가 내부적인 상태(state)에 따라 다르게 행동해야 할 때 사용하는 패턴 UML의 state machine diagram을 구현할 때 가장 적합한 패턴 state에 따라 다르게 행동하도록 구현하는 가장 단순한 방법은 conditional statement를 쓰는 것이다. public class GumballMachine { final static int SOLD_OUT = 0; final static int NO_QUARTER = 1; final static int HAS_QUARTER = 2; final static int SOLD = 3; int state = SOLD_OUT; int count = 0; public GumballMachine(int count) { this.count ..
-
[Design Pattern] Iteration PatternLearn/Architecture 2022. 8. 28. 14:41
# 개요 비슷한 기능을 하는 코드인데 자료구조가 달라서 동일한 방식으로 핸들링이 안되는 경우가 있음 자료구조를 노출하지 않으면서 aggregate object의 element에 접근할 수 있도록 하기 위한 패턴 ※aggregate object: 하나의 오브젝트 안에 다른 오브젝트가 포함된 것. (container 혹은 collection라고 불림) 예시 아래와 같이 MenuItem을 정의했을 때 public class MenuItem { String name; String description; boolean vegetarian; double price; public MenuItem (String name, String description, boolean vegetarian, double price )..
-
[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) 클래스는 단 하나의 변화할 이유(책임)만 있어야 한다. 책임이란? - 해야하는 일 - 많으면 많을수록 더 자주 변한다 > 버그가 생길 확률이 높아진다..