SOLID 원칙

** SOLID : 좋은 객체 지향 설계의 5가지 원칙 , 로버트마틴 클린코드 **

1. 단일 책임 원칙 (single responsibility principle,  SRP) :

하나의 클래스는 하나의 책임만 가져야 한다 

이때, 중요한 기준은 변경이다. 즉 변경이 있을 때 파급효과가 적은 경우 단일 책임 원칙을 잘 따른 것

 

2. 개방 폐쇄 원칙(Open closed principle, OCP) : 

확장에는 열려있으나 변경에는 닫혀있어야 한다, 다형성을 활용(인터페이스를 활용하여 새로운 클래스를 통한 새로운 기능을 구현)

문제점 : 구현객체를 변경하려면 클라이언트 코드를 변경해야한다

> 해당 문제점을 해결하기 위해 IoC 와 DI 같은 컨테이너가 필요하다 (객체를 생성하고 연관관계를 맺어주는 별도의 조립/설정자)

기능의 변경이나 추가가 발생해도 기존 코드는 수정되지 않고, 새로운 코드를 통해 기능이 확장되는 것이 이상적입니다.

 코드의 재사용성을 높이고, 유지 보수를 용이하게 만듭니다.

 

3. 리스코프 치환 원칙(Liskov substitution principle, LSP) : 

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위타입의 인스턴스로 바꿀 수 있어야 한다

즉, 다형성에서 하위클래스는 인터페이스의 규약을 다 지켜야 한다는 것 (컴파일 성공을 넘어서는 이야기이다)
서브타입은 언제나 기반 타입으로 대체될 수 있어야 한다는 원칙입니다. 즉, 자식 클래스는 부모 클래스의 역할을 완전히 대체할 수 있어야 합니다.

 

4. 인터페이스 분리 원칙(Interface segregation principle, ISP) : 

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다,

분리하면 인터페이스 자체가 변해도 클라이언트에 영향을 주지 않음, 인터페이스도 명확하고 대체가능성이 높아진다. 
클라이언트는 자신이 사용하지 않는 인터페이스에 의존하게 만들어서는 안 된다는 원칙입니다. 이는 "작고 구체적인 인터페이스가 낫다"라는 원칙을 의미하며, 클래스는 자신이 필요로 하는 메서드만을 가진 인터페이스에 의존해야 함을 나타냅니다.

 

5. 의존관계 역전 원칙(Dependency inversion principle, DIP) : 

추상화에 의존하는 것이지 구체화에 의존하면 안된다, 구현클래스가 아닌 인터페이스에 의존한다는 뜻이다. 

클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다

정리 :

의존한다는 것은 내가 해당 클래스의 코드를 알고 있다는 뜻이다 . 

객체지향의 핵심은 다형성으로 다형성 만으로는 OCP,DIP를 지킬 수 없다. 

 

스프링은 DI(의존성 주입) + DI컨테이너의 제공(자바객체들을 컨테이너안에 넣어두고 연결,스프링 프레임워크)을 통해

다형성 + OCP<DIP를 가능하게 지원해준다 !! (클라이언트 코드의 변경 없이 기능확장)

 

하지만 실무에서는 인터페이스를 도입하면 "추상화"라는 비용이 발생한다

기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고 향후 인터페이스를 도입(리팩터링)

언제나 장점이 단점을 넘어설때 선택하는 것이 중요

 

* 단일 책임 원칙에 대해 설명하고, 이 원칙을 지키지 않을 때 어떤 문제가 발생할 수 있는지 설명해주세요.

단일 책임 원칙(Single Responsibility Principle, SRP)은 객체 지향 프로그래밍에서 가장 기본적인 원칙 중 하나로, 한 클래스는 한 가지 책임만 가져야 함을 의미합니다. 이는 "변경의 이유는 한 가지만 있어야 한다"라는 원칙으로 이해될 수 있습니다.

단일 책임 원칙을 지키면 코드의 응집도를 높이고 결합도를 낮출 수 있어, 유지 보수성이 향상되고 테스트하기가 더 쉬워집니다. 또한, 각 클래스의 역할이 명확해지므로 코드를 이해하고 사용하는데 도움이 됩니다.

반면에 이 원칙을 지키지 않으면 다음과 같은 문제가 발생할 수 있습니다:

