[Java] 객체 지향 설계 5원칙(SOLID)이란?

 

 

SOLID 원칙이란?

 

객체지향 프로그래밍에 있어 반드시 알아야 하는 SOLID 원칙은 자기 자신 클래스 내부의 응집도는 높이고, 타 클래스와의 결합도는 낮추는 것에 초점을 둔다. 이는 클래스에게 독립된 역할을 부여하기 위함이며 재사용성과 유지보수성이 높은 소프트웨어를 만들 수 있기 때문이다.

 

 

 

 

🔲 SRP(Single Responsibility Principle) : 단일 책임 원칙

- 클래스가 변경되는 이유가 단 한 가지여야 한다

 

🔲 OCP(Open Close Principle) : 개방/폐쇄 원칙

- 확장에는 열려있고, 수정에 대해서는 닫혀있어야 한다.

 

🔲 LSP(Liskov Substitution Principle) : 리스코프 치환 원칙

- 하위 타입을 상위 타입으로 대체할 수 있어야 한다

 

🔲 ISP(Interface Segregation Priciple) : 인터페이스 분리 원칙

- 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공하는 것

 

🔲 DIP(Dependency Inversion Principle) : 의존 역전 원칙

- 고차원 모듈은 저차원 모듈의 구현에 의존해서는 안되며, 저수준 모듈이 고수준 모듈에 의존해야 한다

 

 

 

 

 

 

단일 책임 원칙(SRP)

 

 

SRP는 "클래스가 변경되는 이유가 단 한 가지여야 한다"고 말한다. 여기서 변경의 이유란, 모듈이 여러 대상이나 액터에 대해 책임을 지니지 않고, 오직 하나의 액터에 의해서만 책임을 져야 한다는 것을 의미한다.

 

 

예를 들어, 사용자의 입력 정보를 받고 저장하는 비즈니스 로직을 UserService에서 작성한다고 해보자. 이때의 액터는 다양한 유스케이스나 요구 사항에 따라 달라질 수 있다.

 

• 기획 측에서의 요구 : 사용자를 추가할 때 역할에 대한 정의가 필요하다.
• 보안 측에서의 요구 : 비밀번호 암호화 방식에 개선이 필요하다.
• ...

 

 

UserService에서 이러한 로직을 클래스 파일 하나에 전부 작성한다면, 단일 책임을 지니지 못하는 것이다. 즉, 책임의 분담이 필요하다. 가령 Encoder 클래스를 만드는 식으로 비밀번호 암호화 방식에 대한 로직을 분리해야 한다.

 

 

물론, SRP가 명확하지 않은 경우도 있다. 이는 유스케이스나 요구 사항에 따라 맞추어 지는 것이며 적절한 판단이 필요할 것이다.

 

 

 

 

 

 

 

 

개방 폐쇄 원칙(OCP)

 

 

OCP는 "확장에는 열려있고, 수정에 대해서는 닫혀있어야 한다."라는 원칙이다. 이때 확장에 열려 있다는 것은 요구사항이 변했을 때 코드를 추가해 쉽게 기능 확장이 가능하다는 것이고, 수정에 닫혀있다는 것은 기존의 코드를 수정하지 않고 애플리케이션 동작을 변경할 수 있다는 말이다.

 

 

 

수정에 닫혀있다는 말이 조금 모호하다. 하지만 이는 수정 대상과 무관한 것은 수정하지 않는 것을 말한다. 앞서 보았던, UserService에서 비밀번호 암호화와 관련된 클래스에 수정이 필요하다고 해보자. 이때, 암호화 방식 자체를 바꾸어 버리면 클래스가 통으로 바뀌기 때문에 암호와와 전혀 무관한 UserService 코드 내에서도 변경이 일어난다.

 

 

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;
    private final SHA256PasswordEncoder passwordEncoder;

    ...
    
}

 

 

 

이러한 일이 발생하는 원인은 SHA256PasswordEncoder와 같이 구체화된 클래스에 의존하였기 때문이다. OCP를 지키기 위해서는 이렇게 구체화된 클래스에 의존하는 것이 아니라 "추상화된 클래스"에 의존하여야 한다.

 

 

 

즉, UserService에서는 추상화된 인터페이스에 의존하여 비밀번호 암호화 방식이 바뀌어도 UserService 내의 코드가 바뀔일이 없도록 할 수 있다.

 

 

public interface PasswordEncoder {
    String encryptPassword(final String pw);
}

@Component
public class SHA256PasswordEncoder implements PasswordEncoder {

    @Override
    public String encryptPassword(final String pw)  {
        ...
    }
}

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;

    public void addUser(final String email, final String pw) {
        final String encryptedPassword = passwordEncoder.encryptPassword(pw);

        final User user = User.builder()
            .email(email)
            .pw(encryptedPassword).build();

        userRepository.save(user);
    } 
}

 

 

