SOLID 원칙

💎 1. SOLID 원칙이란

SOLID는 다섯 가지 객체지향 설계 원칙의 앞 글자를 따서 만든 약어이다.

💎 SOLID를 왜 알아야 할까?

• 작은 기능 하나를 수정하려고 수십 줄의 코드를 수정해야 하는 상황이다.
• 새로운 기능을 추가하려는데 기존 코드 구조가 너무 복잡하여 어디를 수정해야 할지 모르는 상황이다.
• 한 사람이 짠 코드 구조가 너무 폐쇄적이어서, 다른 사람이 쉽게 건드릴 수 없는 상황이다.

💎 JavaScript / TypeScript에도 적용할 수 있을까?

interface Doable {
  do(): void;
}

function execute(task: Doable) {
  task.do();
}

💎 2. SRP - 단일 책임 원칙: 하나의 함수에는 하나의 책임만 있어야 한다.

function a() {} // 변경의 이유: a 로직이 변할때
function b() {} // 변경의 이유: b 로직이 변할때
function c() {} // 변경의 이유: c 로직이 변할때

function main() {
  a();
  b();
  c();
} // 변경의 이유: a, b, c 함수의 호출 순서가 바뀌어야할때

💡 왜 SRP가 중요한가?

🧩 예시로 보는 SRP 위반

function uploadAndSaveImage(file: File) {
  // 1. 이미지 생성
  const image = createImage(file);

  // 2. 서버에 저장
  uploadToServer(image);
}

✅ SRP를 지킨 구조

function createImage(file: File) {
  // 이미지 생성 로직
}

function uploadImage(image: Blob) {
  // 서버 저장 로직
}

function processImage(file: File) {
  const image = createImage(file);
  uploadImage(image);
}

🧠 실무에서의 SRP 적용

💎 3. OCP - 개방/폐쇄 원칙: 코드는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다.

💡 왜 OCP가 중요한가?

🧩 OCP를 위반한 예시

function main(type: string) {
  if (type === "a") {
    doA();
  } else if (type === "b") {
    doB();
  } else if (type === "c") {
    doC();
  } else if (type === "d") {
    doD();
  }
}

✅ OCP를 만족하는 구조

interface Doable {
  do(): void;
}

function main(task: Doable) {
  task.do();
}

const a: Doable = {
  do() {
    console.log("A 작업");
  },
};
const b: Doable = {
  do() {
    console.log("B 작업");
  },
};
const c: Doable = {
  do() {
    console.log("C 작업");
  },
};
const d: Doable = {
  do() {
    console.log("D 작업");
  },
};

main(a);
main(b);

🧠 실무에서의 OCP 적용

💎 4. LSP - 리스코프 치환 원칙: 부모 타입은 자식 타입으로 자유롭게 대체 가능해야 한다.

💡 왜 LSP가 중요한가?

🧩 LSP를 위반한 예시

class Bird {
  fly() {
    return "파닥파닥";
  }
}

class Penguin extends Bird {
  override fly() {
    return new Error("펭귄은 못 날아");
  }
}

function move(bird: Bird) {
  console.log(bird.fly());
}

move(new Bird()); // "파닥파닥"
move(new Penguin()); // ❌ Error 발생

✅ LSP를 만족하도록 리팩터링

class Animal {
  isAnimal() {
    return true;
  }
}

interface Flyable {
  fly(): string;
}

class Bird extends Animal implements Flyable {
  fly() {
    return "파닥파닥";
  }
}

class Penguin extends Animal {
  swim() {
    return "수영중";
  }
}

🧠 실무에서의 LSP 고려사항

• 상속을 남발하지 말고 인터페이스 기반 설계를 활용하는 것이 LSP 위반을 줄이는 데 도움이 된다.
• 자식 클래스가 부모 클래스의 행동을 무시하거나 오버라이드로 예외를 던지는 경우는 의심해봐야 한다.
• 테스트 코드에서 부모 타입 대신 자식 타입을 넣어보고 문제없이 동작하는지 확인하는 방식으로 LSP 준수 여부를 검증할 수 있다.

💎 5. ISP - 인터페이스 분리 원칙: 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.

💡 왜 ISP가 중요한가?

🧩 ISP를 위반한 예시

interface IBird {
  fly(): string;
  quack(): string;
}

class Sparrow implements IBird {
  fly() {
    return "파닥파닥";
  }
  quack() {
    return "짹짹";
  }
}

class Penguin implements IBird {
  fly() {
    throw new Error("펭귄은 못 날아");
  }
  quack() {
    return "꿱꿱";
  }
}

✅ ISP를 만족하도록 리팩터링

interface Quackable {
  quack(): string;
}

interface Flyable {
  fly(): string;
}

class Sparrow implements Flyable, Quackable {
  fly() {
    return "파닥파닥";
  }
  quack() {
    return "짹짹";
  }
}

class Penguin implements Quackable {
  quack() {
    return "꿱꿱";
  }
}

🧠 실무에서의 ISP 고려사항

• 단일한 큰 인터페이스보다 목적이 분명한 작고 잘게 나뉜 인터페이스가 더 유지보수가 쉽다.
• 공통 기능을 인터페이스로 나눌 때는 역할 중심으로 분리하는 것이 좋다. (Drawable, Sortable, Savable 등)
• 타입스크립트에서는 interface 또는 type을 통해 조합형 타입을 만드는 것이 ISP를 실현하기에 적합하다.

💎 6. DIP - 의존 역전 원칙: 추상화에 의존하고, 구체화에 의존하지 말아야 한다.

💡 왜 DIP가 중요한가?

🧩 DIP를 위반한 예시

class A {
  doSomething() {}
}

class Main {
  private a = new A();

  run() {
    this.a.doSomething();
  }
}

✅ DIP를 만족하는 구조

interface Doable {
  doSomething(): void;
}

class A implements Doable {
  doSomething() {}
}

class Main {
  constructor(private doable: Doable) {}

  run() {
    this.doable.doSomething();
  }
}

const main = new Main(new A());
main.run();

🧠 실무에서의 DIP 고려사항

• 매개변수로 interface나 abstract class를 받는 습관을 들이자.
• 종속성 주입(DI)을 통해 유연한 구조를 만들 수 있다.
• DIP는 테스트 가능성과 코드 재사용성을 높여준다.

💎 7. 마무리 & 실무 적용 팁