[Java] SOLID 원칙

냄새나는 코드의 방향제

---

좋은, 객체 지향적 프로그래밍을 위한 방법론

좋은 프로그래밍 코드는 변경이 용이하고, 유지보수와 확장이 쉬운 코드이다. 이러한 코드를 작성하기 위해서는 다음과 같은 방법론과 원칙을 따르는 것이 중요하다.

• 중복의 최소화: 하나의 수정이 다른 하나의 수정을 동반해선 안된다.
• 코드 변경의 용이성: 코드는 항상 완벽하지 않고 요구사항은 상시 바뀔 수 있다.
• 재사용성: 정돈된 코드는 비슷하거나 다른 요구사항에도 그대로 사용 가능하다.

클린 코드의 기준: 단일 목적과 오용, 남용 방지

모든 변수, 함수, 클래스는 명확한 목적을 가지고, 오용되지 않도록 관리되어야 한다. 이를 위한 주요 원칙은 다음과 같다

• DRY (Dont' Repeat Yourself): 동일한 로직을 여러 곳에 중복하지 말고, 한 곳에서만 관리한다.
• KISS (Keep It Simple and Stupid): 단일 목적을 가지며, 간단하고 명확한 코드를 작성한다.
• YAGNI (You Ain't Gonna Neet It): 미래의 필요를 고려하여 지나치게 많은 기능을 미리 구현하지 않는다. 

객체지향 설계 원칙 SOLID

SOLID는 객체지향 설계에서 좋은 코드 작성을 위한 다섯 가지 원칙을 제시한다. 이 원칙들은 유연한 설계와 확장 가능한 구조를 만드는 데에 도움이 된다.

1. Single Responsibility Principle (SRP) - 단일 책임 원칙: 하나의 모듈은 한가지 책임

• 하나의 클래스나 메서드는 오직 하나의 책임만을 가져야한다.
• 변경이 일어날 경우, 오직 한 가지 이유 때문에 변경되어야 한다.

 

 

예시 코드

publi class UserService {
	private UserRepository userRepository;
    private PasswordEncoder passwordEncoder;
    
    public void addUser(String email, String password) {
    	String encryptedPassword = passwordEncoder.encrypt(password);
        User user = new User(email, encryptedPassword);
        userRepository.save(user);
    }
}

 

2. Open-Closed Principle (OCP) - 개방 폐쇄 원칙: 확장에 열려있다 | 수정에 닫혀있다.

• 확장에는 열려있지만, 수정에는 닫혀 있어야 한다.
  
  • 확장에 열려있다: 요구사항이 변경될 때 새로운 동작을 추가하여 애플리케이션의 기능을 확장
  • 수정에 닫혀있다: 기존의 코드를 수정하지 않고 애플리케이션의 동작을 추가하거나 변경
• 기존 코드를 변경하지 않고, 기능을 추가할 수 있어야 한다.

OCP가 본질적으로 얘기하는 것은 추상화이며, 이는 결국 런타임 의존성과 컴파일 타임 의존성에 대한 것이다.

• 컴파일타임 의존성: 코드에 표현된 클래스들의 관계를 의미한다. → 인터페이스 부분
• 런타임 의존성: 애플리케이션 실행 시점에서의 객체들의 관계를 의미한다. → 인터페이스 내 구체 클래스 주입

 

 

예시 코드

public interface PasswordEncoder {
	String encrypt(String password);
}

public class SHA256PasswordEncoder implements PasswordEncoder {
	@Override
    public String encrypt(String password) {
    	// SHA-256 암호화 로직
    }
}

 

3. Interface Segregation Principle (ISP) - 인터페이스 분리 원칙: 인터페이스 내에 메소드 최소 개수

인터페이스 내에 메소드는 최소한 개수로(S: 클래스, 메서드 관점 - I: 인터페이스 관점)

하나의 일반적인 인터페이스 보다 여러 개의 구체적인 인터페이스가 낫다.

도메인같은 것으로 인터페이스를 쪼개어 놓으면 필요한 구현은 1개인데 구현체에 나머지 쓰지도 않는 것들까지 구현해야한다.

예시 )

라면 끓이기 객체 - 물끓이기, 스프넣기, 면넣기, 파썰어넣기, 계란넣기

• 파 썰어넣기, 계란 넣기 내 아무것도 구현이 없음 (텅 빈 Empty 구현)
• 기본 라면 끓이기, 라면에 고명 넣기 등으로 쪼개어야함.

• 구체적인 인터페이스 여러 개로 분리하여 필요한 기능만 구현하도록 한다.
• 불필요한 기능이 포함된 인터페이스를 구현하지 않도록 방지한다.

예시 코드

public interface PasswordChecker {
    String isCorrectPassword(final String rawPw, final String pw);
}

@Component
public class SHA256PasswordEncoder implements PasswordEncoder, PasswordChecker {

    @Override
    public String encryptPassword(final String pw)  {
        ...
    }
  
    @Override
    public String isCorrectPassword(final String rawPw, final String pw) {
        final String encryptedPw = encryptPassword(rawPw);
        return encryptedPw.equals(pw);
    }
}

 

4. Dependency Inversion Principle (DIP) - 의존성 역전 원칙: 인터페이스로 구현체를 연결

인터페이스 구현체를 연결

• (@Service) 고수준 모듈 ←인터페이스(추상화) ← (@Autowired) 저수준 모듈
  • 고수준 모듈: 유저 정보를 DB에서 가져온다.(비지니스 관련, 출력(DB)과 멀다)
  • 저수준 모듈: DB에서 유저 테이블을 찾아 정보를 반환한다. (DB, 출력과 가깝다)
    • DB가 RDBMS가 아니라 NoSQL 이라면 ?
    • DB가 동기가 아니라 비동기라면?
    • 출력에 있어서 다양한 선택지, 경우의 수

고수준 모듈은 저수준 모듈의 구현에 의존하지 않는다는 것

= 저수준이 어떻게 구현되어있든 굳이 신경쓸 필요가 없다

= 원하는 저수준 구현체를 가져다 쓰면 된다.

= 저수준이 꼭 무엇이여야만 하는 것은 아니다.

= 저수준은 인터페이스를 통해 뚫려있고, 아무 구체 클래스만 들어오면 장땡이다.

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

• 고수준 모듈: 입력과 출력으로부터 먼(비니지스와 관련된) 추상화된 모듈
• 저수준 모듈: 입력과 출력으로부터 가까운(HTTP, 데이터베이스, 캐시 등과 관련된) 구현 모듈

따라서 고수준 모듈은 저수준 모듈들을 @Autowired 한다.

• 의존 역전 원칙(D)은 개방 폐쇄 원칙(O)와 밀접한 관련이 있다.
• 의존 역전 원칙(D)에서 의존성이 역전되는 시점은 "컴파일 시점" 이다.

정리하자면:

• 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.
• 인터페이스를 통해 구현체에 대한 의존성을 역전시킨다.

5. Liskov Substitution Principle (LSP) - 리스코프 치환 원칙: "상속 시" 부모 클래스에 대한 가정 충족

"상속 시" 부모 클래스에 대한 가정 그대로 자식 클래스가 정의 되어야 한다.(계급제)

• 하위 타입은 항상 상위 타입을 대체 할 수 있어야한다.

상속 시 하위 클래스는 상위 클래스의 모든 가정을 그대로 갖고 있어야한다.

상위 클래스를 사용하는 개발자가 가정하는 모든 것을 제공해야함.

 

예시 코드(잘못된 설계):

public class Rectangle {
    private int width, height;

    public void setWidth(int width) {
        this.width = width;
    }

    public void setHeight(int height) {
        this.height = height;
    }
}

public class Square extends Rectangle {
    @Override
    public void setWidth(int size) {
        super.setWidth(size);
        super.setHeight(size);
    }

    @Override
    public void setHeight(int size) {
        super.setWidth(size);
        super.setHeight(size);
    }
}

Square는 Rectangle을 상속받아야 하지만, setWidth와 setHeight가 Square의 동작을 망가뜨릴 수 있다. 이는 리스코프 치환 법칙을 위반하는 사례이다.

 

이를 해결하는 좋은 방법은 상속을 사용하지 않고, 합성(Composition)을 사용하는 것이다.

Square와 Rectangle 모두가 Shape라는 공통 페이스를 구현하고, 각 도형이 자신만의 동작을 정의하는 방식이다.

 

예시 코드 (LSP 준수):

// Shape 인터페이스 정의
public interface Shape {
    int getArea();
}

// Rectangle 클래스는 Shape를 구현
public class Rectangle implements Shape {
    private int width, height;

    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }

    public void setWidth(int width) {
        this.width = width;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    @Override
    public int getArea() {
        return width * height;
    }
}

// Square 클래스도 Shape를 구현하지만, 상속을 사용하지 않음
public class Square implements Shape {
    private int size;

    public Square(int size) {
        this.size = size;
    }

    public void setSize(int size) {
        this.size = size;
    }

    @Override
    public int getArea() {
        return size * size;
    }
}

---

좋은 객체지향 프로그래밍 코드를 위한 원칙 2가지

1. 구현보다 인터페이스에 맞춰서 코딩한다.
   • 구현은 언제든지 변경될 수 있지만, 인터페이스를 통해 유연한 코드를 작성할 수 있다.
2. 상속보다는 합성(Composition)을 사용하자.
   • 상속은 코드의 결합도를 높이는 반면, 합성은 필요한 기능을 동적으로 추가할 수 있어 더 유연하다.

---

디자인 패턴

디자인 패턴은 자주 발생하는 문제들에 대한 재사용 가능한 해결책을 제공한다. 각 패턴은 특정한 상황에서 구조적으로 효율적인 해결책을 제시하며, 코드의 유지보수성과 확장성을 높이는 데에 기여한다.

 

• 디자인 패턴 종류

 

디자인 패턴:

• 생성 패턴: 객체의 생성 로직을 캡슐화하여 유연성을 제공.
  • 추상 팩토리, 빌더, 팩토리 메서드, 프로토타입, 싱글톤
• 구조 패턴: 객체나 클래스가 어떻게 서로 관계랄 맺고 협력하는지를 정의
  • 어댑터, 브리지, 컴포지트, 데코레이터, 퍼사드, 플라이웨이트, 프록시
• 행위 패턴: 객체들 간의 상호작용 방법을 정의
  • 책임연쇄, 커맨드, 인터프리터, 이터레이터, 미디에이터, 메멘토, 옵저버, 스테이트, 스트레티지, 템플릿 메서드, 비지터

 

일반적으로 현업에서 많이 언급하거나 자주 사용하는 디자인 패턴:

• 추상 팩토리 패턴: 메세지 전송을 위한 로직을 만들 때 수많은 템플릿, 상황들을 커버.
• 팩토리 메서드 패턴: 생성자가 아닌 정적 팩토리 메서드를 통한 객체 생성
• 빌더 패턴: 생성자가 아닌 빌더를 통한 객체 생성
• 싱글턴 패턴
• 어뎁터 패턴 / 데커레이터 패턴: 어떤 메서드를 한번 감싸서 추가적인 작업을 확장하여 사용할 때
• 파서드 패턴: 일반적으로 @Autowired 하여 여러 필요 서비스들을 모아 사용하는 것
• 프록시 패턴: Spring AOP 동작 원리, Spring Data JPA의 @Transactional 동작 원리
• 옵저버 패턴: 브로드캐스팅이 필요할 때
• 템플릿 메서드: 추상 클래스를 사용할 때 사용할 수 밖에 없는 패턴

---

ℹ️참고

[ASAC 6기 강의자료]

https://velog.io/@haero_kim/SOLID-%EC%9B%90%EC%B9%99-%EC%96%B4%EB%A0%B5%EC%A7%80-%EC%95%8A%EB%8B%A4

SOLID 원칙, 어렵지 않다!

https://medium.com/@learnstuff.io/single-responsibility-principle-ad3ae3e264bb

Single Responsibility Principle

https://www.linkedin.com/pulse/interface-segregation-principle-vagdevi-kommineni-okwcc

Interface Segregation Principle

https://medium.com/@learnstuff.io/single-responsibility-principle-ad3ae3e264bb

Single Responsibility Principle