1. 유지 보수성 감소: 한 클래스가 너무 많은 책임을 지게 되면, 한 책임에 대한 변경이 다른 책임에 미치는 영향을 예측하기 어렵게 됩니다. 결과적으로 코드 변경이 어렵고 위험해집니다.
2. 테스트 어려움: 여러 책임을 가진 클래스는 테스트하기가 어려워집니다. 한 책임에 대한 테스트를 하려면 다른 책임과 관련된 코드도 함께 실행되기 때문입니다.
3. 코드 이해도 낮아짐: 클래스의 책임이 많아지면 클래스의 역할을 이해하고 사용하기가 어려워집니다. 이는 특히 다른 개발자가 코드를 이해하고 수정하는 데 문제가 될 수 있습니다.

따라서, 각 클래스가 단일 책임을 가지도록 설계하는 것은 좋은 객체 지향 설계를 위한 중요한 원칙입니다.

 

* 개방-폐쇄 원칙의 의미와 이 원칙을 따르는 설계의 장점에 대해 설명해주세요.

개방-폐쇄 원칙(Open-Closed Principle, OCP)은 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다는 원칙입니다. 즉, 기능을 변경하거나 확장해야 할 때 기존의 코드는 수정하지 않고, 새로운 코드를 추가함으로써 기능의 변경이나 확장이 이루어져야 합니다.

이 원칙을 따르는 설계의 장점은 다음과 같습니다:

1. 유지 보수성 향상: 기존 코드를 수정하지 않으므로, 기존 코드가 잘 작동하는 한 새로운 기능 추가나 변경이 기존 기능에 부정적인 영향을 미치지 않습니다. 따라서 버그의 발생 가능성이 줄어들고, 코드의 안정성이 높아집니다.
2. 확장성 향상: 새로운 기능을 추가하거나 기존 기능을 변경해야 할 때, 기존 코드는 그대로 두고 새로운 코드를 추가하는 방식이므로, 시스템의 확장성이 좋아집니다. 이는 빠르게 변하는 요구사항에 효과적으로 대응할 수 있게 해줍니다.
3. 재사용성 증가: 기존의 코드를 변경하지 않고도 새로운 기능을 추가할 수 있으므로, 기존 코드나 모듈을 재사용하기 쉽습니다. 이는 개발 시간을 단축시키고, 코드의 중복을 줄여주며, 개발 생산성을 향상시킵니다.

개방-폐쇄 원칙은 추상화와 다형성을 활용하여 구현할 수 있습니다. 예를 들어, 추상 클래스나 인터페이스를 정의하고, 이를 구현한 구체 클래스를 확장하여 새로운 기능을 추가하는 방식입니다. 이렇게 하면 기존 코드를 변경하지 않고도 새로운 기능을 추가하거나 기존 기능을 변경할 수 있습니다.

 

* 리스코프 치환 원칙을 위반했을 때 어떤 문제가 발생하는지 예를 들어 설명해주세요.

리스코프 치환 원칙(Liskov Substitution Principle, LSP)은 서브타입은 언제나 기반 타입으로 대체될 수 있어야 함을 의미합니다. 즉, 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 대체해도 프로그램이 제대로 작동해야 합니다.

이 원칙을 위반하면 다음과 같은 문제가 발생할 수 있습니다:

예를 들어, "사각형" 클래스가 "너비"와 "높이"라는 속성을 가지고, "넓이를 계산하는 메서드"를 가지고 있다고 생각해봅시다. 이 클래스를 상속받아 "정사각형" 클래스를 만든다면, "정사각형"은 "너비"와 "높이"가 항상 같아야 하므로, "너비"나 "높이"를 설정하는 메서드가 호출될 때 다른 하나의 속성도 같이 변경되어야 합니다.

그런데 만약 "사각형" 클래스의 인스턴스를 "정사각형" 클래스의 인스턴스로 대체해 사용하려고 하면 문제가 발생합니다. 예를 들어, "너비"와 "높이"를 각각 설정한 후 "넓이를 계산하는 메서드"를 호출하면, "사각형"에서는 기대한 결과를 얻을 수 있지만, "정사각형"에서는 기대한 결과를 얻지 못하게 됩니다.

즉, 리스코프 치환 원칙을 위반하면, 부모 클래스와 자식 클래스가 제대로 대체관계를 가지지 못하게 되어, 코드의 예측 가능성과 재사용성이 떨어지며, 버그의 발생 가능성이 높아집니다. 이런 문제를 피하기 위해, 상속을 사용할 때는 리스코프 치환 원칙을 항상 고려해야 합니다.

 

* "Liskov Substitution Principle"은 Method Overriding과 어떤 관련이 있나요?

