📌 개요

SOLID는 객체 지향 설계에서 중요한 5가지 원칙을 의미한다. 이 원칙은 클린 아키텍처의 저자 로버트 마틴이 제안했으며, 소프트웨어 개발에서 의존성을 관리하고, 유지보수와 확장성을 향상시키기 위해 사용된다. 개인적으로 SOLID 원칙을 공부하기 전과 후로 코드보는 시선이 많이 달라졌다고 느낀다.

📖 단일 책임 원칙(Single Responsibility Principle, SRP)

하나의 클래스는 하나의 책임만 가져야 한다는 원칙이다. 클래스 뿐만 아니라 메소드에도 해당하는 것 같다.
그런데 책임? 책임이 뭘까 책임이란 역할이다 하나의 클래스, 하나의 메소드마다 각각의 역할과 관심사를 응집력있게 만들어 이를 통해 클래스가 더욱 명확해지고, 재사용에 용이하게 만들라는 의미이다.

이를 왜 지켜야 할까? 그냥 한곳에다 다 몰아서 하면 안되나? 각각의 역할별로 클래스와 메소드를 만들면 괜히 코드양만 늘어나지 않나? 그렇지 않다 아래 예시를 보자.

public class 사람 {

    void 일하기() {
        System.out.println("코드를 타다닥 타다닥 치는중 ...");
    }
    
    void 효도하기() {
        System.out.println("부모님께 효도하는중 ...");
    }
    
    void 데이트하기() {
        System.out.println("여자친구랑 데이트 하는중 ...");
    }
    
}

사람이라는 클래스는 코딩하기, 효도하기, 데이트하기 라는 액션을 할 수 있는 메소드들이 있다.

만약 회사, 엄마, 여자친구 라는 클래스들이 있다고 가정할 때 이 클래스들은 유사 개발자 클래스를 의존하게 될 것 이다. 여기서 회사 클래스에서는 효도하기와 데이트하기와 같은 기능은 필요도 없는데 사용할 수 있게 된다.

벌써 맛이 없다.

또, 사람 클래스를 수정할 때 마다 해당 클래스들이 영향을 받게 된다.

이를 개선하기 위해서는 역할별로 클래스를 만들고 메소드를 분리한다면 SRP를 실천할 수 있게된다.

📖 개방-페쇄 원칙(Open/Closed Principle, OCP)

클래스, 모듈, 함수 등은 확장에는 열려있지만 변경에는 닫혀있어야 한다는 원칙이다. 즉, 기존 코드를 변경하지 않고도 기능을 수정하거나 확장할 수 있는 구조를 의미한다.

그런데 어떻게 기존 코드를 변경을 안하고 확장할 수 있는걸까? 아래 예시를 보자

public class UserRepository {
	private final MysqlConnector connector;
    
    public UserRepository(mysqlConnector connector) {
    	this.connector = connector;
    }
    
    public void save(User user) {
    	connector.save(user);
    }
}

별로 이상한 점이 없는 코드지만, 만약 DBMS를 MySQL에서 Oracle로 변경해야 한다면 어떨까?

UserRepository가 의존하고 있는 MysqlConnector부분을 OracleConnector를 만들어서 수정해야 할 것이다.
그런데 만약 시스템 전체에서 MysqlConnector를 의존하고 있는 코드를 변경해야 한다 생각하면 어질어질 하다.

이를 개선하기 위해선 인터페이스를 사용하여 DatabaseConnector 라는 추상적인 개념을 만들면 된다.

핵심은 UserRepository가 특정 db벤더의 의존하지 않게끔 하는것이다. 개선된 코드를 보자

// DB연결부와 save 메소드를 추상화 시킨 후 인터페이스를 구현한 구현체들
public interface DatabaseConnector {
    void save(User user);
}

public class MysqlConnector implements DatabaseConnector {
    @Override
    public void save(User user) {
        System.out.println("Saving user to MySQL database");
    }
}

public class OracleConnector implements DatabaseConnector {
    @Override
    public void save(User user) {
        System.out.println("Saving user to Oracle database");
    }
}

// 구현체에 의존하지 않고 인터페이스에 의존함으로써 OCP를 지킨 코드
public class UserRepository {
    private final DatabaseConnector connector;
    
    public UserRepository(DatabaseConnector connector) {
        this.connector = connector;
    }
    
    public void saveUser(User user) {
        connector.save(user);
    }
}

이제 Mysql이던 Oracle이던 Maria던 상관없이 DatabaseConnector만 구현한 구현체를 꽂아주기만 하면 UserRepository를 수정하지 않고도 기능을 확장하거나 수정할 수 있게되었다.

📖 리스코프 치환 원칙(Liskov Substitution Principle, LSP)

리스코프 치환 원칙은 1988년 바바라 리스코프가 올바른 상속 관계의 특징을 정의하기 위해 발표한 것이다.
서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다는 것을 뜻한다.

