SOLID 원칙

✅ SOLID 원칙이란?

객체지향 설계에서 지켜야 할 5개의 소프트웨어 개발 원칙으로 SRP, OCP, LSP, ISP, DIP의 앞글자를 따서 만들어졌습니다.

잘 설계되었는지 평가하는 데에 도움이 되는 설계 원칙입니다.

• SRP: Single Responsibility Principle, 단일 책임의 원칙
• OCP: Open Closed Principle, 개방 폐쇄의 원칙
• LSP: Liskov Substitution Principle, 리스코프 치환의 원칙
• ISP: Interface Segregation Principle, 인터페이스 분리의 원칙
• DIP: Dependency Inversion Principle, 의존 역전의 원칙

 

 

🏷 나쁜 설계의 특징

• 경직성(Shotgun): 하나를 고치면 마치 도미노처럼 영향이 퍼져서 전체적인 코드에 문제가 생긴다.
• 부서지기 쉬움: 하나를 고쳤는데 작동이 멈춘다.
• 부동성: 재사용이 어렵다.
• 끈끈함(long cycle): 하나를 고치면 다른 곳도 계속 고쳐야 해서 완성이 안된다.
• 쓸데없이 복잡함: 불필요하게 코드가 복잡하다.
• 필요 없는 반복: 중복된 코드가 많다.
• 불투명함: 코드의 의도가 희미하다.

 

 

🏷 스파게티 코드

나쁜 설계의 대표적인 코드입니다.

소스 코드가 복잡하게 얽힌 모습이 마치 스파게티의 면발과 같다는 의미에서 스파게티 코드라고 불립니다.

로직이 굉장히 복잡하여 수정이 어렵다는 특징이 있습니다.

스파게티 코드의 모습

 

---

 

1️⃣ SRP(Single Resposibility Principle, 단일 책임의 원칙)

클래스는 단 하나의 책임만 가져야 합니다. 즉, 어떤 클래스를 변경해야 하는 이유는 오직 하나여야 합니다.

결합된 책임은 분리하여 별도의 클래스를 만들어야 합니다.

여기서 책임이란 쉽게 '기능'이라고 생각하면 됩니다.

 

예시를 살펴봅시다.

public class Student{
	// 각 필드의 getter와 setter가 존재한다고 가정
    private int id;
	private string Name; 
    private string Birth;
    private char Gender; 
    public object Export(string format); // 주어진 포맷으로 데이터를 저장하는 함수
}

[문제점]

위 예시에서 Student의 책임은 크게 2가지로 나눌 수 있습니다.

(1) 학생의 학번 이름, 생년월일, 성별을 저장하는 역할

(2) 다른 포맷으로 데이터를 저장하는 역할

=> 한 클래스가 여러 책임을 맡고 있습니다.

 

[원칙 적용]
따라서 Export 함수는 새로운 클래스를 만들어 책임을 분리해야 합니다.

SRP 원칙을 적용하면 코드는 아래와 같이 변경됩니다.

public class Student{
	// 각 필드의 getter와 setter가 존재한다고 가정
    private int id;
	private string Name; 
    private string Birth;
    private char Gender;
}

public class Exporter{
    public object Export(string format);
}

 

 

🏷 산탄총 수술(Shotgun Surgery)

앞에서는 하나의 클래스가 여러 책임을 가지는 경우에 대해서 다뤘습니다.

그러면 여러 클래스가 하나의 책임을 나눠가지는 경우는 어떨까요? 여기서 나온 개념이 바로 산탄총 수술입니다.

 

산탄총은 총알 하나에 여러 개의 탄이 들어있어 총알을 맞게 되면 여러 개의 탄을 일일이 찾아서 치료해야 합니다.

여기서 '총알'은 '책임'으로, '탄'은 '클래스'로 비유할 수 있습니다. 

즉, 산탄총 수술이란 하나의 책임이 여러 클래스들로 분산되어 있는 경우도 단일 책임의 원칙을 적용해 설계를 변경해야 한다는 의미입니다.

 

