들어가기 전
이전 포스팅에서 객체 지향 프로그래밍에 대해 배웠습니다.
그렇다면 객체 지향 프로그래밍을 위해선 어떤 방법론이 필요할까요?
OOP의 5대 원칙 (SOLID)
SRP - 단일 책임 원칙 (Single Responsibility Principle)
한 클래스는 하나의 책임만 가져야 합니다. 이는 클래스가 변경되어야 하는 이유가 한가지여야 한다는 의미입니다. 해당 클래스가 여러 대상 또는 기능들에 대해 책임을 가져서는 안되고, 오직 하나의 기능에 대해서만 책임을 져야 한다는 것입니다.
만약 어떤 클래스가 여러 액터에 대해 기능을 가지고 있다면 여러 클래스들로 부터 변경에 대한 요구가 올 수 있으므로, 해당 클래스을 수정해야 하는 이유 역시 여러개가 될 수 있습니다.
반면에 어떤 클래스가 단 하나의 책임 만을 갖고 있다면, 특정 기능으로부터 변경을 특정할 수 있으므로 해당 클래스들을 변경해야 하는 이유와 시점이 명확해집니다.
결과적으로 단일 책임 원칙의 목적은 프로그램의 유지보수성을 높이기 위한 설계기법 입니다.
OCP - 개방/폐쇄 원칙 (Open/Closed Principle)
클래스는 확장에는 열려 있어야 하지만, 변경에는 닫혀 있어야 합니다.
확장에 열려있단 말은 새로운 변경 사항이 발생했을 때 유연하게 코드를 추가함으로써 큰 힘을 들이지 않고 애플리케이션의 기능을 확장할 수 있단 말입니다.
변경에 닫혀있단 말은 새로운 변경 사항이 발생했을 때 객체를 직접적으로 수정을 제한한다는 말입니다.
요약하자면 기존의 코드를 변경하지 않으면서, 기능을 추가할 수 있도록 설계 되어야 된다는 원칙입니다.
LSP - 리스코프 치환 원칙 (Liskov Substitution Principle)
서브타입은 언제나 그것의 부모타입으로 교체할 수 있어야 한다는 원칙입니다.
다형성의 특징을 이용하기 위해 상위 클래스 타입으로 객체를 선언하여 하위 클래스의 인스턴스를 받으면, 업캐스팅 된 상태에서 부모의 메서드를 사용해도 동작이 의도대로 흘러가야 하는 것을 의미합니다.
이러한 LSP 원칙을 잘 적용한 예제가 자바 컬렉션 프레임워크입니다.
만일 변수에 LinkedList 자료형을 담아 사용하다, 중간에 전혀 다른 HashSet 자료형으로 바꿔도 add() 메서드 동작을 보장받기 위해서는 Collection 이라는 인터페이스 타입으로 변수를 선언하여 할당하면 됩니다.
왜냐하면 인터페이스 Collection의 추상 메서드를 각기 하위 자료형 클래스에서 implements 하여 인터페이스 구현 규약을 잘 지키도록 미리 잘 설계되어 있기 때문입니다.
결과적으로 확장하는 부분에 다형성을 제공해 변화에 열려있는 프로그램을 만들 수 있도록 합니다.
ISP - 인터페이스 분리 원칙 (Interface Segregation Principle)
ISP 원리는 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원리 입니다. 즉, 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용해야 합니다.
SRP 원칙이 클래스의 단일 책임을 강조한다면, ISP는 인터페이스의 단일 책임을 강조하는 것으로 보면 됩니다.
ISP 원칙은 인터페이스를 사용하는 클라이언트를 기준으로 분리함으로써, 클라이언트의 목적과 용도에 적합한 인터페이스 만을 제공하는 것이 목표입니다.
DIP - 의존성 역전 원칙 (Dependency Inversion Principle)
DIP 원칙이란 객체에서 어떤 Class를 참조해서 사용해야하는 상황이 생긴다면, 그 Class를 직접 참조하는 것이 아니라 그 대상의 상위 요소인 추상 클래스 혹은 인터페이스로 참조 하라는 원칙입니다.
객체들이 서로 정보를 주고 받을 때는 의존 관계가 형성되는데, 이 때 객체들은 나름대로의 원칙을 갖고 정보를 주고 받아야 하는 약속이 있습니다.
여기서 DIP 원칙이란 추상성이 낮은 클래스보다 추상성이 높은 클래스와 통신 한다는 것을 의미합니다.
결과적으로 DIP란 비즈니스와 관련된 부분이 세부 사항에는 의존하는 않는 설계원칙을 의미합니다.
결론
이렇게 SOLID 원칙들에 대해 알아보았습니다.
위 내용에서 시사하는 바는 결국 추상화와 다형성입니다.
구체 클래스에 의존하지 않고 추상클래스 또는 인터페이스에 의존함으로써 우리는 유지보수하기 쉽고, 유연하고, 확장이 쉬운 소프트웨어를 만들 수 있습니다.
출처
https://www.nextree.co.kr/p6960/
https://mangkyu.tistory.com/194
https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)
https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84%EC%9D%98-5%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-SOLID
