이전에 개발자들은 수많은경험들을 통해 프로젝트가 망가져가면서 절차지향적인 코드를 완성했었다
"무엇을(기능)" 중심으로 코드가 어떻게 작동할지 순서에 집중한다 명령을 순차적으로 시작하는방식
그치만 이러한 코드에 문제는 프로젝트가 커질수록 유지보수가 어려워지고 코드의 재사용성이 낮아지면서 디버깅에 오류를 가지는 스파게티 코드가 되버린다
우리는 이러한 코드들을
높은 결합도(High Coupling)와 낮은 응집도(Low Cohesion)을 가진 코드라고한다
우리는 유지보수가 쉽고 확정성이 뛰어나면서 이해하기 쉬운코드를 만들어야한다
결합도를 낮추고 응집도를높혀 견고한 소프트웨어의 구조를 설계해야한다
그 구조에 맞는 설계를 하기위한 처방이 SOLID 의 5가지 원칙이다
즉 SOLID 원칙은 규칙이 아니라, 오랫동안 수많은 프로젝트가 망가지며 얻은 고통의산물이다
하나의 클래스는 하나의 역활만 가져야한다 그 책임을 침범하면안된다
이번에 실습하게된 커머스과제를 통해 예를 들어보면

Product.java 는 개별 상품만을 관리하는 클래스로 정의해야하는데
상품목록관리 , 출력까지 전부 하고있다 이럴경우 수정해야할때 여러곳을 보수해야하는
SRP 위반사례이다

그러나 OCP 관점에서는 기능을 추가하게되면 클래스가 결국생겨나는거니,
main을 계속 수정해야 하며 객체를 인스턴트화 해줘야하는데
그걸 도와주는게 앞으로 배울 Spring 이라고한다
DI (의존성 주입), 제어의 역전(IOC)
쉽게말하면 상속했으면,부모클래스 대신써도 똑같이 동작해야한다 다형성을 지원하기위한 원칙
잘못된설계 X
올바른 설계 O
출저:https://notavoid.tistory.com/326
인터페이스 분리 원칙(ISP)은 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙입니다. 이는 인터페이스를 작고 구체적으로 설계하여, 클라이언트가 필요하지 않은 기능에 의존하지 않도록 하는 것을 목표로 합니다.
예를 들어, 프린터 인터페이스를 복합적으로 설계하는 대신, 스캔, 출력, 복사 기능을 각각의 인터페이스로 분리하여 필요에 따라 구현할 수 있습니다.
기능 단위로 인터페이스를 잘게 쪼개어(Segregation), 각 클라이언트가 필요한 메서드만 가지는 인터페이스를 제공해야 합니다.
올바른 인터페이스 분리 예시
객체 생성 책임을 밖으로 빼는 것
즉 구체적인 클래스보다 상위클래스,인터페잇,추상클래스와 같이 변하지 않을 가능성이 높은 클래스와 관계를 맺으라는 것


마무리하며
원칙간의 연결고리
5개의 원칙은 독립적인 규칙이 아니다
- OCP는 DIP 없이 지키기 어렵다
- 확장에 열려있으려면 추상화에 의존해야 한다
- LSP를 어기면 OCP도 무너진다
instanceof분기가 생기고, 새 자식 추가마다 기존 코드를 수정해야 한다- ISP와 SRP는 함께 작동한다
- 인터페이스에도 단일 책임이 적용된다
- DIP는 모든 원칙의 토대
- 추상화에 의존해야 나머지 원칙을 실천할 수 있다
항상 코드 설계를 할때 5가지 원칙을 생각하며 대입해보자