✏️ SOLID 객체지향 프로그래밍의 5가지 원칙

SOLID 원칙(객체지향 설계 원칙)

1. SPR(Single Responsibility): 단일 책임 원칙

• 클래스는 단 한 개의 책임(=기능)을 가져야 함
• 한 클래스가 수행할 수 있는 기능이 여러 개면 안됨
• 책임을 분리해서 한 개만 가져야 함

2. OCP(Open-Close): 개방-폐쇄 원칙 [추상화]

• 확장(=새로운 기능 추가)에는 열려있어야 하고, 변경에는 닫혀있어야 함.
• 기능 추가 요청이 오면 기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 있도록 설계해야함.
• 하나의 모듈 내 기능을 수정할 때, 다른 모듈을 계속해서 수정해야 한다면 유지보수가 복잡할 것.
• OCP는 추상화(인터페이스)와 상속(다형성) 등을 통해 구현할 수 있다. 자주 변화되는 부분을 추상화함으로써 기존 코드 수정하지 않고도 기능을 확장할 수 있게 해 유연함을 높인다.

//추상화
abstract class Animal{
	abstract void speak();
}

class Cat extends Animal{	//상속
	void Bark(){
    	System.out.println("냐옹");
    }
}

class Dog extends Animal{	//상속
	void Bark(){
    	System.out.println("멍멍");
    }
}

class Animals{
	void zoo(Animal animal){
    	animal.speak();
    }
}

public class Main{
	public static void main(String[] args){
    	Animals hello = new Animals();
        
        Animal cat = new Cat();
        Animal dog = new Dog();
        
        hello.zoo(cat); //냐옹
        hello.zoo(dog); //멍멍
    }
}

 

 

3. LSP(Liskov Substitution): 리스코프 치환 원칙 [다형성]

• 하위 타입 객체는 상위 타입 객체에서 가능한 행위를 수행할 수 있어야 함
• 즉, 부모 클래스의 인스턴스 사용하는 위치에 자식 클래스의 인스턴스를 대신 사용했을 때 코드가 원래 의도대로 동작해야 함
• 부모 클래스와 자식 클래스 사이의 행위가 일관성이 있어야 한다
• 상속관계가 아닌 클래스들을 상속관계로 설정하면 LSP에 위반
• 예를들어, 위의 코드에서 Fish라는 클래스를 만든다고 가정하자. Fish는 Bark할 수 없기 때문에 Bark라는 메서드가 실행될 때 Exception을 처리해주게끔 코드를 짰다. 함께 일하는 개발자는 Fish내 Bark가 Exception으로 실행되는걸 몰랐기 때문에 문제가 발생할 수 있다. LSP는 개발자들이 함께 일을 함에 있어서 지켜야할 규칙같은 거라고 생각하면 편하다.
• 리스코프 치환 원칙을 지키지 않으면, 개방 폐쇄 원칙을 위반하게 되는 것. 기능 확장을 위해 기존의 코드를 여러 번 수정해야하기 때문이다.

 

4. ISP(Interface Segregation): 인터페이스 분리 원칙

• 클라이언트는 자신이 사용하는 메소드에만 의존해야 한다
• 범용적인 인터페이스보다 클라이언트(사용자)가 실제로 사용하는 인터페이스를 만들어야한다.
• 즉, 인터페이스를 용도에 맞게 분리해서 구현해야 한다.
• 사용하지 않는 인터페이스에 변경이 발생해도 영향을 받지 않도록 만들어야 한다.

 

5. DIP(Dependency Inversion): 의존 역전 원칙

• 의존관계를 맺을 때, 변하기 쉬운 것 보다는 변하기 어려운 것에 의존해야 한다.
• 즉, 어떤 클래스를 참조해야하는 상황이 생기면 그 클래스를 직접 참조하는 것이 아니라, 그 대상의 상위요소(추상 클래스 or 인터페이스)로 참조하라는 원칙이다.
• 고수준의 모듈은 저수준의 모듈의 구현에 의존해서는 안된다.