[OOP] 객체지향 설계 원리

객체지향 설계 원리

1. SOLID

SOLID는 객체지향 설계 원리 중 가장 중요한 다섯가지 원리 SRP(Single Responsibility Principle), OCP(Open-Closed Principle), LSP(LIskov Substitution Principle), ISP(Interface Substitution Principle), DIP(Dependency Inversion Principle)를 말한다.

1.1 SRP

단일 책임 원리 A class should have only one reason to change.

• 소프트웨어의 가장 기본적인 설계 원리 중 하나는 모듈은 응집성이 높아야 한다는 것이다. (high-cohesion) 객체지향 프로그래밍에서 기본 모듈은 클래스이다. SRP에 의하면 한 클래스는 단일 책임을 가져야 한다.
• 한 클래스는 수정되어야 할 이유가 하나 밖에 없어야 한다.
• 한 클래스는 여러 멤버 변수를 유지할 수 있고, 여러 메소드를 가질 수 있지만 SRP에 의하면 이들은 모두 공통으로 한 가지 책임을 위해 필요해야 한다.
• 예를 들어 직원정보를 유지하는 Employee 클래스에 급여를 계산하는 메소드와 직원 정보를 데이터베이스에 저장하는 메소드를 가지고 있으면 이 클래스를 수정할 이유는 몇가지인가? 최소 두가지이다.
• 급여를 측정하는 방법이 바뀌면 변경되어야 하고 + 데이터베이스가 바뀌거나 데이터베이스의 레코드 모습이 바뀌어도 변경되어야 한다.
  • 모든 것은 그것의 존재할 위치가 있고, 모든 것은 원래 있어야 할 곳에 있어야 한다.
  • 클래스를 스위스 포켓 나이프처럼 만들면 안된다.
  • 한 가지 일만 해야 하고, 그 일을 잘 해야 한다.
  • 할 수 있다고 하여 그것을 꼭 해야 하는 것은 아니다.

1.2 OCP

열림 닫힘 원리 Classes should be open for extension, but closed for modification.

• OCP에 의하면 클래스는 확장에 대해서 열려 있지만 변화에 대해서는 닫혀 있어야 한다. 클래스는 설계 후 구현이 끝나 정상적으로 동작하면 더 이상 수정할 필요가 없어야 하ㅐㄴ다는 측면에서 닫을 수 있어야 한다.
• 이렇게 닫은 경우에도 기능을 확장할 수 있어야 한다. 클래스가 새 기능이 필요하더라도 이 클래스를 수정하지 않고 기능을 추가할 수 있어야 한다.
• 닫혀 있는 클래스를 확장하는 방법은 2가지가 있다.
  • 상속을 활용함 -->> 상속은 is-a 관계가 성립해야 하며, 클래스 간 관계가 고정되기 때문에 유연하지 못할 수 있다.
  • 포함관계를 활용함
• 닫혀 있는 클래스를 더 유연하게 확장하는 방법은 포함 관계를 이용하는 것이다. 클래스의 어떤 기능을 다르 클래스에 위임하고 그 클래스의 객체를 상위 타입 멤버 변수에 유지하면 언제든지 유지하고 있는 객체를 바꾸어 기능을 바꿀 수 있다. 또 포함 관계를 이용하면 다양한 것들을 조합하여 새로운 특성의 클래스를 만들 수 있다. 기능확장과 관련하여 늘 생각해야 하는 설계 원리는 프로그램에서 변할 수 있는 부분과 변하지 않는 부분을 구분하는 원리와 구체적인 클래스 대신에 추상 타입에 의존하는 원리이다.

1.3 LSP

리스코프 치환 원리 If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.
객체지향의 가장 핵심 요소 중 하나가 상속이다. 상속은 한 클래스를 이용하여 새로운 클래스를 쉽게 정의할 수 있도록 해준다. 클래스 P를 상속하여 클래스 C를 정의하면 클래스 C는 P의 모든 상태와 행위를 다시 정의하지 않아도 된다.

