[디자인패턴] SOLID

이나겸's avatar
Nov 12, 2024
[디자인패턴] SOLID

객체지향 설계 5원칙

SRP(Single Responsibility Principle)

  • 단일 책임 원칙
  • 하나의 클래스는 하나의 책임만 가져야 함
  • 클래스는 그 책임을 완전히 캡슐화 해야 함
 
package ch01; // srp (Single Responsibility Principle) // 하나의 클래스는 하나의 책임을 가지는게 좋다 (의무가 아니라 권장) public class Doorman { // 이 클래스의 책임 public void 쫓아내(Cat cat) { System.out.println(cat.getName() + "쫓아내"); } }

OCP(Open Closed Priciple)

  • 개방 폐쇄 원칙
  • 소프트웨어 요소(클래스, 모듈, 컴포넌트 등등)는 확장에는 개방되어 있어야 하지만 변경에는 폐쇄되어야 함
  • 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있는 설계가 되어야 함
  • 추상화와 다형성이 중요 메커니즘
 
// 문지기(Doorman)가 고양이(Cat)에 의존하기 때문에, // 쥐(Mouse)로 변경하면 기존 코드를 수정해야 함 // ⇒ OCP 위배 package ch01; // 쥐 Object public class Mouse { private String name = "쥐"; // private 변수라 접근 불가능해서 // 갖다쓰려면 getter 이용 public String getName() { return name; } } package ch01; public class Cat { private String name = "고양이"; // private 변수라 접근 불가능해서 // 갖다쓰려면 getter 이용 public String getName() { return name; } } package ch01; // srp (Single Responsibility Principle) // 하나의 클래스는 하나의 책임을 가지는게 좋다 (의무가 아니라 권장) public class Doorman { // 이 클래스의 책임 public void 쫓아내(Cat cat) { System.out.println(cat.getName() + "쫓아내"); } } package ch01; public class App { public static void main(String[] args) { Doorman doorman = new Doorman(); Cat cat = new Cat(); doorman.쫓아내(cat); } }
// Animal 클래스를 만들고, 추상화해서 OCP에 위배되지않게 해결 package ch01; // 추상 클래스 => 상속 가능 public abstract class Animal { public abstract String getName(); } package ch01; // 쥐 Object // Animal 상속 public class Mouse extends Animal{ private String name = "쥐"; // 부모와의 동일 메소드 오버라이드 public String getName() { return name; } } package ch01; // 고양이 Object // Animal 상속 public class Cat extends Animal { private String name = "고양이"; // 부모와의 동일 메소드 오버라이드 public String getName() { return name; } } package ch01; // srp (Single Responsibility Principle) // 하나의 클래스는 하나의 책임을 가지는게 좋다 (의무가 아니라 권장) public class Doorman { // DIP (Dependency Inversion Principle, 의존성 역전 원칙) // 구체적인것(Mouse, Cat)에 의존하지말고 추상적인것(Animal)에 의존하라 // 이 클래스의 책임 public void 쫓아내(Animal animal) { System.out.println(animal.getName() + " 쫓아내"); } } package ch01; public class App { public static void main(String[] args) { Doorman doorman = new Doorman(); Animal cat = new Cat(); Animal mouse = new Mouse(); doorman.쫓아내(cat); doorman.쫓아내(mouse); } }

LSP(Listov Substitution Priciple)

  • 리스코프 치환 원칙
  • 서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 함 ⇒ 상위 타입은 항상 하위 타입으로 대체될 수 있어야 함
  • 다형성을 지원하기 위한 원칙 - 상속을 잘 활용할 것
notion image

ISP(Interface Segregation Principle)

  • 인터페이스 분리 원칙
  • 자신이 사용하지 않는 인터페이스는 구현하지 말아야 하고 꼭 필요한 인터페이스만 상속해야 함 ⇒ 최소한의 기능만 제공하면서 하나의 역할에 집중해야 함 (인터페이스의 단일 책임)

DIP(Dependency Inversion Principle)

  • 의존관계 역전 원칙
  • 추상화된 것은 구체적인 것(Object)에 의존하지 말고, 추상화된 것(abstract)에 의존해야 함
 
package ch01; // 추상 클래스 => 상속 가능 public abstract class Animal { public abstract String getName(); } package ch01; // 쥐 Object // Animal 상속 public class Mouse extends Animal{ private String name = "쥐"; // 부모와의 동일 메소드 오버라이드 public String getName() { return name; } } package ch01; // 고양이 Object // Animal 상속 public class Cat extends Animal { private String name = "고양이"; // 부모와의 동일 메소드 오버라이드 public String getName() { return name; } } package ch01; // srp (Single Responsibility Principle) // 하나의 클래스는 하나의 책임을 가지는게 좋다 (의무가 아니라 권장) public class Doorman { // DIP (Dependency Inversion Principle, 의존성 역전 원칙) // 구체적인것(Mouse, Cat)에 의존하지말고 추상적인것(Animal)에 의존하라 // 이 클래스의 책임 public void 쫓아내(Animal animal) { System.out.println(animal.getName() + " 쫓아내"); } } package ch01; public class App { public static void main(String[] args) { Doorman doorman = new Doorman(); Animal cat = new Cat(); Animal mouse = new Mouse(); doorman.쫓아내(cat); doorman.쫓아내(mouse); } }
Share article

Nakyeom's Study