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