---

 

2️⃣ OCP(Open Closed Principle, 개방 폐쇄의 원칙)

소프트웨어의 요소는 확장에 대해서는 열려 있지만, 변경에 대해서는 닫혀 있어야 합니다.

요구사항의 변경 및 추가가 일어났을 때, 기존 구성 요소는 수정이 일어나지 않아야 하며 쉽게 확장이 가능해서 재사용할 수 있어야 합니다.

 

예시를 이어가 봅시다. 

public class Exporter{
    public object Export(string format){
    	switch(format){
        	case "Grade": // 성적표
            	... // 학생의 모든 성적이 엑셀표로 저장
            case "Attendance": // 출석부
            	... // 이름, 학번 순서의 문자열 반환
            default:
            	...
        }
    }
}

[문제점]

Export 함수의 내부를 살펴보면 switch-case문을 사용하여 구현되어 있습니다.

만약 새로운 format 형식이 추가된다면, case문을 하나 더 추가해야 하므로 Exporter 클래스에서 변경이 필요합니다.

=> 기존 구성 요소를 수정하지 않고 쉽게 확장이 불가능합니다.

 

[원칙 적용]

OCP 원칙을 지키려면 Exporter를 추상화하고, 이를 상속받는 클래스를 format별로 만들어야 합니다.

public abstract class Formatter{
	public abstract Stream Format(Student student);
}

public class AttendanceFormatter extends Formatter{
	public Stream Format(Student student){
    	return AttendanceStream;
    }
}

public class GradeFormatter extends Formatter{
	public Stream Format(Student student){
    	excel.save(location);
    	return GradeStream;
    }
}

 

---

 

3️⃣ LSP(Liskov Substitution Principle, 리스코프 교체의 원칙)

서브 타입은 베이스 타입에 교체될 수 있어야 한다는 원칙입니다.

슈퍼 클래스에서 받는 매개변수는 서브 클래스가 다 받아야 하며, 슈퍼  클래스가 사용되었을 때 유효하면 서브 클래스가 사용되었을 때도 유효해야 합니다.

 

OCP 원칙을 적용한 후의 코드를 다시 봅시다.

public abstract class Formatter{
	public abstract Stream Format(Student student);
}

public class AttendanceFormatter extends Formatter{
	public Stream Format(Student student){
    	return AttendanceStream;
    }
}

public class GradeFormatter extends Formatter{
	public Stream Format(Student student){
    	excel.save(location);
    	return GradeStream;
    }
}

[문제점]

(1) GradeFormatter의 Format 함수를 보면 location이라는 변수가 쓰이고 있습니다. 하지만 이 변수는 어디에서도 받아오지도 선언되어 있지도 않습니다. 즉, 파라미터로 location 변수를 받아와야 합니다.

(2) 또한, 지금 Format 함수의 반환값이 Stream으로 선언되어 있는데, Attendance일 때는 string이, Grade일 때는 null이 반환되어야 합니다.

=> 부모 클래스를 서브 클래스들이 완전히 대체하지 못하고 있습니다.

 

[원칙 적용]

LSP 원칙을 적용하여 고쳐봅시다.

public abstract class Formatter{
	public abstract Object Format(Student student, string? location);
}

public class AttendanceFormatter extends Formatter{
	public String Format(Student student, string? location){
    	return attString;
    }
}

public class GradeFormatter extends Formatter{
	public Object Format(Student student, string? location){
    	excel.save(location);
    	return null;
    }
}

부모 클래스의 (1) 파라미터에 location을 추가하고, (2) 반환 타입을 Object로 변환했습니다.

 

코드에서 `string?` 물음표의 의미는 null 값일 수도 있고 아닐 수도 있다는 의미입니다. 포맷이 Attendance일 때는 location 값이 null이고 Grade일 때는 null이 아니므로 이를 반영하기 위함입니다.

 