그렇다면 무작정 추상화에 의존하는 것이 가장 좋은 방법일까? 이는 애플리케이션의 규모에 따라 과도한 설계가 될 수도 있고, 적절한 선택이 될 수도 있다. 결국 코드를 작성하는 것 또한 비용이기에 요구사항과 확장 가능성을 잘 따져보아야 한다.

 

 

 

 

 

 

 

 

 

리스코프 치환 법칙(LSP)

 

 

LSP는 하위 타입을 상위 타입으로 대체할 수 있어야 한다는 원칙이다. 다시말해 Upcasting 된 객체 참조 변수가 논리적으로 그 역할을 하는데 문제가 없어야 한다. LSP는 인터페이스와 클래스 관계, 그리고 상위 클래스와 하위클래스간의 관계를 얼마나 논리적으로 잘 구성했냐가 핵심 관건이다.

 

 

 

이러한 설계를 잘 하기 위해서는 계층이 아니라 분류로써 클래스 구성을 해야한다. 예를 들어, 아버지와 아들의 관계를 상속관계로 나타낸다면 잘못된 것이다. 이는 계층에 해당되는 것이며 아들이 아버지의 한 종류라고 말할 수 없기 때문이다. 당연하게도 아들이 아버지의 역할을 하는 것은 논리 상 맞지 않다.

 

 

 

반면, 곤충과 사슴벌레와 같이 분류로써 클래스 구성을 하는 것은 올바른 형태이다. 하위 클래스인 사슴벌레는 상위 클래스인 곤충의 역할을 수행할 수 있기 때문이다.

 

 

 

즉, 리스코프 치환 원칙은 하위 클래스가 상위 클래스의 역할을 대신 수행할 수 있는 것을 말하며 분류로써, 클래스 구성을 이루어야 한다.

 

 

 

 

 

 

 

 

 

 

인터페이스 분리 원칙(ISP)

 

 

ISP는 "클라이언트의 목적과 용도에 적합한 인터페이스만을 제공하는 것" 이다. 즉, 상황과 관련있는 메서드만을 제공하라는 뜻인데 이는 SRP(단일 책임 원칙)과 같은 원인에 대해 다른 해결책을 제시하는 것이다.

 

 

 

이전의 보았던 SRP의 원인은 너무 많은 책임을 주었기 때문에 발생하였다. 그래서 하나의 액터에 대해서 하나의 책임을 지니도록 했었다. 반면, ISP는 해당 클래스를 쪼개지 않고, 그대로 두는 대신에 인터페이스 최소주의 원칙에 의해 상황에 맞는 메서드 만을 제공하도록 필터링한다.

 

 

 

즉, 원하는 액터의 메서드를 포함한 인터페이스를 생성하고 이를 상속받는 구조로 만들어 클라이언트에 목적에 맞도록 사용할 수 있다.

 

 

 

 

public class Person implements Developable, Cookable, Eatable {
    @Override
    public void develope() {
        System.out.println("개발한다.");
    }
    
    @Override
    public void cook() {
        System.out.println("요리한다.");
    }
    
    @Override
    public void Eatable() {
        System.out.println("밥 먹는다.");
    }
}

 

 

 

 

 

 

 

 

 

 

 

의존 역전 원칙(DIP)

 

 

마지막으로 DIP는 고차원 모듈은 저차원 모듈의 구현에 의존해서는 안되며, 저수준 모듈이 고수준 모듈에 의존해야 한다는 것을 말한다.

 

 

 

이때 고차원 모듈은 입/출력과 먼(비즈니스와 연관된) 추상화된 모듈을 의미하고, 저수준 모듈은 입/출력과 가까운(HTTP, 데이터베이스, 캐시 등) 구현 모듈을 말한다.

 

 

 

즉, 입/출력과 가까운 구현 클래스가 비즈니스와 연관된 추상화 클래스에 의존해야 한다라고 해석할 수 있다. 이전에 보았던, UserService를 한 번 생각해보자. UserService에는 비밀번호 암호화 방식에 대해 SRP를 적용하여 클래스 분리를 이루게 해주었다.

 

 

 

이때, 구현 모듈인 각각의 암호화 방식(SHA256, Simple, BCrpt)에 대한 각각의 클래스를 서비스 로직에 따라 갈아 끼우는 것은 객체 지향적이지 않다. 여기서 의존 역전 원칙을 통해 UserService가 각각의 암호화 방식인 구현 모듈에 의존하는 것이 아니라 비밀번호 암호화 방식 자체를 가리키는 인터페이스에 의존하도록 해야 한다.

 

 

 

다시말해, _SHA256PasswordEncoder_ 클래스 같은 구현 모듈에 의존하는 것이 아닌, _PasswordEncoder_ 인터페이스에 의존하며 각각의 암호화 구현 모듈이 이 _PasswordEncoder_를 상속받는 그림이 되어야 한다.

 

 

 

 

 

 

 

References

https://mangkyu.tistory.com/194

https://limkydev.tistory.com/77