• 상속은 코드를 재사용할 수 있도록 해주고, 코드 중복을 없애준다. 하지만 이것만이 상속의 장점은 아니다. 상속은 상위 클래스 타입을 후속 클래스를 아우르는 공통 리모컨으로 사용할 수 있도록 해준다. 즉 상위 타입 변수에는 다양한 종류의 객체를 유지할 수 있다. 이를 통해 다형성을 활용할 수 있고, 범용 프로그래밍이 가능하다.
• 코드 재사용이 가능하다고 무조건 상속하면 매우 어색한 코드를 만들 수 있다. 상속은 반드시 is-a 관계가 성립하는 경우에만 사용해야 한다. Pet 클래스가 이름을 유지하고 있다고 하여 Pet을 상속하여 사람을 정의하면 사람은 애완동물이다 라는 명제가 성립하지 않기 때문에 올바른 상속 관계라 할 수 없다.
• 객체지향에서는 클래스나 interface를 이용하여 새 클래스를 정의할 수 있도록 해준다. 이와 관련하여 subclassing이라는 개념과 subtyping이라는 개념이 있다.
  • subclassing : 한 클래스의 내부 구현을 재사용하는 것
  • subtyping : 외부 모습만 재사용하는 것
• subcalssing 하면 subtyping이 무조건 제공되지 않는다.
• 하지만 LSP 원리에 의하면 subclassing도 subtyping을 제공해야 한다.
• LSP가 위배되지 않도록 프로그래밍 언어는 문법적으로 다음을 보장
  • 메소드 인자의 반변성(contravariance)
  • 메소드 반환타입의 공변성(covariance)
