SOLID 원칙에대해 공부해보자
안녕하세요 이번 포스팅에서는 SOLID 원칙에대해
알아보도록하겠습니다.
구글에 SOLID 원칙이라고 검색하면 바로 나오는내용은
SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지
소프트웨어 소스 코드를 리팩터링하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이다.
이 원칙들은 애자일 소프트웨어 개발과 적응적 소프트웨어 개발의 전반적 전략의 일부다.위의 글에서 소스 코드를 리팩터링하여 코드 냄새를 제거하기위해.. 라는 말이 이해가 되지않아서
좀더 검색을 해봤습니다.
결론적으로는 객체 지향 프로그래밍에서 유지 보수성,재사용성,확장성 등을 고려하여
소프트웨어를 설계하는데 사용되는 원칙입니다. SOLID 원칙은 5가지의 원칙의 앞글자를 따서
부르는것입니다.
1. SRP (Single Responsibillity Principle) : 단일 책임(기능) 원칙
- " 하나의 클래스는 하나의 책임(기능)만 가져야 한다 " 라는 원칙입니다.
예를들어서, 로그인과 회원가입을 동시에 처리하는 클래스가 있다면 이 클래스는 단일 책임 원칙을
위반하고 있습니다. 이를 해결하기 위해서는 로그인과 회원가입 기능을 각각 별도의 클래스로 분리하는
것이 좋습니다!
2. OCP( Open / Closed Principle ) : 개방-폐쇄 원칙
- 확장에는 열려 있고 , 수정에는 닫혀 있어야 한다는 원칙입니다.
예를들어서, 새로운 기능을 추가하기 위해 기존의 코드를 수정해야 하는 경우에는 개방-폐쇄의 원칙을
위반하고 있습니다. 이를 해결하기 위해서는 새로운 기능을 추가할 때는 기존의 코드를 수정하지 않고, 확장
가능한 방식으로 설계해야 합니다.
3. LSP ( Liskov Substitution Principle ) : 리스코프 치환 원칙
- 자식 클래스는 언제나 부모 클래스를 대체할수 있어야 한다는 원칙 입니다.
예를들어, 부모 클래스와 자식 클래스가 있다고 할 때 , 자식클래스가 부모클래스는 대체 할수 없는경우에는
리스코프 치환 원칙을 위반하고 있는것입니다. 이를 해결하기위해 부모 자식 클래스간에 관계를 재설계 하여
자식클래스가 대체 가능하도록 설계를 해야합니다.
4. ISP ( Interface Segregation Principle ) : 인터페이스 분리 원칙
- 인터페이스는 클라이언트에서 필요한 메소드만 제공해야한다는 원칙 입니다.
예를들어, 하나의 인터페이스가 많은 메소드를 가지고 있다면 클라이언트에서 필요하지 않은 메소드까지
호출할 가능성이 있습니다. 이를 해결하기 위해서는 인터페이스를 작은 단위로 분리하여 필요한 메소드만
제공하는 방식으로 설계해야 합니다.
5. DIP ( Dependency Inversion Principle ) : 의존 역전 원칙
- 상위 모듈은 하위 모듈에 의존하면 안되며, 추상화된 인터페이스에 의존해야 한다는 원칙입니다.
예를들어, 하위 모듈에서 상위 모듈에 직접적으로 의존하는 경우에는 의존 역전 원칙을 위반하고 있는것 입니다.
이를 해결하기위해 상위모듈과 하위모듈 간에 인터페이스를 사용하여 의존성을 역전시키는 방식으로 설계해야 합니다.
총 정리를 해보자면 , 단일 책임 원칙과 인터페이스 분리원칙은 객체가 커지는것을 막아줍니다.
객체가 단일 책임을 갖도록 하고 클라이언트마다 특화된 인터페이스를 구현하게 함으로써
한 기능의 변경이 다른곳까지 미치는 영향을 최소화하고 , 이는 기능 추가 및 변경에 용이 하도록 만들어 줍니다.
리스코프 치환 원칙과 의존 역전 원칙은 개방-폐쇄 원칙을 서포트 합니다.
개방-폐쇄 원칙은 자주 변화되는 부분을 추상화하고 다형성을 이용함으로써 기능 확장에는 용이하되
기존 코드의 변화에는 보수적이도록 만들어 줍니다.
여기서 '변화되는 부분을 추상화' 할수 있도록 도와주는 원칙이 의존 역전 원칙 이고,
다형성 구현을 도와주는 원칙이 리스코프 치환 원칙 입니다.
SOLID 원칙을 지키면, 객체 지향 프로그래밍에서 발생하는 문제들을 줄이고 유지보수성 , 재사용성 , 확장성
등을 고려하여 소프트웨어를 설계할수 있습니다..!!