메서드 오버라이딩은 자식 클래스에서 부모 클래스의 메서드를 재정의하는 것입니다. 만약 리스코프 치환 원칙을 위반하게 되면, 메서드 오버라이딩이 문제를 일으킬 수 있습니다. 예를 들어, 부모 클래스의 메서드와 동일한 이름과 시그니처를 가진 메서드를 자식 클래스에서 오버라이딩하되, 그 기능이나 동작 방식, 반환 값 등이 부모 클래스의 메서드와 많이 다르다면, 부모 클래스의 인스턴스가 들어갈 자리에 자식 클래스의 인스턴스가 들어가게 되면 프로그램이 예상대로 동작하지 않게 됩니다.

따라서, 메서드를 오버라이딩할 때는 리스코프 치환 원칙을 항상 염두에 두고, 부모 클래스의 메서드를 자식 클래스에서 재정의하더라도 프로그램의 동작에 문제가 없도록 해야 합니다.

 

* 인터페이스 분리 원칙을 위반하면 어떤 문제가 생길 수 있는지 설명해주세요.

인터페이스 분리 원칙(Interface Segregation Principle, ISP)은 클라이언트가 사용하지 않는 메서드에 의존하지 않도록, 즉 "클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안 된다"는 원칙입니다. 이는 클라이언트 관점에서 필요한 메서드만을 제공하는 것이 중요하다는 의미입니다.

이 원칙을 위반하면 다음과 같은 문제가 발생할 수 있습니다:

1. 낮은 응집력: 클라이언트가 사용하지 않는 메서드에도 의존하게 되므로 클래스나 모듈의 응집력이 낮아집니다. 응집력이 낮아지면 코드의 이해도가 떨어지고, 유지보수가 어려워집니다.
2. 불필요한 의존성: 클라이언트는 필요하지 않은 메서드에 대해서도 의존성을 가지게 됩니다. 이로 인해 클라이언트는 자신이 사용하지 않는 메서드에 대한 변경사항에도 영향을 받게 될 수 있습니다.
3. 낮은 재사용성: 인터페이스가 과도하게 크고 복잡해지면 재사용성이 떨어집니다. 특정 클라이언트에 맞춰진 크고 복잡한 인터페이스는 다른 클라이언트에서는 필요하지 않은 메서드들을 포함하게 될 수 있습니다.

따라서 인터페이스는 최대한 작게 나누고, 특정 목적에 맞게 분리하는 것이 좋습니다. 이렇게 하면 클라이언트는 자신이 필요로 하는 메서드만을 제공하는 인터페이스에 의존하게 되므로, 불필요한 의존성을 줄이고 코드의 유지보수성과 재사용성을 높일 수 있습니다.

 

* 의존성 역전 원칙에 대해 설명하고, 이 원칙이 설계에 어떤 영향을 미치는지 설명해주세요.

의존성 역전 원칙(Dependency Inversion Principle, DIP)은 고수준 모듈이 저수준 모듈에 의존하면 안 되며, 둘 다 추상화에 의존해야 한다는 원칙입니다. 또한, 추상화는 구체적인 사항에 의존하면 안 되며, 구체적인 사항이 추상화에 의존해야 합니다.

즉, 소프트웨어 컴포넌트 간의 의존관계가 하위 레벨에서 상위 레벨로 가는 것이 아니라, 상위 레벨의 추상화된 인터페이스를 향해 가야 함을 의미합니다.

이 원칙이 설계에 미치는 영향은 다음과 같습니다:

1. 모듈 간의 느슨한 결합: DIP를 따르면 고수준 모듈과 저수준 모듈 사이의 의존성이 줄어들고, 이들은 추상화된 인터페이스에 의존하게 됩니다. 이로 인해 시스템의 각 부분 사이의 결합이 느슨해지며, 변경에 대한 영향이 줄어듭니다.
2. 유지 보수성과 확장성 향상: 추상화에 의존함으로써 코드 변경이나 기능 추가가 상대적으로 용이해집니다. 하위 모듈이 변경되거나 새로운 하위 모듈이 추가되더라도, 상위 모듈은 변경되지 않거나 최소한의 변경만으로도 대응할 수 있습니다.
3. 재사용성 증가: 고수준 모듈과 저수준 모듈이 추상화에 의존하게 되므로, 각 모듈이 독립적이고 재사용 가능해집니다. 따라서 코드의 재사용성이 증가하게 됩니다.

DIP를 지키지 않으면, 하위 레벨의 모듈 변경이 상위 레벨의 모듈까지 영향을 미칠 수 있어 시스템이 불안정해질 수 있으며, 유지보수와 확장이 어려워질 수 있습니다. 이 원칙은 특히 대규모 시스템에서 중요한데, 이를 지키면 시스템의 다른 부분에 영향을 주지 않고 특정 부분을 변경하거나 확장할 수 있기 때문입니다.

 

