Decorator Pattern 데코레이터 패턴(Decorator pattern)이란 주어진 상황 및 용도에 따라 동적 혹은 정적으로 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있습니다. 여기서 동적으로 추가할 때는 보통 특정 객체를 결합하는 방식을 사용합니다. Class Diagram (클래스 다이어그램) Abstract Decorator (추상 데코레이터) 클래스 이 클래스는 Component 객체를 참조하는 참조 변수 (component)를 유지합니다. 모든 요청을 이 참조된 객체로 전달합니다 (component.operation()). 이로써 Decorator는 Component의 클라이언트에게 투명하게(보이지 않게) 동작합니다..

Publishers + Subscribers = Observer Pattern 옵저버 패턴(Observer Pattern)은 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의합니다. 1. Class Diagram (클래스 다이어그램) Subject 클래스는 의존 객체(dependent objects)의 상태를 직접적으로 업데이트하지 않습니다. 대신, Subject는 Observer 인터페이스의 메서드 update()를 참조하여 상태를 업데이트합니다. 이렇게 함으로써 Subject는 의존 객체의 상태가 어떻게 업데이트되는지에 독립적이게 됩니다. Observer1과 Observer2 클래스는 Observer ..

* 이 글은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. 고수준 모듈이 저수준 모듈에 의존하는 경우 이러한 고수준 모듈을 다른 맥락에서 재사용하기가 매우 어려워집니다. 그러..

* 이 글은 Agile Software Development, Principles, Patterns, and Practices - Robert Martin 책 내용을 번역 및 요약하여 작성하였습니다. The Interface-Segregation Principle 이 원칙은 "두꺼운(fat)" 인터페이스의 단점에 대처하기 위한 원칙입니다. "두꺼운" 인터페이스를 가진 클래스란, 인터페이스가 그 인터페이스를 구현한 클래스와 연관성이 없는 클래스를 말합니다. ISP는 연관성이 없는 인터페이스가 필요한 객체가 있음을 인정하지만, 이러한 객체들에 대한 클라이언트가 하나의 클래스로 이해하면 안된다고 말합니다. 대신 클라이언트는 연관성 있는 인터페이스를 갖는 추상 기본 클래스를 알아야 합니다. Interface P..

* 이 글은 Agile Software Development, Principles, Patterns, and Practices - Robert Martin 책 내용을 번역 및 요약하여 작성하였습니다. LSP: The Liskov Substitution Principle OCP(개방-폐쇄 원칙)의 주요 메커니즘은 추상화(abstraction)와 다형성(polymorphism)입니다. C++ 및 Java와 같은 정적으로 형식화된 언어에서는 이러한 추상화와 다형성을 지원하는 주요 메커니즘 중 하나가 상속(inheritance)입니다. 상속을 사용함으로써 우리는 기본 클래스의 추상 메서드를 구현하는 파생 클래스를 생성할 수 있습니다. 이러한 상속 사용의 특정한 디자인 규칙과 최상의 상속 계층 구조의 특성을 다루..

* 이 글은 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(개방-폐쇄 원칙)는 프로그램이 추가 변경 사항이 발생하더라도, 연쇄적인 변..

* 이 글은 Agile Software Development, Principles, Patterns, and Practices - Robert Martin 책 내용을 번역 및 요약하여 작성하였습니다. SRP: The Single-Responsibility Principle 왜 책임을 별도의 클래스로 분리하는 것이 중요한가요? 각 책임은 변경의 축이기 때문입니다. 요구 사항이 변경되면 그 변경은 클래스 간의 책임 변경을 통해 나타날 것입니다. 하나의 클래스가 두 개 이상의 책임을 가정하면 해당 클래스가 변경해야 하는 이유가 두 개 이상 발생할 것입니다. 하나의 클래스가 두 개 이상의 책임을 갖는 경우, 이러한 책임들은 서로 결합됩니다. 이때 한 책임에 대한 변경 사항은 클래스가 다른 책임을 충족하는 능력을..

* 이 글은 Agile Software Development, Principles, Patterns, and Practices - Robert Martin 책 내용을 번역 및 요약하여 작성하였습니다. The Agile Alliance 소프트웨어 개발 프로젝트에서 명확한 지침이나 효과적인 접근 방식의 부재로 인해 예측 불가능성, 반복된 오류 및 낭비가 발생합니다. 일정 지연, 예산 증가 및 저품질로 인해 클라이언트는 실망하고, 개발자는 더 많은 노력을 기울일수록 점점 나쁜 소프트웨어를 생산하게 됩니다. 소프트웨어 개발 프로젝트는 몇 가지 제한사항과 결과물만으로는 완벽하다고 볼 수 없습니다. 오류가 계속 발생하면 그 오류를 진단하고 앞으로의 오류를 방지하기 위해 더 많은 제한사항과 결과물을 도입합니다. 많은..