오늘은 객체지향 프로그래밍에대한 내용부터 SOLID원칙까지 테크톡 준비를 해서 스터디 팀원들에게 발표했다.
그래서 이 글은 배운 객체지향의 원칙 5가지 SOLID원칙에 대한 정리 내용이다.
1. SRP(Single responsibility principle) 단일 책임 원칙
먼저 단일 책임 원칙이다.
1번 원칙은 단어를 하나씩 떼어서 생각해보면 직관적으로 뜻을 이해할 수 있는 원칙이다.
단일 : 하나의 객체(클래스)
책임 : 해당 클래스가 할 수 있는 기능, 혹은 정보만
원칙 : 원칙
정도로 정리가 되는데, 하나의 클래스는 하나의 책임만 가지며, 클래스가 가지는 모든 서비스는 그 책임을 수행하는데 집중되어 있어야 한다. 라는 원칙인데, 이것만 들어보면 잘 이해가 안 될 수 있다 아래를 보자
고양이가 있다 해당 고양이는 나이와 이름 정보를 들고있으며, 먹기 말하기 걷기와 같은 활동을 할 수 있다. 그런데 아래에 print라는 기능이 고양이에게 들어간다면? 저것은 과연 고양이가 책임 져야할 기능일까? 하는 것이다.
해당 그림으로 본다면 고양이는 고양이의 기능,정보만을 책임 져야한다.
이것이 단일 책임의 원칙이다.
2. OCP(Open Close Principle) 개방폐쇄의 원칙
다음은 개방 폐쇄의 원칙이다.
이 원칙은 상속과 추상화나 다형성과 긴접한 연관이 있는 원칙이다.
이 원칙도 직관적으로 이해가 가능하다.
확장(extends)에는 개방하며, 수정(modification)에는 폐쇄 하라는 원칙이다.
예를 들어 아래 사진을 보자
왼쪽부터 동물 클래스들이 있고 정보 그리고 hey라는 함수와, 해당 함수를 호출하는 코드이다.
이 코드상으로 볼 때 만일 동물의 종류가 늘어난다고 가정하면? 프로그램이 더 복잡해지고 거대해진다고 생각했을 때
hey라는 함수를 계속해서 수정해주어야 할것이다. 예를들어 소(cow)를 추가한다고 생각하면 if예외처리에 또 print("moo") 같은걸 추가해 줘야할 것이다.
그래서 여기서 두번째 원칙에서 설명한 "수정에는 폐쇄"가 나오게 된다.
그럼 어떻게 동물 종류를 늘리느냐? 어떤 구조로 프로그램을 해야하느냐?
이런 형태가 된다.
동물들별로 클래스 내에 개개인이 호출하는 hey함수가 따로 있으며 동물들은 각각 Animal을 상속 받는다.
이런식으로 설계하면 동물이 늘어난다해도 Animal의 내부의 함수를 계속 수정해줄 필요가 없다. Animal이란 클래스가 더욱 큰 범위로 확장 된것을 볼 수 있다. 이것이 "확장에는 개방" 이라는 것이다.
3. LSP(The Liskov Substitution Principle) 리스코프 치환 원칙
세번째는 리스코프 치환원칙이다.
이번에는 이름만으로 직관적으로 이해하기가 힘들다.
하지만 내용은 매우 쉽다.
Object T는 T의 서브 Object S 가 있을 때 서브 Object중 어느것으로 변경하더라도 프로그램이 정상동작 해야한다. 라는 원칙인데 이해하기 어렵다. 예제를 보자
다음과 같이 고양이 클래스와 고양이를 상속받은 검은고양이 클래스가 있을 때, 가운데와같이 넣어줘도 정상동작을 해야한다는 원칙이다.
이 원칙은 이름에 비해 이해가 쉬웠다 넘어가자.
4. ISP(Interface Segregation Principle) 인터페이스 분리 원칙
인터페이스 분리원칙은 Client는 사용하지도 않을 메서드들에 의존하게 만들어선 안 되며, 큰 인터페이스를 더 작은 단위로 분리하는게 좋다.란 원칙이다.
이게 무슨 뜻이냐
이렇게 자동차와 수륙양용 자동차가 있는데, 수륙양용 자동차같이 인터페이스르 만들어서 보트를 만들 때 저 인터페이스를 써서 쓰지 않는 메서드를 늘리기 보다 더 작게 분리해서 자동차와 보트 인터페이스로 만들어서 쓰라는 뜻이다.
그 작은 단위들을 이용해 조합해서 아래 사진같이 수륙 양용 자동차를 만들어 사용하라는 것이다.
이렇게 2개의 인터페이스를 implements받아서 수륙양용 자동차를 만들면 된다는 이야기다.
5. DIP(Dependency Inversion Principle) 의존성 역전의 원칙
마지막 다섯째 의존성 역전의 원칙이다.
의존성 역전의 원칙은 DI개념을 알고있다면 바로 이해할 수 있는데, 상위레벨 모듈은 절대 하위레벨 모듈에 의존하지 않고 둘 다 추상화에 의존해야한다.
이 원칙의 의미는 무엇이냐, 한쪽 방향으로 의존하는 관계를 가운데 추상화를 둬서 서로 추상화를 의존하도록 만들어 하위 클래스의 의존의 역전이 일어나게 만들어야한다는 의미인데,
원래는 위와같이 의존하고있는 방향을 가운데 추상화를 의존하게 함으로 저수준 모듈의 의존방향을 역전시킨다. 다음 사진같이 말이다.
참고로 Spring에서는 그 DI역할을 Ioc컨테이너 에서 해주고 있다. Ioc컨테이너에 대한건 다음에 또 다뤄보겠다.
아래 빨간 화살표를 보면 의존성의 방향이 역전된 것을 볼 수 있다.
이렇게 의존성의 역전을 해야하는 이유는 클래스간 관계를 좀 더 느슨하게 하기 위함이다. 이후 기능추가나 유지보수에 더욱 이점을 가져올 수 있는 설계 방법이다.
이상 SOLID원칙이었다.
팀원들과 함께 테크톡을 하면서 CS지식을 공부할 때마다 새로운 공부할게 늘어나는 것 같다.
오늘은 SOLID원칙을 했는데, 하고보니 정말 기초가 중요하다고 느꼈다. 알고있고 쓰고있는 내용이지만 다시한번 제대로 공부해보고 확실히 알아가는건 정말 천지차이인것 같다.