* 실제 작업에서 SOLID 원칙을 어떻게 적용하고 있나요?

실제 작업에서 SOLID 원칙은 코드의 품질을 높이고 유지 보수를 쉽게 만드는 데에 도움을 줍니다. 각 원칙은 다음과 같이 적용될 수 있습니다:

1. 단일 책임 원칙 (Single Responsibility Principle, SRP): 하나의 클래스나 함수는 하나의 책임만을 가져야 합니다. 이 원칙을 적용함으로써, 하나의 변경이 다른 기능에 영향을 미치는 것을 최소화하고 코드를 이해하고 유지 관리하기 더 쉽게 만들 수 있습니다.
2. 개방-폐쇄 원칙 (Open-Closed Principle, OCP): 기존의 코드를 변경하지 않고 기능을 추가하거나 변경할 수 있도록 설계해야 합니다. 이 원칙은 주로 상속과 인터페이스를 통해 구현됩니다. 이 원칙을 지키면 기존 코드에 영향을 미치지 않고 새로운 기능을 추가할 수 있으므로 유지 보수가 용이해집니다.
3. 리스코프 치환 원칙 (Liskov Substitution Principle, LSP): 하위 클래스는 상위 클래스를 대체할 수 있어야 합니다. 이 원칙은 주로 메서드 오버라이딩과 관련이 있습니다. 이 원칙을 지키면 클래스의 일관성이 유지되고 코드의 예측 가능성이 높아집니다.
4. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP): 클래스는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 합니다. 이 원칙을 지키면 필요 없는 의존성을 줄이고 모듈 간의 결합도를 낮출 수 있습니다.
5. 의존성 역전 원칙 (Dependency Inversion Principle, DIP): 고수준 모듈은 저수준 모듈에 직접 의존하는 대신 추상화에 의존해야 합니다. 이 원칙을 지키면 코드의 유연성과 재사용성이 증가하고 모듈 간의 결합도가 낮아집니다.

* SOLID 원칙을 지키는 것이 중요하다고 생각하는 이유는 무엇인가요?

SOLID 원칙을 지키는 것이 중요한 이유는 크게 세 가지로 요약할 수 있습니다:

1. 유지 보수성: SOLID 원칙을 따르면 코드의 유지 보수가 용이해집니다. 각 원칙이 코드의 결합도를 낮추고 응집력을 높여서, 변경이나 추가 기능이 필요할 때 그 영향을 최소화하게 합니다. 이는 유지 보수 비용을 줄이는 데 도움이 됩니다.
2. 확장성: 개방-폐쇄 원칙과 의존성 역전 원칙 같은 SOLID 원칙은 코드의 확장성을 높입니다. 새로운 요구 사항이나 기능 추가가 필요할 때, 기존 코드를 크게 변경하지 않고도 새로운 기능을 추가하거나 기존 기능을 수정할 수 있게 됩니다.
3. 재사용성: SOLID 원칙을 따르면 코드의 재사용성이 높아집니다. 각각의 클래스와 모듈이 잘 정의된 책임을 갖게 되어, 필요할 때 다른 곳에서 재사용할 수 있게 됩니다.

위와 같이, SOLID 원칙은 개발자가 효율적이고 유지 보수가 쉬운, 확장 가능하며 재사용 가능한 코드를 작성하는 데 도움이 됩니다. 그러나 모든 상황에 SOLID 원칙을 무조건 적용하는 것이 아니라, 상황에 맞게 적절하게 적용해야 합니다.

 

* SOLID 원칙을 준수하면서 겪었던 어려움은 무엇이었나요?

1. 설계 복잡성: SOLID 원칙을 준수하려면 종종 추가적인 추상화 레벨이나 디자인 패턴이 필요합니다. 이로 인해 설계가 복잡해질 수 있습니다. 예를 들어, 의존성 역전 원칙을 준수하기 위해 인터페이스나 추상 클래스를 도입하면, 코드의 복잡성이 증가할 수 있습니다.
2. 이해도와 학습 곡선: SOLID 원칙을 처음 배우고 이해하는 것은 쉽지 않을 수 있습니다. 각 원칙이 의미하는 바와 그 원칙을 지키기 위한 방법을 이해하는 데는 시간이 필요하며, 이는 개발 과정에 추가적인 시간을 요구합니다.
3. 과도한 적용: 때로는 SOLID 원칙을 과도하게 적용하는 경향이 있을 수 있습니다. 모든 클래스나 모듈이 단일 책임 원칙을 완벽하게 지키려다 보면, 과도한 클래스 분리가 일어나서 오히려 코드를 이해하고 유지 보수하는 데 어려움을 초래할 수 있습니다.
4. 성능 문제: SOLID 원칙의 적용은 때때로 성능에 부정적인 영향을 미칠 수 있습니다. 예를 들어, 인터페이스를 통한 의존성 역전은 런타임에 객체 생성과 가비지 컬렉션 비용을 증가시킬 수 있습니다.

