Object Oriented Programming SOLID
기초 공부를 생각하다 문뜩,,,
명확하게 모르는것 같아서 정리,,,
1. Single Responsibility Principle(단일 책임 원칙)
객체는 단 하나의 책임만 가져야 한다.
잘못된 예
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | class Text { String text; String author; int length; String getText() { ... } void setText(String s) { ... } String getAuthor() { ... } void setAuthor(String s) { ... } int getLength() { ... } void setLength(int k) { ... } /*methods that change the text*/ void allLettersToUpperCase() { ... } void findSubTextAndDelete(String s) { ... } /*method for formatting output*/ void printText() { ... } } |
Text class는 text를 출력하는 처리를 하고 있다. 하지만 출력 기능에 대한 변화가 이루어 지게 된다면 Text class는 계속하여 변경 되어야 한다.
Text class는 다른 역할을 하는 코드들과 결합 관계를 가지게 된다는 뜻
출력 기능을 제거하고 다른 class에서 해당 기능을 처리 하도록 하자.
수정 예
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | class Text { String text; String author; int length; String getText() { ... } void setText(String s) { ... } String getAuthor() { ... } void setAuthor(String s) { ... } int getLength() { ... } void setLength(int k) { ... } /*methods that change the text*/ void allLettersToUpperCase() { ... } void findSubTextAndDelete(String s) { ... } /*method for formatting output*/ void printText() { ... } } class Print { Text text; Printer(Text t) { this.text = t; } void printText() { ... } } |
2. Open / Closed(개방 폐쇠 원칙)
특정 클래스는 그 클래스를 수정하지 않으면서 확장(extension) 가능해야 한다
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | public class FacebookUser{ public boolean isValidUser() { System.out.println("FacebookUser: valid user..."); /*Logic to valid user*/ return true; } } // UserRegisterManager class에 addUser(TwitterUser user) method가 추가될때 추가 되어야 하는 class //public class TwitterUser{ // // public boolean isValidUser() { // System.out.println("FacebookUser: valid user..."); // /*Logic to valid user*/ // return true; // } //} public class UserRegisterManager { public void addUser (FacebookUser user) { if(user.isValidUser()) { System.out.println("UserRegisterManager: valid user."); } } // 추가 되는 method public void addUser (TwitterUser user) { if(user.isValidUser()) { System.out.println("UserRegisterManager: valid user."); } } } |
UserRegisterManager class에 addUser (TwitterUser user) method가 추가되어야 한다고 가정한다.
새로운 기능에 대한 지원을 추가하기 위해 클래스를 수정해야합니다. 사실, 우리는 우리가 ClaimApprovalManager 클래스를 수정 할 때 이미 쓴 첫 번째 인스턴스에 개방 폐쇄 원칙을 위반했다. 변화가 많은 시스템일 경우 변경에 주의를 기울어야 할 부분이 많아진다.
응용 프로그램이 취약하고 확장하는 비용 발생하며 오류가 발생할 확률이 높아진다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | public abstract class User { public abstract boolean isValidUser(); } public class FacebookUser extends User{ public boolean isValidUser(){ System.out.println("FacebookUser: valid user..."); /*Logic to valid user*/ return true; } } public class TwitterUser extends User{ public boolean isValidUser(){ System.out.println("TwitterUser: valid user..."); /*Logic to valid user*/ return true; } } public class UserRegisterManager { public void processClaim(User user){ if(user.isValidUser()){ System.out.println("UserRegisterManager: valid user"); } } } |
3. 리스코프 치환 원칙(Liskov Substitution Principle)
서브타입은 언제나 자신이 기반타입 (base type)으로 교체할 수 있어야 한다.
LSP란 상위형 P가 있고 이걸 확장하는 하위형 C가 있을 때 P를 C로 치환할 수 있어야 한다 는 말이다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | class TransportationDevice { String name; String getName() { ... } void setName(String n) { ... } double speed; double getSpeed() { ... } void setSpeed(double d) { ... } Engine engine; Engine getEngine() { ... } void setEngine(Engine e) { ... } void startEngine() { ... } } class Car extends TransportationDevice { @Override void startEngine() { ... } } |
상위 코드는 문제가 없다. 자동차는 확실히 운송장치이며, 여기에 우리는 슈퍼 클래스의 startEngine() method를 override 하였다.
다른 운송장치를 추가 해보도록 하자.
1 2 3 4 | class Bicycle extends TransportationDevice { @Override void startEngine() /*problem!*/ } |
추가한 운송장치를 보면 자전거는 엔진을 가지고 있지 않으며 엔진을 시작 할 수 없다.
수정을 해보자.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | class TransportationDevice { String name; String getName() { ... } void setName(String n) { ... } double speed; double getSpeed() { ... } void setSpeed(double d) { ... } //engine 관련 정보 삭제 } class DevicesWithoutEngines extends TransportationDevice { void startMoving() { ... } } class DevicesWithEngines extends TransportationDevice { Engine engine; Engine getEngine() { ... } void setEngine(Engine e) { ... } void startEngine() { ... } } class Car extends DevicesWithEngines { @Override void startEngine() { ... } } class Bicycle extends DevicesWithoutEngines { @Override void startMoving() { ... } } |
4.Interface Segregation Principle(인터페이스 분리 원칙)
client는 자신이 사용하는 interface의 변경으로 자신을 변경하는 것은 용납하지만 자신과 관련되지 않는 interface의 변화로 인해 자신이 변하는 것은 용납해서는 안된다.
하나의 일반적인 interface 보다 구체적인 여러 개의 Interface가 낫다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | public interface Toy { void setPrice(double price); void setColor(String color); void move(); void fly(); } public class ToyHouse implements Toy { double price; String color; @Override public void setPrice(double price) { this.price = price; } @Override public void setColor(String color) { this.color=color; } @Override public void move(){} @Override public void fly(){} } |
상위 코드를 보면 Toy interface를 상속받은 ToyHouse는 move(), fly() methode를 사용하지 않아도 구현해야만 한다.
이러한 위반은 코드의 가독성과 개발자를 혼란스럽게 한다.
1 2 3 4 5 6 7 8 9 10 11 12 13 | public interface Toy { void setPrice(double price); void setColor(String color); } // interface를 작게 분리한다. public interface Movable { void move(); } public interface Flyable { void fly(); } |
인터페이스를 작게 분리 하였으면 각 필요한 class의 기능들을 구현한다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | public class ToyHouse implements Toy { double price; String color; @Override public void setPrice(double price) { this.price = price; } @Override public void setColor(String color) { this.color=color; } @Override public String toString(){ return "ToyHouse: Toy house- Price: "+price+" Color: "+color; } } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | public class ToyPlane implements Toy, Movable, Flyable { double price; String color; @Override public void setPrice(double price) { this.price = price; } @Override public void setColor(String color) { this.color=color; } @Override public void move(){ System.out.println("ToyPlane: Start moving plane."); } @Override public void fly(){ System.out.println("ToyPlane: Start flying plane."); } @Override public String toString(){ return "ToyPlane: Moveable and flyable toy plane- Price: "+price+" Color: "+color; } } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | public class ToyBuilder { public static ToyHouse buildToyHouse(){ ToyHouse toyHouse=new ToyHouse(); toyHouse.setPrice(15.00); toyHouse.setColor("green"); return toyHouse; } public static ToyCar buildToyCar(){ ToyCar toyCar=new ToyCar(); toyCar.setPrice(25.00); toyCar.setColor("red"); toyCar.move(); return toyCar; } public static ToyPlane buildToyPlane(){ ToyPlane toyPlane=new ToyPlane(); toyPlane.setPrice(125.00); toyPlane.setColor("white"); toyPlane.move(); toyPlane.fly(); return toyPlane; } } |
5.Dependency Inversion Principle(의존 역전 원칙)
구현 클래스가 아닌 인터페이스 타입을 사용하라는 규칙이다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | public class LightBulb { public void turnOn() { System.out.println("LightBulb: Bulb turned on..."); } public void turnOff() { System.out.println("LightBulb: Bulb turned off..."); } } public class ElectricPowerSwitch { public LightBulb lightBulb; public boolean on; public ElectricPowerSwitch(LightBulb lightBulb) { this.lightBulb = lightBulb; this.on = false; } public boolean isOn() { return this.on; } public void press(){ boolean checkOn = isOn(); if (checkOn) { lightBulb.turnOff(); this.on = false; } else { lightBulb.turnOn(); this.on = true; } } } |
상위 코드에서 ElectricPowerSwitch class에 LightBulb class의 참조 필드를 사용하였다. ElectricPowerSwitch 생성자에서 lightBulb 객체를 생성하고 필드에 할당한다. 그 다음 ElectricPowerSwitch의 상태를 반환하는 isOn() method를 사용하였다. press() method에 state를 기준으로 turnOn() 및 turnOff() method를 호출한다.
상위 코드로 우리는 switch를 끄고 켤수 있다. 그러나 고레벨에 있는 ElectricPowerSwitch class는 저레벨의 LightBulb class를 직접 참조한다. 고레벨과 저레벨의 차이는 여러가지 일을 복합적으로 한다면 고레벨(ex:파일을 불러와 암호화 여부를 확인하고 backup 폴더에 저장하고 경로를 json으로 전달 해준다.), 저레벨은 단순한 기능만을 한다(ex:파일에서 바이트 데이터를 읽어온다.)
문제를 해결하기 위해서 인터페이스를 만들고 ElectricPowerSwitch, LightBulb classes를 구현한다.
1 2 3 4 5 6 7 8 9 | public interface Switch { boolean isOn(); void press(); } public interface Switchable { void turnOn(); void turnOff(); } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | public class ElectricPowerSwitch implements Switch { public Switchable client; public boolean on; public ElectricPowerSwitch(Switchable client) { this.client = client; this.on = false; } public boolean isOn() { return this.on; } public void press(){ boolean checkOn = isOn(); if (checkOn) { client.turnOff(); this.on = false; } else { client.turnOn(); this.on = true; } } } |
1 2 3 4 5 6 7 8 9 10 11 |
1 2 3 4 5 6 7 8 9 10 11 |
Single Responsibility Prinsciple