• 공변성이란 자식 클래스에서 메소드를 재정의할 때 특정 타입이 특수화되는 경우를 말하고, 반변성은 재정의하면서 일반화되는 경우를 말한다.
• 메소드 인자는 변하지 않거나 일반화화면 타입 안전성에 문제가 없으며, 메소드 반환타입은 변하지 않거나 특수화하면 타입 안전성에 문제가 없다.
• 예를 들어 다음과 같은 클래스가 있을 때, CatShop은 메소드의 인자와 반환타입을 모두 특수화하여 재정의하 있고, DogShop은 메소드의 인자와 반환타입을 모두 일반화하여 재정의하고 있다.
• class PetShot{ Pet getPet(){} void addPet(Pet pet){} } class CatShop extends PetShot{ Cat getPet(){} // 공변성 O void addPet(Cat cat){} // 재정의로 인식되지 않음 } class DogShop extends PetShot{ Object getPet(){} // 반변성 X void addPedt)Object pet){} // 재정의로 인식하지 않음 반변성 }
• 자바는 메소드 반환타입의 공변성은 지원하지만 인자의 반변성은 지원하지 않는다. 자바는 인자의 경우에는 정확하 게 일치하여야 한다. C++도 마찬가지이다. C#은 메소드 반환타입의 공변성도 지원하지 않는다. 자바는 checked 예외의 경우 자식이 더 많이 발생하면 문법적으로 오류를 주고 있지만 예외 발생을 문법적으로 엄격하게 검사해 주는 언어는 거의 없다.
• 메소드를 재정의할 때 문법적인 측면뿐만 아니라 다음과 같은 논리적 측면까지 고려해야 LSP가 위배되지 않는다.
  • 메소드의 사전 조건은 강화되지 않아야 한다.
  • 메소드의 사후 조건은 약화되자 않아야 한다.
  • 상위 타입의 불변 조건은 계속 유지되어야 한다.
  • (히스토리 규칙) 객체는 자신의 메소드를 통해서만 상태가 변경될 수 있어야 한다.

1.4 ISP

인터페이스 분리 원리 Clients should not be forced to depend upon interfaces that they do not use.

• ISP 원리란 클래스는 자신이 필요하지 않는 메소드를 구현하도록 강요되지 않아야 한다는 원리이다. 이 원리에 충실하기 위해 클래스나 interface가 제공하는 메소드의 수는 최소화되어야 한다. 상속은 정적 관계이기 때문에 자식 클래스가 상속하는 메소드를 취사 선택할 수 없다. 이 문제를 극복하기 위해 빈 메소드를 이용하여 필요 없는 메소드를 재정의하는 경우가 있지만, 이 원리에 의하면 이것은 잘못된 설계의 결과에 해당한다. 이 문제는 LSP 측면에서도 살펴볼 수 있다.
• 살아 있는 것을 정의하기 위해 다음과 같은 클래스를 정의
• public interface LivingThing{ void eat(); void walk(); void swim(); void fly(); }
• 직관적으로 살아 있는 모든 것이 날지 못하고, 수영도 못하고, 땅에서 걸을 수 없다. 따라서 쉽게 잘못 정의된 것임을 알 수 있다. 모든 살아 있는 것은 먹어야 하기 때문에 eat만 유지하고 다른 3개는 다음과 같이 모두 분리하는 것이 바람직하다.

public interface LivingThing{
  void eat();
}

public interface LivingInSky extends LivingThing{
  void fly();
}

public interface LivingInWater extends LivingThing{
  void swim();
}

public interface LivingOnLand extends LivingThing{
  void walk();
}

• 오리, 개구리 클래스는 다음과 같이 정의할 수 있다.

public class Duck implements LivinInSky, LivinInWater, LivinOnLand{




}

public class Frog implements LivinInWater, LivinOnLand{

}

• ISP를 극단적으로 적용하면 위 예처럼 단일 메소드 interface만 사용할 수 있다. 실제로 단일 메소드 interface를 사용하면 ISP가 위배될 수 없다.
• 하지만 항상 같이 사용하는 것까지 분리하는 것은 적절하지 않다.
• 예를 들어 자료구조와 같은 경우에는 다음과 같이 size, isEmpty 등을 함께 정의하는 것은 문제가 되지 않는다.
• public class Collection{ int size(); boolean isEmpty(): }
• interface A에 f라는 메소드가 선언되어 있다고 하자. 이 interface를 구현하는 여러 클래스 중에 대다수가 공통적으로 g라는 메소드가 필요하다고 하자. 그러면 ISP에 의하면 이것을 어떻게 처리하는 것이 가장 효과적인 방법일까? 이 경우 크게 다음과 같이 처리할 수 있다. 이때 X는 새 메소드 g가 필요한 클래스이고, Y는 g가 필요없는 기존 A를 구현하고 있는 클래스라 하자.
  • 방법1. A에 g를 추가함. X는 자신에 맞게 g를 재정의하여 사용함. Y는 g를 빈 메소드로 재정의하여 문제가 없도록 함
  • 방법 2. A를 상속하는 새 interface B를 정의하고 B에 g를 선언함. X는 interface B를 구현하도록 수정하고 자신에 맞게 g를 재정의하여 사용하고, Y는 수정 없이 사용함
  • 방법 3. 새 interface B를 정의하고 B에 g를 선언함. lstinlineX는 interface B를 추가 구현하도록 수정하고 자신에 맞게 g를 재정의하여 사용함. lstinlineY는 수정 없이 사용함
• 자바 8 이후에는 방법 1을 사용할 때 g를 선언만 하는 것이 아니로 기본 빈 메소드로 정의하면 다른 방법과 마찬가 지로 Y는 수정 없이 사용할 수 있다.

1.5 DIP

의존관계 뒤집기 원리 Depend upon abstractions. Do not depend on concrete classes.

• 한 클래스 A를 구현할 때 다른 클래스 B를 사용하면 A는 B에 의존한다고 말한다. 둘 간 관계가 상속과 같이 정적인지 동적인지 상관없이 두 클래스 간 또는 두 클래스 객체 간의 관계가 형성되면 둘 중 하나는 다른 하나를 의존 한다고 말한다. 한 모듈의 결합성은 낮을수록(low-coupling) 효과적이라는 원리 매우 오래된 소프트웨어 원리이다. 즉, 의존관계가 적을수록 효과적이다.
• DIP 원리는 의존을 하더라도 구체적인 클래스 대신에 상위 추상 타입이나 interface 에 의존해야 한다는 원리 이다. 따라서 이 원리에 충실하게 구현하기 위해서는 다음과 같은 리펙토링이 필요하다.
  • 구체적인 클래스를 직접 참조하는 것이 있으면 간접 참조하도록 바꾸어야 한다.
  • 구체적인 클래스의 행위들을 추상 클래스나 interface로 일반화해야 한다.
  • 상속 대신에 포함 관계를 활용하여야 한다.

public class OrderFood{
  private Baemin finder = new Bamin();
  public List<Restaurant> getRestaurantByType(FoodType type){
    return finder.findAll(type);
    }
 }

• 이 예에서는 OrderFood 클래스는 Baemin이라는 구체적인 클래스에 의존하고 있다. 이 경우 클래스 관계도에서 화살표가 OrderFood에서 Baemin 방향으로 향하게 그리게 된다.
• 다음과 같은 interface를 정의

public interface FoodDeliveryFinder{
  List<Restaurant> findAll(FoodType type);
}

• interface를 구현하도록 Baemin을 수정하고, OrderFood 클래스를 다음과 같이 수정하였다고 하자.

public class OrderFood{
  private FoodDeliveryFinder finder = null;
  public OrderFood(FoodDeliverlyFinder finder){
     this.finder = Objects.requireNonNull(finder);
   }

   public void setFoodDeliveryFInder(FoodDeliverlyFInder finder){
     this.finder = objects.requireNonNull(finder);
   }

   public List<Restaurant> getREstaurantByType(FoodType type){
     return finder.findAll(type);
   }
 }

• OrderFood 객체를 생성할 때 다음과 같이 생성한다고 가정
• OderFood orderFood = new OrderFood(new Baemin());
• 이처럼 수정을 하면 OrderFood는 궁극에는 Baemin 타입의 객체를 사용하지만 OrderFood는 Baemin에 더 이상 의존하지 않는다. 클래스 관계도를 그려도 OrderFood와 Baemin 간에 화살표가 연결되지 않는다. 이 측면에서 의존관계 뒤집기라 하는 것이다.
• 의존관계를 뒤집기 위해서는 무엇을 할 것인지를 결정하는 부분과 언제할 것인지를 결정하는 부분을 분리해야 하고, 언제할 것인지를 결정하는 부분과 무엇을 할 것인지를 결정하는 부분은 서로 모르게 해야 한다. 이 예에서 음식점을 찾는 how는 Baemin이 담당하지만 언제 이것을 사용할지는 OrderFood 클래스가 결정하지만 서로 의존하지 않는다. 이와 같이 관계를 클래스를 정의할 때 고정하는 것이 아니라 객체를 생성할 때 관계를 맺을 수 있도록 하는 것을 관계 주입(dependency injection)이라 한다.
• 무엇을 할 것인지를 결정하는 부분과 언제할 것인지를 결정하는 부분을 분리하는 또 다른 예로 GUI에서 이벤트 처리와 interface를 생각해 볼 수 있다. 이벤트 처리의 경우 처리자가 무엇을 할 것인지를 결정하는 부분이고, 사건 발생이 언제할 것인지를 결정하는 부분이다. 즉, interface는 what과 how를 분리해 주며, 이를 통해 how와 when도 분리할 수 있다. interface를 구현하는 구체적인 클래스가 어떻게 할 것인지를 결정하며, 이 interface를 사용하는 측이 언제할 것인지를 결정한다.
• 관계 주입이 의존관계를 뒤집는 유일한 방법은 아니다. 상속 관계에서도 자식 클래스에 행위 구현의 일부를 위임하지만 어떤 자식 클래스가 올지 부모 클래스는 모르는 상태에서 부모 클래스를 정의할 수 있다.

public class Person{
  private String naem;
  prvate Pet pet;
  public void setPet(Pet pet){
    this.pet = pet;
    }
  }

의존관계 주입

• OCP를 제공하기 위해 가장 널리 사용하는 방법 중 하나는 포함 관계를 모델링할 때 구체적인 클래스 타입을 이용 하여 멤버 변수를 정의하지 않고 상속 관계나 구체화 관계에서 상위 타입을 이용하여 멤버 변수를 정의하는 것이다. 예를 들어 그림 1.1와 같이 사람과 그 사람이 기르는 애완동물을 모델링하기 위해 Person 클래스를 정의하면서 Pet 타입을 사용하는 것과 상속계층도에서 단말에 해당하는 구체적인 클래스인 Siamese를 유지하는 것은 큰 차이가 있다.
• 전자는 다양한 애완동물을 유지할 수 있고 심지어 나중에 새로운 애완동물을 정의하더라도 이 애완동물의 조상 클래스가 Pet이면 Person 클래스를 재컴파일되지 않더라도 Person 객체는 이 새 클래스의 객체를 유지할 수 있다. 즉, Pet 아래에 수 많은 클래스들이 있을 수 있지만 Person은 이들에 대한 지식없이 이들을 사용할 수 있다.
• 다음과 같은 코드가 실행되면 해당 객체는 특정한 종류의 애완동물과 관계를 맺게 된다.

p.setPet(new SiberianHusky());

기타 원리

1. 변할 가능성이 높은 부분을 추상화해라

• 변할 수 있는 부분은 향후 확장을 쉽게 할 수 있도록 설계되어야 한다는 것이다. OCP와 매우 밀접한 관련이 있는 원리이다. 이 원리는 객체지향 프로그래밍을 하지 않더라도 늘 적용해야 하는 원리이다.2. 구체적 타입에 의존하는 것이 아니라 추상 타입에 의존해라
• 구체적 타입에 의존하면 유연성이 떨어질 수밖에 없다. 반면에 추상 타입에 의존하면 실제 관계를 맺는 구체적인 타입은 코드 수정없이 바꿀 수 있으며, 미래에 구현할 객체와도 상호작용할 수 있다.3. 느슨한 연결을 선호해라
• 서로 상호작용해야 하는 객체 간에는 느슨한 연결을 선호하라는 것은 구체적 타입 대신에 추상 타입을 사용하 라는 것과 같다. 한 객체가 다른 종류의 객체에 대해 알아야 하는 것이 많으면 많을수록 강한 연결이라 한다.4. 최소 지식 원리
• 이 원리와 밀접한 관련이 있는 원리가 데메테르 규칙(law of demeter)이다. 데메테르 규칙은 다음 4가지 규칙으로 구성되어 있다.
  • 규칙 1. 클래스 O에 정의되어 있는 메소드m은 클래스 O에 있는 다른 메소드는 호출할 수 있다.
  • 규칙 2. 메소드m은 그것의 인자객체의 메소드는 호출할 수 있다.
  • 규칙 3. 메소드m 내에서 어떤 객체 o를 생성하였으면 그 객체의 메소드는 호출할 수 있다.
  • 규칙 4. 클래스 O에 정의되어 있는 메소드 m은 O의 멤버 변수 객체의 메소드는 호출할 수 있다.

class A{
  public void foo(){}
}

class B{
  public void bar(){}
}

class C{
  public void baz(){}
}

class D{
  private A a = new A();
  public void ham(C c){
    B b = new B();
    egg();                 // rule1
    c.baz();               // rule2
    b.bar();               // rule3
    a.foo();               // rule4
   }
   public void egg(){}
}

5. 상속 관계보다 포함 관계를 선호해라

• 상속 관계는 클래스 간 관계이며, 정적 관계이다. 상속은 is-a 관계가 성립할 경우에만 사용해야 하며, is-a 관계가 성립하더라도 LSP에 위배되지 않는지 검토해야 한다. 상속은 정적 관계이기 때문에 한번 관계가 형성되면 코드 수정 없이는 관계는 지속된다. 이 때문에 더 강한 결합에 해당하는 관계이다. 반면에 포함 관계는 객체 간 관계이며 동적 관계이기 때문에 더 유연하다. 이때 중요한 것은 DIP 원리에 따라 구체적인 타입 변수를 이용하여 관계를 형성하면 안 된다. 한 객체는 추상 타입의 변수나 interface 변수를 통해 다른 객체를 참조해야 한다. 이렇게 하면 실행 시간에 참조하는 객체를 바꾸어 기능을 동적으로 바꿀 수 있다. 이 때문에 포함 관계는 느슨한 결합에 해당하는 관계이다.
• 하지만 이 원리에 따라 상속을 절대 악으로 생각하는 것은 잘못된 것이다. 상속으로 모델링해야 할 경우도 있고 상속 대신에 포함 관계로 모델링해야 할 경우가 있다. 특히, 포함 관계만을 사용하면 상속처럼 코드 중복을 효과적 으로 제거하지 못할 수 있다. 따라서 개발하고자 응용에서 필요한 것이 무엇인지 잘 살펴보아야 하며, 어떤 관계를 이용하여 해결하는 것이 더 효과적인지 잘 살펴보아야 한다. 클래스 간에 is-a와 같은 논리적 관계가 형성되는지, 클래스 간에 공통된 행위가 무엇인지. 같은 행위에 대한 여러 가지 다른 구현이 필요한 것인지 등을 개발하고자 하는 응용에 대해 검토해 보아야 한다.6. 할리우드 원칙
• 상위 수준 요소가 하위 수준 요소에 의존하고 이 하위 수준 요소가 다시 상위 수준 요소에 의존하고, 그 상위 수준 요소가 또 다른 요소에 의존하는 등 의존 관계가 복잡하고 꼬여 있는 경우에 의존성 부패 문제가 있다고 말한다. 이처럼 의존 관계가 복잡하게 꼬이지 않게 하기 위해 사용할 수 있는 설계 원칙 중 하나가 할리우드 원칙이다. 이 원칙에 의하면 하위 수준 요소는 상위 수준 요소와 연결되어 동작할 수 있지만 상위 수준 요소가 언제 어떻게 하위 수준 요소를 사용할지 결정하며, 하위 수준 요소는 절대 상위 수준 요소를 직접 호출하지 않아야 한다.
• 할리우드 원칙은 의존성 뒤집기 원칙과 비교하여 보면 의존성 뒤집기 원칙이 더 포괄적인 개념이라고 생각하면 된다. 할리우드 원칙은 상속 관계와 관련된 원리이지만 DIP는 관계 주입 등 상속, 포함 관계 등 다양한 방법을 통해 적용할 수 있는 원리이다.