갬장장이
'software engineering/design patterns' 카테고리의 글 목록

software engineering/design patterns

software engineering/design patterns

디자인 패턴을 남용하지 말아야 하는 이유

디자인 패턴은 분명 알아둔다면 많은 도움이 될 수 있다. 또 다른 개발자들과 소통할 때 편리함을 더해주기도 한다. 하지만 모든 상황에서 디자인 패턴을 남용한다면 여러 문제가 발생할 수 있다. 간단히 구현할 수 있는 기능을 지나치게 복잡하게 구현하는 결과를 초래할 수 있고, 무엇보다 디자인 패턴에만 의존하다 보면 사고 자체가 유연해지지 못해 디자인 패턴으로 해결할 수 없는 상황을 마주쳤을 때 문제를 해결할 수 있는 능력을 기르지 못할 수도 있다. 때문에 디자인 패턴은 어디까지나 일종의 가이드라인으로서만 사용하는 것이 좋다.

software engineering/design patterns

State 패턴

목표: 서로 다른 State들에 대해 같은 동작을 실행해야 할 때, 이를 긴 if else if 문으로 실행하는 것보다 더 나은 방법을 찾는 것이 state 패턴의 목표이다. 예시 상황: 포토샵과 유사한 프로그램을 구현한다고 가정해보자. 선택한 tool에 따라 mouseDown(), mouseUp()이 실행될 때마다 다른 결과가 도출되어야 한다. 접근1: if else if 문을 사용한다. package state; public class Canvas { private ToolType currentTool; public void mouseDown() { if (currentTool == ToolType.SELECTION) { System.out.println("Selection MouseDown"); }..

software engineering/design patterns

Memento 패턴

목표: Undo 기능을 구현하기. 이 때 Undo는 여러 차례 연속으로 행할 수 있어야 한다. 예시 상황: Notepad 클래스에 void SetString(String s)과 String GetString()메소드가 있다고 하자. Notepad 클래스에는 String타입의 content라는 변수가 존재하며, Notepad는 한 번에 딱 하나의 String값만을 저장한다고 가정하자. Notepad 클래스에 string을 저장한 후 Undo하는 기능을 추가하려면 어떻게 해야할까? 접근 1: Notepad 클래스에 stringList를 추가하고, 이 List에 SetString()이 실행될 때마다 String정보를 저장한다. Undo() 메소드를 추가하고, 이 메소드가 실행될 때마다 List에서 String..

software engineering/design patterns

UML이란

UML 소프트웨어 구조를 시각화하기 위한 표기방식. Aggression vs Composition Aggression은 연결된 상위 클래스가 사라져도 aggression 관계에 있는 하위 클래스가 독립적으로 존재할 수 있음을 의미한다. Composition은 상위 클래스가 사라지면 composition 관계의 하위 클래스가 사라짐을 의미한다. ex. aggression: Zoo 클래스가 내부에 변수로 Tiger 클래스를 저장하고 있다고 해보자. Zoo가 사라져도 Tiger 클래스는 가 하나의 인스턴스로서 남아있다면 이는 aggression 관계이다. composition: Human 클래스가 내부에 변수로 LeftArm 클래스를 저장하고 있다고 해보자. Human이 지워질 때 LeftArm 클래스도 지워..