웹프로그래밍 스터디 - 3.디자인패턴(1)-SOLID
-객체지향 원칙 (SOLID)
"웹프로그래밍 스터디"라는 주제로 글을 작성하고자 한다. 그동안 공부하고 싶었던 주제를 정리했는데, 웹개발의 전반적인 내용이 포함될 예정이다. 아마 바쁘다는 핑계로 글 올라오는 속도가 매우 느릴 수 있다. 하루에 한시간씩이라도 시간을 내서 스터디 해야한다!! 라고 내 자신에게 다짐해본다. 아래와 같은 목차로 진행 예정이며, 목차는 변경 될 수는 있다.
https://brunch.co.kr/@springboot/15
3.디자인 패턴
"웹프로그래밍 스터디"과정 중, 디자인 패턴을 공부해야 하는 이유는 아래와 같다.
올바른 "객체지향 프로그래밍"을 하기 위해서
"스프링 프레임워크"를 깊게 이해하기 위해서
"테스트 주도 개발"을 객체지향스럽게 하기 위해서
"리팩토링"을 제대로 하기 위해서
이런 이유가 아니더라도, 소프트웨어 공학을 공부하는 사람으로서 당연히 디자인 패턴을 제대로 알고, 실무에 적용할 수 있어야 한다. 오래전에 공부하고 그동안 잊고 있었던 "디자인 패턴" 을 이번 기회에 정리를 하고 싶어서 글을 작성하게 되었다.
해당 글은 예시가 억지스럽게 포함되어 있습니다. 그래서, 추후에 내용이 변경 될 수는 있습니다. 내용은 가볍게 참고만 부탁드리며, 좋은 의견 있으시면 언제든지 말씀 부탁드립니다. 시중에 좋은 책들이 많으니, 좋은 책을 통해서 공부하시면 좋을 듯 합니다. 이 글은.. 제 공부 겸 쓰는 글이에요.
3.1 객체지향 개발 5대 원리 : SOLID
"디자인 패턴"을 공부하기 전에 객체지향 개발 5대 원리에 대해서 이해하고 있어야 한다.
SRP : 단일 책임 원칙
OCP : 개방 폐쇄 원칙
LSP : 리스코프 치환 원칙
ISP : 인터페이스 분리 원칙
DIP : 의존 역전 원칙
3.1.1 SRP(Single Resonsibility Principle) : 단일 책임 원칙
어떤 클래스를 변경해야 하는 이유는 오직 하나 뿐이어야 한다. - 로버트 C. 마틴
객체 지향 프로그래밍에서 "SRP, 단일책임원칙"이란 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 말한다. 예시로 설명을 하겠다. "회사에서_나"라는 클래스가 있다고 가정해보겠다. 회사에서의 나는 "서비스 담당 개발자", "중간 관리자", "시니어 개발자" 의 역할을 수행하고 있다. 역할이 많아서인지, 나란 사람은 회사에서 참 피곤하고 힘들게 살고 있다. 그래도 이 모든 역할을 성실히 잘 수행해야 한다.
"회사에서_나" 클래스를, "SRP, 단일 책임 원칙" 에 맞게 개선한다면 어떻게 하면 좋을까? 역할을 분리해서 아래와 같이 클래스를 만들면 된다.
3.1.2 OCP(Open Closed Principle) : 개방 폐쇄 원칙
소프트웨어 엔티티는 확장에 대해서는 열려 있어야 하고, 변경에 대해서는 닫혀 있어야 한다. - 로버트 C.마틴
우리는 인터넷 웹사이트를 보기 위해서 인터넷 익스플로러, 크롬, 파이어폭스 등의 인터넷 브라우저를 사용한다. 아주 간단하게 그리면 아래와 같이 그릴 수 있는데, "IE", "Chrome", "FF" 클래스가 Browser 인터페이스를 구현하고 있다. 모든 클래스(인터넷 브라우저) 는 PageLoad() 메서드를 사용하여 웹사이트를 사용자에게 보여준다.
만약, 새로운 브라우저가 등장하면 어떻게 될까? 예를 들어서 "Safari" 라는 브라우저가 새로 나왔다고 가정하겠다. "Safari" 클래스는 "Browser" 인터페이스를 구현하고, PageLoad() 메서드를 구현하면 된다. 각 하위클래스(브라우저=IE, Chrome, FF, Safari) 에서의 "PageLoad()" 의 로직은 모두 다를 수는 있다. 각 브라우저가 사용하는 렌더링 기술이 모두 다르기 때문이다. 하지만 사용자는 어떤 렌더링 기술을 쓰는지 알 필요는 없다. 브라우저를 실행하고, 웹사이트를 접속하고, 화면을 보는 역할만 수행하면 된다. 이 역할들은 브라우저를 바꾼다고 해서 달라지지 않는다. 다시, 정리하면 아래와 같다.
브라우저 입장에서는, 확장에는 열려 있어야 한다. 신규 브라우저가 출시를 해도 "Browser" 인터페이스의 PageLoad 를 구현하면 된다.
사용자 입장에서는, 변경에 대해서는 폐쇄되어 있어야 한다. 신규 브라우저를 사용해도, 웹사이트를 접속하고, 화면을 보는 습관은 영향을 미치지 않는다.
3.1.3 LSP(Liskov Substitution Principle):리스코프 치환 원칙
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
LSP 원칙에 맞지 않는 잘못된 예위 조직도를 보면 하위 클래스는 상위 클래스의 역할을 수행하는데 문제가 있다. 리스코프 치환 원칙에 맞지 않는 클래스 구성이다. 아래와 같이 변경을 하였다.
하위에 존재하는 클래스는 상위 클래스의 역할을 할 수 있다. "아이폰개발자" 는 "개발자"의 역할을 할 수 있고, "개발자"는 "본부구성원"의 역할을 할 수 있다. 사실 많이 억지스러운 예시이지만, 이해를 돕기 위해서 쉽게 구조를 만들어봤다.
3.1.4 ISP(Interface Segregation Principle): 인터페이스 분리 원칙
클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다 - 로버트 C.마틴
인터페이스 분리 원칙은 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시켜서, 하위 클래스가 꼭 필요한 메서드만 사용할 수 있게 구현한다. 분리 원칙을 통해 시스템의 의존성을 낮춘다. "3.1.1 SRP:단일 책임 원칙" 에서 사용했던 예시를 변경해봤다.
"SRP:단일책임원칙"과 "ISP:인터페이스 분할 원칙" 은 같은 문제를 다른 방향으로 해결한 것이다. 어떤 원칙이 더 좋다 나쁘다를 판단할 수는 없을 것 같다. 프로젝트 환경에 맞게 적절하게 잘 사용해야 한다.
3.1.5 DIP(Dependency Inversion Principle) : 의존 역전 원칙
"DIP:의존역전원칙" 은 상위 계층이 하위 계층에 의존하는 전통적인 의존 관계를 반전 시킴으로, 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다.
첫째, 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.
둘째, 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다.
"OCP(Open Closed Principle) : 개방 폐쇄 원칙" 에서 예시로 들었던 예시를 다시 활용하겠다. 인터넷 사용자는 브라우저를 통해서 웹사이트를 볼 수 있다. 만약 크롬브라우저를 사용하는 사용자가 있는데, "사용자와 크롬" 사이에 의존성이 강하게 결합되어 있다면? 어떻게 될까? 크롬 브라우저를 버리고, 다른 브라우저를 사용하게 되는 경우가 있을 것이다. 사용자는 크롬에만 의존하고 있기 때문에, 분명히 클래스의 변경이 있을 것이다.
사용자가 구체적인 브라우저(크롬, IE) 에 의존하지 않고, 추상화 된 브라우저 인터페이스에만 의존하게 한다면, 크롬에서 IE 로 바꾸게 되어도 사용자는 영향을 받지 않는 형태로 구성이 된다.
이번 글에서는 [웹프로그래밍 스터디 - 3.디자인패턴(1)-SOLID] 라는 주제로, 객체지향 개발 원칙에 대해서 공부하였다. 다음 글에서는 [웹프로그래밍 스터디 - 3.디자인패턴(2)] 라는 주제로, 아래와 같이 8개의 디자인 패턴에 대해서 정리할 것이다.
어댑터 패턴
데코레이터 패턴
팩토리 메서드 패턴
프록시 패턴
싱글톤 패턴
전략 패턴
템플릿 메서드 패턴
템플릿 콜백 패턴
https://brunch.co.kr/@springboot/31
객체 지향 프로그래밍은 하루아침에 완성이 되는 일이 절대 아니다. 꾸준히 학습하고, 개발을 하면서 경험을 쌓아야 한다. 심화 학습을 통해서 추후에 [웹프로그래밍 스터디] 의 심화 과정에서 "리팩토링", "TDD", "DDD" 등 의 주제에서도 객체지향 개발에 대해서 글을 작성할 예정이다.
참고 서적
Head First Design Patterns - 에릭프리먼 외 지음, 한빛미디어 출판사
스프링 입문을 위한 자바 객체 지향의 원리와 이해 - 김종민님 지음, 위키북스 출판사
개발자가 반드시 정복해야할 객체 지향과 디자인 패턴 - 최범균님 지음, 인투북스 출판사
클린 소프트웨어 - 로버트 C. 마틴 지음, 제이펍 출판사
참고 링크
