[오브젝트 : 코드로 이해하는 객체지향 설계] 객체지향 프로그래밍 (객체, 설계)

캡슐화 (Encapsulation)

몰라도 되는 객체 내부의 세부적인 사항을 감추는 것
👉 목적 : 변경하기 쉬운 객체 만들기 

캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있음 ➔ 설계 좀더 쉽게 변경 가능

 

➡️ 객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개해 객체 사이의 결합도 낮추고 변경하기 쉬운 코드 작성 

 

 

 

응집도 (Cohesion)

밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임 👉 응집도가 높음 
자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도↓, 응집도↑

 

 

 

✨ 객체지향 프로그래밍 (Object-Oriented Programming)

데이터를 사용하는 프로세스가 데이터를 소유 👉 데이터와 프로세스가 동일한 모듈(객체) 내부에 위치 

 

• 의존성을 통제하고 하나의 변경으로 인한 여파가 여러 클래스로 전파되는 것을 효율적으로 억제 
  
  
• 하나의 기능을 완성하는 데 필요한 책임이 여러 객체에 걸쳐 분산 = 책임의 이동 

 

👉 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계 = 좋은 객체지향 설계 

 

 

 

📽️ 객체지향  프로그래밍 예시  - 영화 예매 시스템 

요구사항은 책 참고
👉 영화, 상영, 할인조건, 할인정책으로 도메인 구성

• 어떤 클래스가 필요한지 고민하기 전에 어떤 객체들이 필요한지 먼저 고민 !
• 객체를 독립적인 존재가 아닌 협력하는 공동체의 일원으로 생각 
• 객체 내부에 대한 접근을 통제함으로써 객체를 자율적인 존재로 만듦 👉 외부 간섭 최소화 
  일반적으로 객체의 상태는 숨기고 행동만 외부에 공개 

 

✴️ 할인 정책 

public abstract class DiscountPolicy{
	private List<DiscountCondition> conditions = new ArrayList<>();
    
    public DiscountPolicy(DiscountCondition ... conditions){
    	this.conditions = Arrays.asList(conditions);
    }
    
    public Money calculateDiscountAmount(Screening screening){
    	for(DiscountCondition each : conditions){
        	if(each.isSatisfiedBy(screening)){
            	return getDiscountAmount(screening);
            }
        }
        
        return Money.ZERO;
    }
    
    abstract protected Money getDiscountAmount(Screening screening);
}

➔ DiscountPolicy의 인스턴스를 생성할 필요가 없기 때문에 추상클래스로 구현 

 

• 하나의 할인 정책은 여러 개의 할인 조건을 포함 가능 ➔ 리스트를 사용해 여러 개의 DiscountCondition 인스턴스 허용 
• 만족하는 할인 조건이 하나라도 존재하면 추상 메서드인 getDiscountAmount 호출해서 할인 요금 계산
  존재하지 않다면, Screening의 getMovieFee 메서드 호출해서 원래 영화 가격 반환
• 실제로 요금을 계산하는 부분은 추상 메서드인 getDiscountAmount에게 위임 👉 Template Method

✨ Template Method

👉 부모 클래스에 기본적인 알고리즘의 흐름을 구현하고 중간에 필요한 처리를 자식 클래스에게 위임하는 디자인 패턴 

 

• 금액 할인 정책

public class AmountDiscountPolicy extends DiscountPolicy {
	private Money discountAmount;
    
    public AmountDiscountPolicy(Money discountAmount, DiscountCondtion ... conditions){
    	super(conditions);
        this.discountAmount = discountAmount;
    }
    
    @Override
    protected Money getDiscountAmount(Screening screening) {
    	return discountAmount;
    }
}

 

• 비율 할인 정책

public class PercentDiscountPolicy extends DiscountPolicy {
	private double percent;
    
    public PercentDiscountPolicy(double percent, DiscountCondtion ... conditions){
    	super(conditions);
        this.percent = percent;
    }
    
    @Override
    protected Money getDiscountAmount(Screening screening) {
    	return screening.getMovieFee().times(percent);
    }
}

 

• 0원 할인 정책 (할인 정책 X)

public class NoneDiscountPolicy extends DiscountPolicy {
	@Override
    protected Money getDiscountAmount(Screening screening){
    	return Money.ZERO;
    }
}

👉 부모 클래스인 DiscountPolicy에서 할인 조건이 없을 경우 getDiscountAmount() 메서드를 호출하지 않기 때문에 어떤 값을 반환하더라도 상관 없음... 

👉 이 문제를 해결하려면 DiscountPolicy 클래스를 인터페이스로 변경하고, 기존에 있던 DiscountPolicy 클래스의 이름을 DefaultDiscountPolicy로 변경한 후 인터페이스를 구현하도록 수정해야 함. 

 

---

✴️ 할인 조건 

public interface DiscountCondition {
	boolean isSatisfiedBy(Screening screening);
}

 

• 순번 조건 

public class SequenceCondition implements DiscountCondition {
	private int sequence;
    
    public SequenceCondition(int sequence){
    	this.sequence = sequence;
    }
    
    public boolean isSatisfiedBy(Screening screening){
    	return screening.isSequence(sequence);
    }
}

 

• 기간 조건

public class PeriodCondition implements DiscountCondition {
	private DayOfWeek dayOfWeek;
    private LocalTime startTime;
    private LocalTime endTime;
    
    public PeriodCondition(DayOfWeek dayOfWeek, LocalTime startTime, LocalTime endTime){
    	this.dayOfWeek = dayOfWeek;
        this.startTime = startTime;
        this.endTime = endTime;
    }
    
