Day 27 - TIL

📘 Day 27 - Today I Learned

🔍 Today’s Error or Issue

오늘은 개인 과제를 제출하고 여전히 컨트롤러 의존성이 높은거 같다는 생각이 들어서 객체지향 설계에 대해 찾아보던 중 SOLID 원칙이라는 라는것을 알게 됐다.

🛠️ Troubleshooting

다음 과제부터는 SOLID 원칙을 따라서 컨트롤러 의존성을 낮추는 형식으로 설계를 해보기로 했다.

📝 Learning Summary

1. S - 단일화 책임 원칙(SRP: Single Responsibility Principle)
   • 하나의 클래스는 하나의 책임만 가져야 한다.
   • 클래스는 변경될 이유가 하나 뿐이어야 한다.
     예: 사용자 정보를 저장하는 클래스가 사용자 로그인 로직까지 가지면 안된다.

     📌 UserManger 클래스가 사용자 저장과 인증을 모두 하면 책임이 두개. UserRepository와 AuthService로 나누는 것이 SRP를 지키는 방식이다.

2. O - 개방 - 폐쇄 원칙(OCP: Open/Closed Principle)
   • 확장에는 열려 있고, 수정에는 닫혀 있어야 한다.
   • 기존 코드를 수정하지 않고 기능을 확장할 수 있어야 한다.

     📌 새로운 결제 방식(예: KakaoPay)을 추가할 때 기존 PaymentManager를 수정하지 않고 PaymentProtocol을 따르는 객체를 추가해 확장 가능하게 함.

3. L - 리스코프 치환원칙(LSP: Liskov Substitution Principle)
   • 자식 클래스는 언제나 부모 클래스 대신 사용할 수 있어야 한다.
   • 상속받은 객체가 부모 역할을 완벽히 대체할 수 있어야 한다.

     📌 Bird를 상속받은 Penguin이 fly() 를 구현하지 못하면 문제가 생김 → Bird에 fly()를 넣는 것은 리스코프 원칙 위반.

4. I - 인터페이스 분리 원칙(ISP: Interface Segregation Principle)
   • 클라이언트가 사용하지 않는 메서드에 의존하게 해서는 안된다.
   • 인터페이스(프로토콜)는 작고 구체적으로 분리해야 한다.

     📌 Printer 프로토콜에 scan(), fax() 기능까지 있으면 단순 프린터 구현체는 불필요한 메서드도 구현해야 한다. → Printable, Scannable, Faxable로 나누는 것이 ISP에 부합하다.

5. D - 의존 역전 원칙(DIP: Dependency Inversion Principle)
   • 상위 모듈은 하위 모듈에 의존하면 안 된다.
   • 둘다 추상화(인터페이스 또는 프로토콜)에 의존해야 한다.

     📌 Car 클래스가 GasEngine에 직접 의존하면 안된다.
     대신 Engine 프로토콜에 의존하고, 실제 구현은 외부에서 주입받도록 구성해야 유연하다.

📘 Lesson Learned

SOLID를 잘 적용해서 잘 분리된 책임과 유연한 의존성을 통해 변경에 강하고 유지보수가 쉬운 객체지향 코드를 만들어 보자!