[Software Engineering] 디자인 패턴 및 종류

1. 디자인 패턴

• 목적 : 소프트웨어 재사용성, 호환성, 유지 보수성 보장
• 디자인 패턴은 특정한 구현이 아닌 아이디어
• 재사용, 호환, 유지보수 시 발생하는 문제 해결을 예방하기 위해 나타난 패턴

1-1. SOLID 원칙

1. Single Responsibility Principle : 하나의 클래스는 하나의 역할만 해야 함
2. Open - Close Principle : 확장에는 열려있고, 수정에는 닫혀있어야 함
3. Liskov Substitution Principle : 자식이 부모 자리에 항상 교체될 수 있어야 함
4. Interface Segregation Principle : 인터페이스가 잘 분리되어, 클래스가 꼭 필요한 인터페이스만 구현하도록 해야 함
5. Dependency Inversion Property : 상위 모듈이 하위 모듈에 의존 X -> 둘 다 추상화에 의존, 추상화는 세부 사항에 의존 X

1-2. 종류

• Adapter Pattern

클래스를 바로 사용할 수 없는 경우가 존재할 때, 중간에서 변환 역할을 하는 클래스

클래스를 바로 사용할 수 없는 경우는 다른 곳에서 개발했을 때 or 수정할 수 없을 때를 의미

 

• Singleton Pattern

앱이 시작될 때, 어떤 클래스가 최초 한번만 메모리에 할당하고 해당 메모리에 인스턴스를 만들어 사용하는 패턴

-> 반드시 필요한 상황이 아니라면 지양하는 것이 좋음

  Why? 싱글톤이 혼자 너무 많은 일을 하거나 데이터 공유를 시키면 클래스 간 결합도가 높아지는데, 이때 SOLID 원칙인 Open - Close 원칙에 위배 됨, 또한 멀티 스레드 환경에서 동기화 처리를 하지 않을 때 인스턴스가 2개 생성되는 문제 등 여러 문제점들이 생기기 때문

반드시 사용해야 할 땐 위의 조건들을 생각하며 구현을 해야 함

 

• Template Method Pattern

특정 작업을 처리하는 일부분을 서브 클래스로 캡슐화 하여 전체적인 구조는 바뀌지 않으나, 특정 단계에서 수행할 내용을 바꾸는 패턴

-> 로직을 단계별로 나눠야하는 상황에 적용, 단계별로 나눈 로직들이 앞으로 수적될 가능성이 있을 경우 더 효율적

 

• Factory Method Pattern

객체를 생성하는 부분을 Sub-Class에 맡기는 패턴

생성하는 객체를 별도로 두어 그 객체에 넘어오는 값에 따라 각기 다른 객체를 생성하면 됨

 

• Observer Pattern

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가며, 자동으로 정보가 갱신

인터페이스를 통해 느슨한 결합성을 유지

ex> 안드로이드 개발시 OnClickListener가 옵저버 패턴의 예시

 

• Strategy Pattern

어떤 동작을 하는 로직을 정의하고 이들을 하나로 캡슐화하여 관리하는 패턴

새로운 로직을 추가하거나 변경할 때 한번에 효율적으로 변경 가능 -> 독립적으로 관리하는 것이 편해짐

 

• Compositie Pattern

객체의 Hierarchy를 표현하고 각각의 객체를 독립적으로 동일한 인터페이스를 통해 처리할 수 있게하는 패턴

---

참고문서

https://gyoogle.dev/blog/design-pattern/Overview.html

[Design Pattern] 개요 | 👨🏻‍💻 Tech Interview