Week5 SOLID

About this offer

S.O.L.I.D 기초개념 1) SOLID란 유연성(새로운 기능 쉽게 추가), 유지보수성, 재사용성 끊임없이 변화하는 소프트웨어에 유연하게 대처 결합도 낮추고 응집도 높이기 2) 결합도와 응집도 결합도: 모듈과 모듈간의 의존 정도 <-> 클래스 간의 자유로운 교체 결합도 낮게! 응집도: 한 모듈내 구성요소의 연관정도 - 클래스 내부가 하나의 목적에 집중 응집도 높게! //안 좋은 코드 class Player { Sword s = new Sword(); Gun g = new Gun(); void attack() { s.slash(); g.shoot(); } } : Player라는 하나의 클래스에서 무기를 생성하고 관리 -> 검과 총을 모두 들음 -> 여러 책임 혼합되어 응집도가 낮음. 또한 새로운 무기 추가와 교체가 어려움 -> 결합도 높음 //좋은 코드 interface Weapon { void use(); } class Sword implements Weapon { public void use() { System.out.println("칼로 베었다!"); } } class Gun implements Weapon { public void use() { System.out.println("총을 발사했다!"); } } class Player { Weapon w; public Player(Weapon w) { // TODO Auto-generated constructor stub this.w=w; } public void attack() { w.use(); //총이든 검이든 상관없이 공격가능 } } : 무기를 직접 생성하는 대신 주입받음! Player는 attack()이라는 책임 하나에 집중 -> 응집도 높아짐 무기 종류가 바뀌더라도 Player 코드는 영향이 없음 -> 결합도 낮아짐 총과 검을 Weapon이라는 인터페이스를 구현시켜 따로 클래스를 만듦으로써 사용자가 무기를 무얼 선택하든 바로 w.use만 쓰면 공격할 수 있게 됨. 이런 코드는 나중에 무기가 추가되었을 때도 따로 함수를 사용할 필요 없이 동일하게 Weapon을 구현시킨 클래스를 만들면 되기 때문에 w.use를 통해 간단하게 공격할 수 있음. 3) SOLID의 필요성 이미 존재하는 레거시 코드를 좋은 코드로 만드는 기술이자 원칙임: 기존 코드를 어떻게 개선할까에 대한 방향 제시 기술적 부채를 막는 실용적 방법: 빠른 개발속도 < 처음부터 차근차근 유지보수와 확장이 쉽게! 변화에 강하고 유연한 코드로 전환하는 힘 4) SOLID의 활용 리펙토링 스프링 프레임워크의 핵심: IoC/DI cf. IoC(제어의 역전)과 DI(의존성 주입)은 DIP(의존성 역전 원칙)와 OCP(개방-폐쇄 원칙)를 가장 잘 구현한 대표적 예시 유연한 아키텍처 설계 ex) MSA SOLID 원칙 1) S: 단일 책임의 원칙 클래스는 단 하나의 책임에만 집중 //before class ReportService { public void generateReport() {//보고서작성} public void sendEmail() {//이메일전송} } //after class ReportGenerator{ public void generateREport(){//보고서작성} } class EmailSender { public void sendEmail() {//이메일 작성} } : 하나의 클래스에 있던 함수들을 두개의 클래스로 분리 -> 유지 보수가 용이해짐 **2) O: 개방-폐쇄의 원칙** - 확장에 개방, 수정에 폐쇄 - 기존 코드를 변경하지 않고도 새로운 기능을 추가할 수 있어야 함 - 추상화에 의존O, 구체적 클래스에 의존X  : 결제방식을 추가할 때마다 PaymentProcesssor라는 기존의 클래스를 수정할 필요 없이, 결제방식이라는 추상 인터페이스를 구현한 새로운 결제방식 클래스를 만들 수 있다 **3) L: 리스코프 치환의 원칙** - 하위 타입은 언제나 상위 타입으로 대체될 수 있어야 한다 - 자식 클래스는 부모 클래스가 사용되는 곳에 문제없이 들어갈 수 있어야 함 (IS-A관계)  : 타조클래스가 새 클래스를 상속했을 때, 타조는 새의 특성인 fly를 하지 못한다는 문제점 발생.(자식 클래스가 부모 클래스에서 사용하지 못하는 부분이 생김!) -> 새를 Flyling Bird와 Walking Bird로 분리하여 자식클래스가 부모 클래수의 규약을 모두 지킬 수 있도록(IS-A 관계 명확히 따르도록) 수정. **4) I: 인터페이스 분리의 원칙** - 자신이 사용하지 않는 메소드에 의존해서는 안됨(책임 위주로 보기) - 하나의 거대한 인터페이스 < 여러 개의 구체적인 인터페이스 -> 인터페이스를 기능별로 분리! - 인터페이스 변경 시 영향받는 클래스 최소화(인터페이스의 기능 최소화)  : 로봇은 eat()을 구현할 필요가 없으므로, 원래 하나의 인터페이스로 합쳐져있던 work()와 eat() 메소드를 각각의 인터페이스로 분리 **5) D: 의존성 역전의 원칙(DIP)** - 상위 모듈은 하위모듈에 의존해서는 안됨. 둘 다 추상화에 의존해야함! (하위모듈은 변하기 쉽기 때문에, 변하기 어렵고 빈도 낮은 인터페이스나 추상클래스에 의존하라는 의미)  : 상위 모듈은 추상화계층의 계약만 알면 되고, 하위모듈은 그 계약을 충족하는 방식으로 구현하기만 하면 됨. 새로운 구현체(AirConditioner, CoffeeMachine)이 추가되더라도 상위모듈(SmartHomeSwitch)는 수정할 필요가 없음 ### 제어의 역전(IoC)와 의존성 주입(DI) **1) 제어의 역전(IoC)** - 프레임워크(전문가): 추상화에 의존할 때 구체적인 구현체를 넣어줌 -> 프레임워크를 통해 제어방법을 역전시키고 모든것을 관리함 - 구현방법: 의존성(DI)을 주입 **2) 의존성 주입(DI)** - DI: IoC를 구현하는 대표적 기술 - 클래스 내부에서 new를 통해 의존 객체를 직접 생성하는 것이 아니라, 외부(프레임워크)에서 의존 객체를 '주입'받는 방식 - 구현방법 - 생성자주입: 의존성 불변, 필수 의존성 명확, 테스트 용이 - Setter 주입 - 필드 주입