반환 타입을 Object로 변환함으로써 포맷이 Attendance 일 때는 string을 반환하고 Grade 일 때는 null 값을 반환할 수 있게 되었습니다. 참고로 Object 클래스는 모든 자바 클래스의 최고 조상 클래스입니다.

 

---

 

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

인터페이스를 사용에 맞게 잘 분리해야 한다는 원칙입니다.

즉, 클라이언트는 자신이 사용하지도 않는 인터페이스 메서드에 의존하면 안 됩니다.

SRP가 클래스의 단일 책임을 주장한다면, ISP는 인터페이스의 단일 책임을 주장한다고 생각하면 됩니다.

 

앞서 쓴 코드를 살짝 수정해서 ISP 원칙에 부합하지 않는 예시를 살펴봅시다.

public interface Formatter{
	public void Save(Stduent student);
    public Stduent Get(int id);
}

public class ReadOnlyRepository implements Formatter{
	public void Save(Stduent student){
    	throw NotImplementedException();
    }
    public Stduent Get(int id){
    	return db.findById(id);
    }
}

[문제점]

간단하게 메서드 2개만 있다고 가정해 봅시다.

ReadOnlyRepository 클래스는 이름에서 보듯이 db로부터 읽는 역할만 수행하고 싶어 합니다.

그래서 Save 함수를 NotImplementedException을 통해 '나는 이 함수를 구현하지 않을 거다~'라고 말하고 있습니다.

=> 사용하지 않는 인터페이스를 현재 강제로 구현하고 있습니다.

 

[원칙 적용]

ISP 원칙에 맞게 고치려면 결국 readonly 용도의 인터페이스와 writeonly 용도의 인터페이스 두 개로 분리해야 합니다.

그리고 ReadOnlyRepository는 readonly 용도의 인터페이스만 구현하도록 수정해야 합니다.

 

수정이 간단하기 때문에 코드는 생략하겠습니다.

 

---

 

5️⃣ DIP(Dependency Inversion Principle, 의존 역전의 원칙)

구현 클래스에 의존하지 말고, 그 대상의 상위 요소인 추상 클래스나 인터페이스에 의존해야 한다는 원칙입니다.

즉, 구체적인 것이 아닌 추상적인 것에 의존해야 한다. 

 

이는 추상적인 개념보다 구체적인 개념이 더 많이 변하고 불안정하기 때문입니다.

추상적인 개념은 변경이 되지 않는 명세적인 부분입니다. 클라이언트 입장에서는 추상적인 것, 변하지 않는 부분에 의존해야 합니다.

 

새로운 예시를 살펴봅시다.

public class Kid {
    private Robot toy;
    public void setToy(Robot toy) {
        this.toy = toy;
    }
    public void play() {
        System.out.println(toy.toString());
    }
}

public class Main{
    public static void main(String[] args) {
        Robot robot = new Robot();
        Kid k = new Kid();
        k.setToy(robot);
        k.play();
    }
}

[문제점]

위 코드에서 Kid는 Robot에 의존하고 있습니다.

 

만약 toy로 Robot이 아닌 Lego를 할당하고 싶으면 어떻게 될까요?

Kid 내부의 모든 Robot 부분 코드를 Lego로 수정해야 합니다. 아니면 새로운 Lego toy 객체에 의존하도록 추가해야 합니다.

=> 구현 클래스에 의존하고 있습니다.

 

[원칙 적용]

여기에 DIP 원칙을 적용하면, Robot과 Lego 클래스의 상위 요소인 Toy 인터페이스를 만들면 됩니다.

public class Kid {
    private Toy toy;
    public void setToy(Toy toy) {
        this.toy = toy;
    }
    public void play() {
        System.out.println(toy.toString());
    }

만약 클라이언트가 toy로 새로운 장난감을 할당하고 싶다면, Toy의 하위 클래스로 새로운 장난감 클래스를 만들어서 사용하면 끝입니다.

Kid의 코드를 변경할 필요 없습니다.