본문 바로가기

ComputerScience/DesignPattern

 (18)
[DesignPattern] Singleton Pattern 싱글톤 패턴 (Singleton Pattern) Singleton 패턴은 소프트웨어 디자인 패턴 중 하나로, 클래스의 인스턴스화를 단일 인스턴스로 제한하는 소프트웨어 디자인 패턴입니다. "Gang of Four" 디자인 패턴 중 하나로, 객체 지향 소프트웨어에서 반복적으로 발생하는 문제를 해결하는 방법을 설명합니다. 이 패턴은 시스템 전체에 걸쳐 작업을 조정해야 할 때 유용합니다. Singleton 패턴을 사용하면 객체가 다음을 수행할 수 있습니다. 1. 하나의 인스턴스만 가지도록 보장 2. 해당 인스턴스에 쉽게 액세스 3. 인스턴스의 생성을 제어 (예: 클래스의 생성자를 숨김) 이 용어는 수학적인 개념인 'singleton'에서 유래되었습니다. 싱글톤은 종종 global 변수와 비교하여 선호되는데, 그..
[DesignPattern] Factory Pattern과 Factory Method, Abstract Factory 차이 (+피자가게 예시) Factory Pattern 새로운 객체가 필요한 곳마다 new를 사용하여 구상 클래스를 코딩하면, 나중에 코드를 수정해야 할 가능성이 커지고 유연성이 떨어집니다. 디자인 패턴을 적용하지 않은 코드 예시를 보겠습니다. public class DependentPizzaStore { public Pizza createPizza(String style, String type) { Pizza pizza = null; if (style.equals("NY")) { if (type.equals("cheese")) { pizza = new NYStyleCheesePizza(); } else if (type.equals("veggie")) { pizza = new NYStyleVeggiePizza(); } else i..
[DesignPattern] Decorator Pattern Decorator Pattern 데코레이터 패턴(Decorator pattern)이란 주어진 상황 및 용도에 따라 동적 혹은 정적으로 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있습니다. 여기서 동적으로 추가할 때는 보통 특정 객체를 결합하는 방식을 사용합니다. Class Diagram (클래스 다이어그램) Abstract Decorator (추상 데코레이터) 클래스 이 클래스는 Component 객체를 참조하는 참조 변수 (component)를 유지합니다. 모든 요청을 이 참조된 객체로 전달합니다 (component.operation()). 이로써 Decorator는 Component의 클라이언트에게 투명하게(보이지 않게) 동작합니다..
[DesignPattern] Observer Pattern Publishers + Subscribers = Observer Pattern 옵저버 패턴(Observer Pattern)은 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의합니다. 1. Class Diagram (클래스 다이어그램) Subject 클래스는 의존 객체(dependent objects)의 상태를 직접적으로 업데이트하지 않습니다. 대신, Subject는 Observer 인터페이스의 메서드 update()를 참조하여 상태를 업데이트합니다. 이렇게 함으로써 Subject는 의존 객체의 상태가 어떻게 업데이트되는지에 독립적이게 됩니다. Observer1과 Observer2 클래스는 Observer ..
[SOLID] DIP: The Dependency-Inversion Principle * 이 글은Agile Software Development, Principles, Patterns, and Practices - Robert Martin 책 내용을 번역 및 요약하여 작성하였습니다. DIP: The Dependency-Inversion Principle a. High-level modules should not depend on low-level modules. Both should depend on abstractions. b. Abstractions should not depend on details. Details should depend on abstractions. 고수준 모듈이 저수준 모듈에 의존하는 경우 이러한 고수준 모듈을 다른 맥락에서 재사용하기가 매우 어려워집니다. 그러..
[SOLID] ISP: The Interface-Segregation Principle * 이 글은 Agile Software Development, Principles, Patterns, and Practices - Robert Martin 책 내용을 번역 및 요약하여 작성하였습니다. The Interface-Segregation Principle 이 원칙은 "두꺼운(fat)" 인터페이스의 단점에 대처하기 위한 원칙입니다. "두꺼운" 인터페이스를 가진 클래스란, 인터페이스가 그 인터페이스를 구현한 클래스와 연관성이 없는 클래스를 말합니다. ISP는 연관성이 없는 인터페이스가 필요한 객체가 있음을 인정하지만, 이러한 객체들에 대한 클라이언트가 하나의 클래스로 이해하면 안된다고 말합니다. 대신 클라이언트는 연관성 있는 인터페이스를 갖는 추상 기본 클래스를 알아야 합니다. Interface P..
[SOLID] LSP: The Liskov Substitution Principle * 이 글은 Agile Software Development, Principles, Patterns, and Practices - Robert Martin 책 내용을 번역 및 요약하여 작성하였습니다. LSP: The Liskov Substitution Principle OCP(개방-폐쇄 원칙)의 주요 메커니즘은 추상화(abstraction)와 다형성(polymorphism)입니다. C++ 및 Java와 같은 정적으로 형식화된 언어에서는 이러한 추상화와 다형성을 지원하는 주요 메커니즘 중 하나가 상속(inheritance)입니다. 상속을 사용함으로써 우리는 기본 클래스의 추상 메서드를 구현하는 파생 클래스를 생성할 수 있습니다. 이러한 상속 사용의 특정한 디자인 규칙과 최상의 상속 계층 구조의 특성을 다루..
[SOLID] OCP: The Open–Closed Principle * 이 글은 Agile Software Development, Principles, Patterns, and Practices - Robert Martin 책 내용을 번역 및 요약하여 작성하였습니다. OCP: The Open–Closed Principle Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. 프로그램의 단일 변경으로 인해 종속 모듈에 대한 연쇄적인 변경이 발생하는 경우, 해당 디자인은 경직(Rigidity)의 흔적, 즉 코드의 수정이 어려워지는 경향이 있습니다. OCP(개방-폐쇄 원칙)는 프로그램이 추가 변경 사항이 발생하더라도, 연쇄적인 변..

티스토리툴바