취미처럼

옵저버 패턴(observer pattern) 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴 주체란 객체의 상태 변화를 보고 있는 관찰자이며, 옵저버들이란 이 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 추가 변화 사항이 생개는 객체들을 의미한다. 옵저버 패턴은 주로 이벤트 기반 시스템에 사용하며 MVC 패턴에도 사용된다. import java.util.ArrayList; import java.util.List; interface Subject { public void register(Observer obj); public void unregister(Observer obj); public voi..

전략 패턴(strategy pattern) 객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고 전략이라고 부르는 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴 import java.text.DecimalFormat; import java.util.ArrayList; import java.util.List; interface PaymentStrategy { public void pay(int amount); } class CardStrategy implements PaymentStrategy { private String name; private String cardNumber; private String cvv; private String dateOfExpiry; pub..

팩토리 패턴(Factory Pattern) 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이자 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴 상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 가지며 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없기 때문에 더 많은 유연성을 갖게 된다. 또한 객체 생성 로직이 따로 떼어져 있기 때문에 코드를 리팩터링하더라도 한 곳만 고칠 수 있으니 유지 보수성이 증가한다. abstract class Coffee { public abstract int getPrice(); @Override public String toString(){ retur..

싱글톤 패턴(singleton pattern) 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴 하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스를 만들 수 있지만, 그렇게 하지 않고 하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 이를 기반으로 로직을 만드는데 쓰이며, 보통 데이터베이스 연결 모듈에 많이 사용 class Singleton { private static class singleInstanceHolder { private static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return singleInstanceHolder.INSTANCE; } } public class..

DIP ( Dependency Inversion Principle ) - 의존 역전 원칙 객체들이 서로 정보를 주고 받을 때 의존 관계가 형성되는데, 이 때 객체들은 나름대로의 원칙을 갖고 정보를 주고 받아야 한다는 설계 원칙이다. 여기서 나름대로의 원칙이란, 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 것을 의미한다. 일반적으로 인터페이스를 활용하면 이 원칙을 준수할 수 있게 된다( 캡슐화 ) Client 객체는 Cat, Dog, Bird의 crying() 메서드에 직접 접근하지 않고, Animal 인터페이스의 crying() 메서드를 호출함으로써 DIP를 만족할 수 있습니다.

ISP ( Interface Segregation Principle ) - 인터페이스 분리 원칙 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 설계 원칙이다. 즉, 하나의 거대한 인터페이스 보다는 여러 개의 구체적인 인터페이스가 낫다는 것을 의미한다. SRP는 객체의 단일 책임을 뜻한다면, ISP는 인터페이스의 단일 책임을 의미한다. 예를 들어, 핸드폰( Phone )에는 전화( call ), 문자( sms ), 알람( alarm ), 계산기( calculator ) 등의 기능이 있다. 옛날 3G폰과 현재 스마트폰은 Phone의 기능들을 사용하므로, call, sms, alarm, calculator 기능이 정의된 Phone 인터페이스를 정의하려고 한다. 그러나 ISP를 만족하려면 Phone ..

LSP ( Liskov Substitution Principle ) - 리스코프 치환 원칙 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙이다. 즉, 자식 클래스는 언제나 부모 클래스의 역할을 대체할 수 있어야 한다는 것을 말하며, 부모 클래스와 자식 클래스의 행위가 일관됨을 의미한다. 자식 클래스가 부모 클래스를 대체하기 위해서는 부모의 기능에 대해 오버라이드 되지 않도록 하면 된다. 즉, 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야 LSP를 만족하게 된다. LSP에 따르면 객체지향적으로 설계를 하기 위해서는 오버라이드는 가급적 피하는 것이 좋다고 한다.

OCP ( Open-Closed Principle ) - 개방-폐쇄 원칙 기존의 코드를 변경하지 않으면서( closed ), 기능을 추가할 수 있도록( open ) 설계가 되어야 한다는 원칙을 말한다. 즉, 확장에 대해서는 개방적이고 수정에 대해서는 폐쇄적이어야 한다는 의미를 갖는다. 이를 만족하는 설계가 되려면, 캡슐화를 통해 여러 객체에서 사용하는 같은 기능을 인터페이스에 정의하는 방법이 있다.. Animal 인터페이스를 구현한 각 클래스들은 울음소리 crying() 함수를 재정의한다. 울음소리를 호출하는 클라이언트는 다음과 같이 인터페이스에서 정의한 crying() 함수만 호출하면 된다. public class Client { public static void main(String args[]){ ..

SRP( Single Responsibility Principle ) - 단일 책임 원칙 객체는 단 하나의 책임만 가져야 한다는 원칙을 말한다. 객체지향적으로 설계할 때는 응집도를 높게, 결합도는 낮게 설계하는 것이 좋다. 응집도 : 한 프로그램의 요소가 얼마나 뭉쳐있는지, 즉 구성 요소들 사이의 응집력을 말한다. 결합도 : 프로그램 구성 요소들 사이가 얼마나 의존적인지를 말한다. SRP에 따른 설계를 하면 응집도는 높게, 결합도는 낮게 설계할 수 있게 된다. 흔히 함수는 하나의 기능만 수행하도록 구현되어야 하는데, calculator() 함수가 덧셈, 뺼셈, 곱셈, 나눗셈을 모두 한다면 이는 좋은 설계가 아니다. 덧셈, 뺼셈, 곱셈, 나눗셈이 각각의 함수로 정의되어 있어야 유지보수가 쉽다. 마찬가지로 ..

객체지향설계의 5원칙 SOLID는 아래 5가지 원칙의 앞 머리 알파벳을 따서 부르는 이름이다. 1. SRP : 단일 책임 원칙 - 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다. 2. OCP : 개방 폐쇄 원칙 - 자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다. 3. LSP : 리스코프 치환 원칙 - 서브 타입은 언제나 자신의 가반 타입으로 교체할 수 있어야 한다. 4. ISP : 인터페이스 분리 원칙 - 클라이언트는 자신이 사용하지 않는 메서드에 의존 관게를 맺으면 안된다. 5. DIP : 의존 역전 원칙 - 자신보다 변하기 쉬운 것에 의존하지 마라 이 원칙들은 응집도는 높이고, 결합도는 낮추는 고전 원칙을 객체 지향의 관점에서 재정립한 것이라고 할 수 있다. SOL..