* SOLID 원칙과 디자인 패턴 사이의 관계에 대해 설명해주세요.

SOLID 원칙과 디자인 패턴은 모두 좋은 소프트웨어 설계를 위한 지침입니다. 그러나 그들은 다른 목적과 적용 범위를 가지고 있습니다.

SOLID 원칙은 객체 지향 프로그래밍의 핵심 원칙들을 총체적으로 설명한 것입니다. 이 원칙들은 클래스와 객체, 그리고 이들 간의 관계를 어떻게 설계해야 하는지에 대한 가이드라인을 제공합니다. SOLID 원칙을 따르면 느슨한 결합, 높은 응집력, 재사용 가능성, 유지 보수성 등을 달성할 수 있습니다.

한편, 디자인 패턴은 특정 문제에 대한 해결책을 제공합니다. 이는 재사용 가능한 설계를 만드는 데 도움이 됩니다. 디자인 패턴은 일반적으로 소프트웨어 개발에서 반복적으로 발생하는 문제를 해결하는 방법을 제공합니다.

SOLID 원칙과 디자인 패턴은 서로 상호 보완적인 관계에 있습니다. 디자인 패턴은 대부분 SOLID 원칙을 따르며, SOLID 원칙을 이해하고 적용하면 디자인 패턴을 더 잘 이해하고 적용할 수 있습니다. 예를 들어, "전략 패턴"은 개방-폐쇄 원칙을 따르며, "팩토리 패턴"은 의존성 역전 원칙을 따릅니다.

따라서 SOLID 원칙과 디자인 패턴은 각각 다른 측면에서 소프트웨어 설계의 품질을 향상시키는 도구로 볼 수 있으며, 이 두 가지를 함께 사용하면 더욱 견고하고 유지 보수가 용이한 코드를 작성하는 데 도움이 될 수 있습니다.

 

1. 전략 패턴과 개방-폐쇄 원칙(OCP)
   전략 패턴은 알고리즘 또는 정책을 캡슐화하는 행위 디자인 패턴입니다. 이 패턴은 각 알고리즘을 별도의 클래스로 정의하고, 공통 인터페이스를 갖게 하여 상호 교환 가능하게 만듭니다. 이로 인해 알고리즘을 독립적으로 변경하거나 확장할 수 있게 되며, 이는 바로 개방-폐쇄 원칙(OCP)의 표현입니다.
   개방-폐쇄 원칙은 "소프트웨어 구성요소(클래스, 모듈, 함수 등등)는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다."라는 원칙입니다. 이를 통해 새로운 기능을 추가하더라도 기존 시스템의 수정 없이 확장이 가능하게 됩니다. 전략 패턴은 이 원칙을 구현하며, 알고리즘의 변화에 따라 기존 클래스를 수정하지 않고, 새로운 알고리즘을 추가하여 확장할 수 있게 합니다.
2. 팩토리 패턴과 의존성 역전 원칙(DIP)
   팩토리 패턴은 객체 생성 로직을 캡슐화하는 생성 패턴입니다. 이 패턴은 클라이언트가 직접 객체를 생성하지 않고, 팩토리 클래스를 통해 객체를 생성합니다. 이는 클라이언트와 구체적인 객체 생성 클래스 사이의 의존성을 줄여줍니다.
   의존성 역전 원칙은 "고수준 모듈은 저수준 모듈에 의존하면 안 되고, 둘 다 추상화에 의존해야 한다."라는 원칙입니다. 즉, 구체적인 클래스에 의존하는 것이 아니라, 인터페이스나 추상 클래스에 의존하게 하는 것입니다.
   팩토리 패턴에서는 객체 생성을 담당하는 팩토리 클래스를 통해 이 원칙을 구현합니다. 클라이언트는 구체적인 클래스를 직접 참조하지 않고, 팩토리 클래스에 객체 생성을 요청합니다. 이로 인해 객체 생성을 위해 클라이언트가 구체적인 클래스에 의존하지 않게 되며, 의존성이 역전되는 것입니다.