    public boolean isSatisfiedBy(Screening screening){
    	return screening.getStartTime().getDayOfWeek().equals(dayOfWeek) &&
        	startTime.compareTo(screening.getStartTime().toLocalTime()) <= 0 &&
            endTime.compareTo(screening.getStartTime().toLocalTime()) >= 0;
    }
}

 

 

✴️ 영화 

public class Movie {

	private String title;
    private Duration runningTime;
    private Money fee;
    private DiscountPolicy discountPolicy;
    
    public Movie(String title, Duration runningTime, Money fee, DiscountPolicy discountPolicy){
    	this.title = title;
        this.runningTime = runningTime;
        this.fee = fee;
        this.discountPolicy = discountPolicy;
    }
    
    public Money getFee(){
    	return fee;
    }
    
    public Money calculateMovieFee(Screening screening){
    	return fee.minus(discountPolicy.calculateDiscountAmount(screening));
    }
}

 

• 특정 영화에 할인 정책과 할인 조건을 설정한 경우

Movie toystory = new Movie("토이스토리", 
	Duration.ofMinutes(100),
    Money.wons(10000),
    new AmountDiscountPolicy(Money.wons(800),
    	new SequenceCondition(1),
        new SequenceCondition(10),
        new PeriodCondition(DayOfWeek.MONDAY, LocalTime.of(10, 0), LocalTime(11, 59)),
        new PeriodCondition(DayOfWeek.SUNDAY, LocalTime.of(10, 0), LocalTime(20, 59))));

Movie titanic = new Movie("타이타닉", 
	Duration.ofMinutes(180),
    Money.wons(10000),
    new PercentDiscountPolicy(0.1,
        new PeriodCondition(DayOfWeek.MONDAY, LocalTime.of(10, 0), LocalTime(15, 59)),
        new SequenceCondition(2),
        new PeriodCondition(DayOfWeek.SUNDAY, LocalTime.of(10, 0), LocalTime(19, 59))));

✨ Movie 클래스에서 할인 정책을 결정하는 조건문 X 👉 상속 & 다형성

 

 

 

의존성 - 상속과 다형성, 인터페이스

• Movie는 DiscountPolicy와 연결
• AmountDiscountPolicy와 PercentDiscountPolicy는 추상 클래스인 DiscountPolicy를 상속 받음

👉 다른 클래스에 접근할 수 있는 경로를 가지거나 해당 클래스의 객체의 메서드를 호출할 경우 두 클래스 사이에 "의존성이 존재한다"고 함

 

• Movie의 인스턴스는 실행 시에 AmountDiscountPolicy와 PercentDiscountPolicy의 인스턴스에 의존하지만 코드 상으로는 DiscountPolicy에만 의존하고 있음 !
  👉 코드의 의존성과 실행 시점의 의존성이 다름  = 클래스 사이의 의존성과 객체 사이의 의존성이 다름 
  👆 유연, 쉽게 재사용, 확장 가능한 객체지향 설계의 특징 

하지만, 설계가 유연해질수록 코드를 이해하고 디버깅하기는 어려워진다. 
그러므로 항상 유연성과 가독성 사이를 고민해야 함. 

---

✳️ 상속 

코드를 재사용하기 위해 가장 널리 사용되는 방법으로 기존 클래스가 가지고 있는 모든 속성과 행동을 새로운 클래스에 포함시킬 수 있음.
부모 클래스의 구현은 공유하면서도 행동이 다른 자식 클래스를 쉽게 추가 가능 

 

• 자식 클래스가 부모 클래스를 대신하는 것 = 자식 클래스가 부모 클래스의 타입으로 변환되는 것 = 업캐스팅(Upcasting)
• 구현 상속
  • 코드 재사용 목적
• 인터페이스 상속
  • 다형적인 협력을 위해 부모 클래스와 자식 클래스가 인터페이스를 공유할 수 있도록 상속 이용 
    
    

✳️ 다형성 

동일한 메시지를 수신했을 때 객체의 타입에 따라 다르게 응답
컴파일 시간 의존성과 실행 시간 의존성을 다르게 만들 수 있는 객체지향의 특성을 이용해 서로 다른 메서드 실행
👉 실행시점에 실행될 메서드 결정 = Lazy Binding(지연 바인딩) = Dynamic Binding(동적 바인딩)
ex). AmountDiscountPolicy 또는 PercentDiscountPolicy

 

✨ 상속받는 것 = 다형성 구현

 

 

✳️ 인터페이스 

추상 클래스를 이용해 다형성을 구현했던 할인 정책과 달리 할인 조건은 구현을 공유할 필요가 없으므로 인터페이스를 이용해 타입 계층 구현 

 

 

 

상속의 단점과 합성 

• 캡슐화 위반
  • 부모 클래스의 구현이 자식 클래스에게 노출되므로 캡슐화 약화
  • 자식 클래스가 부모 클래스에 강하게 결합되도록 만들기 때문에 부모 클래스를 변경할 때 자식 클래스도 함께 변경될 수 있음
• 설계가 유연하지 X
  • 부모 클래스와 자식 클래스 사이의 관계를 컴파일 시점에 결정하기 때문에 실행 시점에 객체의 종류 변경 불가

 

✳️ 합성 

인터페이스에 정의된 메시지를 통해서만 코드 재사용
ex). Movie와 DiscountPolicy는 합성 관계로 연결  ➔ 요금 계산하기 위해 DiscountPolicy 코드 재사용

👉 코드 재사용을 위해서는 상속보다는 합성 선호 !
하지만, 다형성을 위해 인터페이스를 재사용하는 경우에는 상속과 합성을 함께 조합해서 사용 !