요약
개발자 입장에서 수정하기 쉬운 소프트웨어를 만들기 위해서
클래스간 의존관계를 잘 관리해야 하는데
클래스 설계가 잘못되어가는 증상들을 잡기 위해서
5가지 원칙들을 세웠고
그 원칙들을 지킨 결과물이 바로 디자인패턴이라는 거죠.
-----------------------------
그러니 저는 패턴들을 보면서
어떤 원칙들이 어떻게 지켜졌는지 공부를 하면 될거같습니다.
그게 중간고사 문제겠죠 ㅠ
더 어렵게 낼거 같지만 ㅂㄷㅂㄷ..
모든 대학생 님들 중간고사 화이팅!
---------------------------------------------
우리는 개발자입니다.
소프트웨어을 만들어야 하죠.
그것도 좋은 소프트웨어말입니다.
좋은 소프트웨어의 기준이 뭘까요?
사용자 입장에서는 잘 동작하는 소프트웨어 ( Realibility )
개발자 입장에서는 개발하기 쉬운 소프트웨어 ( Maintanability ) 라고 할 수 있습니다.
Maintanability, 수정하기 편한 소프트웨어를 말하는 거죠.
소프트웨어를 개발하기 위해 우리는 객체지향프로그래밍( Objective Oriented Programming )을 사용합니다 ( 이하 OO )
OO의 특징이 무엇이길래 사용자 입장에서 Realibity, 개발자 입장에서 Maintanability를 만족 시킬 수 있을까요?
바로 우리가 열심히 배운 추상화, 캡슐화, 상속, 다형성 때문이죠.
복잡한걸 단순화 시키는 추상화
input 값을 핸들링 할 수 있는 캡슐화
코드의 재사용을 가능케 하는 상속
코드의 Felxbility를 가능케 하는 다형성 때문에 우리는 OO를 사용합니다.
하지만 여기서 문제가 생기죠.
상속과 다형성을 사용하다보면 클래스간 의존관계가 생기게 됩니다.
부모의 코드를 바꾸니까 원치않는 자식코드도 바뀌어버리는 상황
개발자 입장에서 Maintanability가 떨어지게 됩니다.
좋은 소프트웨어가 아닌거죠.
그래서 우리는 클래스간 의존관계를 관리해야합니다.
이를 Dependency Management.,DDM이라고 부르죠.
DDM의 3가지 원칙을 지키면 됩니다.
1. 서비스형태를 인터페이스로 구현한다.
2. 상속대신 인터페이스를 사용한다.
3. Design by contract를 지킨다.
상속대신 인터페이스를 활용하여
1,2번 원칙이 클래스간 Coupling을 낮추는 거라면
3번 원칙은 Cohesion을 높이는 것입니다.
Design by contract란 가각의 모듈이 가져야하는 기능만큼만 동작하는 것입니다.
input값을 3만큼 넣으면 계약에 써있는 대로 output을 3만큼 내뱉어야 하는 거라고 이해하시면 됩니다.
즉 DDM은 Coupling은 낮추고 Cohesion은 높이는 겁니다.
이를 통해서 좋은 소프트웨어를 만들 수 있죠.
우리는 무엇을 만들어야 하는 지는 알았습니다.
하지만 그것을 어떻게 만들어야하는지는 모르죠
어떻게 좋은 소프트웨어를 만드냐? 그 방법론이 에자일입니다.
에자일 방법론 그 중에서도 Extreme Programming을 활용합니다.;
짧은 주기, 테스트 주도, 리팩토링등등.. 을 활용하는 방법론이죠.
이를 통해 아주 조금씩 소프트웨어를 만들어 나갑니다.
여기서 의문이 생깁니다.
리팩토링이라는 명목 하에, 수많은 쓰레기 코드들만 만드는 거 아닌가?
큰 그림은 못보는거 아닌가? ( 소프트웨어 개발의 지혜 p97 )
그래서 에자일은 배가 산으로 가는 듯한, 설계가 잘못된거 같은 증상을 정의합니다.
냄새가 나는 듯한 Code smell이라고 불리는 7가지 증상이죠.
경직성, 취약성, 부동성, 점착성, 불필요한 복잡성, 불필요한 반복, 불투명성입니다.
프로그램 개발을 하다가 위에 7가지 증상이 나타나기 시작하면
악취를 제거하기 위한 5가지 객체 지향 원칙을 적용합니다.
그게 바로 SOLID원칙 이죠.
1. Single Respinsibilty Principle, SRP 단일 책임 원칙
2. Open-Closed Principle OCP 개방 폐쇄 원칙
3. Liskov Substitution Principle LSP 리스코프 교체 원칙
4. Dependency Inversion Principle DIP 의존 관계 역전 원칙
5. Interface Segregation Pinciple ISP 인터페이스 격리 원칙입니다.
SRP는 클래스는 단 한가지의 변경 이유만을 가져야 한다는 것입니다.
OCP는 소프트웨어가 확장에 대해서는 열여있어야 하고, 코드 수정에 대해서는 닫혀있어야 하는 것이죠.
LSP는 자식클래스는 자식의 기반타입(부모)에 대해서 치환 가능해야 하는 것입니다.
DIP는 클래스가 하위 수준의 클래스에 의존해서는 안되고 둘 모두 추상 클래스에 의존해야 한다는 것입니다.
또한 Concrete클래스 역시 추상화에 의존해야 한다는 걸 의미합니다.
ISP는 각 클라이언트가 각각의 인터페이스를 가져야한다는 것입니다.
각각의 원칙들을 잘 곱씹어 본다면
OCP는 만들고자 하는 소프트웨어의 목표를 정의하고
DIP는 소프트웨어의 메커니즘을 정의하고
LSP는 DIP의 보험이라는 걸 알 수 있습니다.
이 5가지 원칙들을 지켜서 나타나는 일련의 패턴이
바로 디자인패턴입니다.
디자인패턴들을 뜯어보면 이 SOLID원칙들을 지키다보니 나온 결과물이라 할 수 있죠.