교체할 수 있다는 것은 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행이 보장되어야 한다는 의미이다.

즉, 부모 클래스의 인스턴스를 사용하는 위치에 자식 클래스의 인스턴스를 대신 사용했을 때 코드가 원래 의도대로 작동해야 한다는 의미이다.

이러한 LSP 원칙을 잘 적용한 예시가 자바의 컬렉션 프레임워크 이다.

만일 변수에 LinkedList 자료형에 담아 사용하다, 중간에 전혀 다른 HashSet 자료형으로 바꿔도 add() 메서드 동작을 보장받기 위해서는 Collection 이라는 인터페이스 타입으로 변수를 선언하여 할당하면 된다.

왜냐하면 인터페이스 Collection의 추상 메서드를 각기 하위 자료형 클래스에서 implements하여 인터페이스 구현 규약을 잘 지키도록 잘 설계가 되어있기 때문이다.

void main() {
	// Collection 인터페이스 타입으로 변수 선언
    Collection data = new LinkedList();
    data = new HashSet(); // 중간에 전혀 다른 자료형 클래스를 할당해도 호환됨
    
    modify(data); // 메소드 실행
}

void modify(Collection data){
    data.add(1); // 인터페이스 구현 구조가 잘 잡혀있기 때문에 add 메소드 동작이 각기 자료형에 맞게 보장됨
}

리스코프 치환 원칙을 어긴 쉬운 예시로는 다음과 같다.

// 부모 클래스
class 새 {
    public void 날다() {
        System.out.println("새가 날고 있다.");
    }
}

// 자식 클래스
class 참새 extends 새 {
    @Override
    public void 날다() {
        System.out.println("참새가 날고 있다.");
    }
}

// 자식 클래스
class 타조 extends 새 {
   
    @Override
    public void 날다() {
        throw new UnsupportedOperationException("타조는 날 수 없다.");
    }
}

새라는 부모 클래스에는 날다라는 메소드가 있는데 타조의 경우 새의 한 종류 이긴 하지만 날 수는 없다.
이 처럼 상속관계에서의 모호한 관계가 발생한 경우 이를 적절히 해결해줘야 한다.
해법으로는 날다라는 기능을 인터페이스로 만들어 적절히 구현하게 만들어주면 된다.

// 부모 클래스
class 새 {
    // 공통된 속성 및 메서드 정의
}

interface 날수있는 {
    void fly();
}

// 자식 클래스
class 참새 extends 새 implements 날수있는 {
    @Override
    public void 날다() {
        System.out.println("참새가 날고 있다.");
    }
}

// 자식 클래스
class 타조 extends 새 {
    
}

📖 인터페이스 분리 원칙(Interface Segregation Principle, ISP)

인터페이스 분리 원칙은 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다는 원칙이다.
그 이유는 범용 인터페이스의 경우 구현해야할 추상 메서드들이 많이 있기 때문에 내가 구현하고 싶지 않아도 구현해야만 하는 불상사가 일어나기 때문이다.

interface 작업자 {
    void 작업하다();
    void 식사하다();
}

class 사람작업자 implements 작업자 {
    public void 작업하다() {
        System.out.println("사람이 작업하고 있습니다");
    }
    
    public void 식사하다() {
        System.out.println("사람이 식사하고 있습니다");
    }
}

class 로봇작업자 implements 작업자 {
    public void 작업하다() {
        System.out.println("로봇이 작업하고 있습니다");
    }
    
    // 로봇은 먹을 필요가 없지만, 인터페이스 때문에 식사하다() 메서드를 구현해야 한다
    public void 식사하다() {
        throw new UnsupportedOperationException("로봇은 식사할 수 없습니다");
    }
}

📖 의존성 역전 원칙(Dependency Inversion Principle, DIP)

의존성 역전 원칙이란 고수준 개념은 저수준 개념을 의존해서는 안된다는 원칙이다. 그리고 추상화는 구체적인 사항에 의존해서는 안되며, 구체적인 사항이 추상화에 의존해야 한다는 의미이다.

그럼 여기서 고수준은 뭐고 저수준은 무엇일까?

고수준 : 애플리케이션의 정책을 정의하는 개념이다. 주로 비즈니스 로직을 포함한다.
저수준 : 고수준 개념을 지원하는 영역으로 구체적은 구현 세부 사항을 포함한다. 데이터 베이스 접근, 네트워크 통신 등의 세부적인 기능을 담당한다.

interface DataRepository {
    void save(Object data);
}

class FileDataRepository implements DataRepository {
    public void save(Object data) {
        // 파일 시스템에 데이터 저장
    }
}

class HighLevelModule {
    private DataRepository dataRepository;

    public HighLevelModule(DataRepository dataRepository) {
        this.dataRepository = dataRepository;
    }

    public void performAction(Object data) {
        dataRepository.save(data);
    }
}