[기술면접] CS 기술면접 질문

SOLID 원칙이란?

SOLID 원칙은 객체 지향 프로그래밍에서 유지보수성과 확장성을 높이고 코드 품질을 향상시키기 위한 다섯 가지 설계 원칙을 의미합니다.

SOLID는 각 원칙의 첫 글자를 따서 만들어졌으며, 코드가 변경에 유연하고 안정적인 구조를 갖출 수 있도록 돕습니다.

면접에서 SOLID 원칙을 설명할 때는 각 원칙이 왜 중요한지와 어떻게 적용할 수 있는지에 초점을 맞추면 좋습니다.

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

• 설명: 하나의 클래스는 하나의 책임만 가져야 한다는 원칙입니다. 즉, 클래스는 단 하나의 기능만 수행하고, 그 기능에 대해서만 변경의 이유가 있어야 합니다.
• 중요성: 한 클래스가 여러 책임을 가지면, 해당 책임 중 하나가 변경될 때 다른 책임도 영향을 받습니다. SRP는 각 클래스가 하나의 역할만 담당하게 하여 코드의 응집도를 높이고, 유지보수를 쉽게 만듭니다.
• 예시: 만약 Order 클래스가 주문 처리와 결제까지 모두 담당한다면, SRP 위반입니다. 결제를 따로 처리하는 PaymentProcessor 클래스를 분리하는 것이 좋습니다.

개방-폐쇄 원칙 (Open-Closed Principle, OCP)

• 설명: 소프트웨어 구성 요소(클래스, 모듈 등)는 확장에는 열려 있어야 하지만, 변경에는 닫혀 있어야 한다는 원칙입니다. 즉, 새로운 기능을 추가할 수는 있지만, 기존 코드를 수정하지 않고 기능을 확장해야 합니다.
• 중요성: OCP는 기존 코드를 건드리지 않으면서 새로운 기능을 추가할 수 있도록 하여, 코드 수정에 따른 리스크를 줄입니다. 이로써 버그 발생 가능성이 감소합니다.
• 예시: 새로운 결제 방식을 추가할 때 기존 Payment 클래스의 코드를 수정하는 대신, 인터페이스나 추상 클래스를 확장하여 새로운 결제 방식을 추가할 수 있습니다.

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

• 설명: 자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다는 원칙입니다. 즉, 프로그램에서 부모 클래스로 정의된 객체를 자식 클래스로 대체하더라도 프로그램이 정상적으로 동작해야 합니다.
• 중요성: 자식 클래스가 부모 클래스의 행동을 변경하면, 다형성(polymorphism)이 제대로 동작하지 않아 예기치 않은 문제가 발생할 수 있습니다. LSP는 자식 클래스가 부모 클래스의 계약을 준수하도록 하여, 시스템의 안정성을 보장합니다.
• 예시: Bird라는 부모 클래스가 있고, Penguin이라는 자식 클래스가 있을 때, Bird 클래스에 fly() 메서드가 있다면 Penguin은 LSP를 위반할 수 있습니다. 펭귄은 날 수 없기 때문입니다. 이를 해결하기 위해 Bird에 fly()를 두기보다는, 날 수 있는 새만을 위한 클래스를 별도로 정의하는 것이 좋습니다.

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

• 설명: 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다는 원칙입니다. 즉, 인터페이스는 특정 클라이언트에 맞게 최소한으로 나누어져야 합니다.
• 중요성: 한 클래스가 여러 메서드를 가진 큰 인터페이스를 구현하면, 필요하지 않은 기능까지 의존하게 됩니다. ISP는 인터페이스를 세분화하여, 불필요한 의존성을 제거하고, 유연하고 독립적인 설계를 가능하게 합니다.
• 예시: Worker 인터페이스가 work()와 eat() 메서드를 모두 가지고 있다면, 이는 작업만 하는 로봇 클래스에 불필요합니다. Worker와 Eater 인터페이스를 분리하는 것이 좋습니다.

의존성 역전 원칙 (Dependency Inversion Principle, DIP)

• 설명: 고수준 모듈은 저수준 모듈에 의존해서는 안 된다. 둘 다 추상화에 의존해야 한다는 원칙입니다. 즉, 구체적인 구현이 아닌, 추상적인 인터페이스나 클래스에 의존해야 합니다.
• 중요성: DIP는 상위 모듈이 하위 모듈의 구체적인 구현에 의존하지 않도록 하여, 코드의 결합도를 낮추고 유연성을 높입니다. 이를 통해 시스템의 유지보수가 쉬워지고, 새로운 요구 사항에도 쉽게 대응할 수 있습니다.
• 예시: NotificationService가 EmailSender라는 구체 클래스에 의존한다면, 이는 DIP 위반입니다. EmailSender 대신 MessageSender 같은 추상 인터페이스에 의존하게 하면, 다양한 메시징 수단(SMS, 푸시 알림 등)을 쉽게 추가할 수 있습니다.