4장 설계 품질과 트레이드오프

[lee-ji-hoon]

No description provided.

[lee-ji-hoon]

캡슐화를 잘 해야지 객체지향을 잘 하는 것이다.

위 제목과 같은 내용을 자주 봤는데 책에서 캡술화에 대한 내용이 나오는데 의문점이 든다.

102p

public class DiscountCondition {
  private DiscountConditionType type;
  private int sequence;
  private DayOfWeek dayOfWeek;
  private LocalTime startTime;
  private LocalTime endTime;

  public DiscountConditionType getType() {
    return type;
  }
}

// 캡슐화의 원칙에 따라서 클래스 외부에 노출하면 안된다.
// get 메서드를 추가한다.
public class DiscountCondition {
  public DiscountConditionType getType() {
      return type;
  }
}

• 이렇게 결국에는 해당 객체를 접근할 수 있게 getter를 열어주는데 캡슐화인가?
• 캡슐화가 맞다고는 하지만 결국에는 접근을 할 수 있게끔 열어주는 모습이라 살짝 꺼림찍하다.

kotlin에서 이렇게 주로 만드는데 얘네는 캡슐화가 안된 것들이라고 봐야하나?

class DiscountCondition(
    val discountConditionType: DiscountConditionType,
    val sequence: Int,
    val dayOfWeek: DayOfWeek,
    val startTime: LocalTime,
    val endTime: LocalTime,
)

• decompile을 해보면 public getter가 생성이되고 setter는 생성이 안된다.
• val이기 때문에 당연한 이야기이긴하다.

private으로 선언한 객체는 아니더라도 디컴파일 해보면 위의 java와 같은 구현이라고 생각이된다.
그렇기에 val로 구현하면 캡슐화가 된걸까? 라는 생각이 드는데 다들 어떻게 생각하나요?

[lee-ji-hoon]

위 내용에서 이어서 읽고 있는데 117p에 이런 내용이 있네

속성의 가시성을 private으로 설정했다고 해도 접근자와 수정자를 통해 속성을 외부로 제공하고 있다면 캡슐 화를 위반하는 것이다.

이 책은 뭔가 읽다가 이게 맞나? 라는 생각이 들어서 적어두면 항상 뒤에서 너 생각이 맞아 라는거 같네.

[lee-ji-hoon]

4장 마지막 단원에서 아래 문장이 제일 와닿는거 같네

올바른 객체지향 설계의 무게 중심은 항상 객체의 내부가 아니라 외부에 맞춰져 있어야 한다.
객체가 내부에 어떤 상태를 가지고 그 상태를 어떻게 관리하는가는 부가적인 문제다. 중요한 것은 객체가 다른 객체와 협력하는 방법이다.

나는 항상 어떤 class를 만들 때

1. 이 객체는 무슨 상태를 갖고 있어야 할까?
2. 어떻게 관리를 하지?
3. 어디서 어떻게 사용을 해야 할까?

이런 생각의 흐름으로 만들었는데 정반대로 생각을 해야지 캡슐화가 지켜진다는게 맞는 말인거 같다는 생각이 들어서 이 규칙을 잘 지켜봐야겠다는 생각이 들어

[ldh019]

코틀린이라서 조금 더 애매하게 느껴지는 부분들이 존재한다고는 생각해
그럼 과연 "멤버들에 대한 캡슐화를 어떻게 받아들여야 할까"를 고민해봤는데

이상적인 객체지향 패러다임을 생각해보자면, 멤버 변수들이 밖으로 노출되는 일이 전혀 없이 오롯이 본인이 책임져야 할 데이터는 본인만 컨트롤 해야한다.
라고 느껴져.

계속 말했듯이 객체는 데이터를 보관하기만 하는 존재가 아니라 특정한 책임을 갖고 역할을 하기 때문이지.

어떤 예외상황이 일어날지는 모르겠지만 협력을 할때 있어서, 멤버 전달만을 위한 기능은 없어야 하지않을까?
라는 생각을 해봤습니다. 물론 이상적일때 만 이겠지만

[ldh019]

그래서 public으로 했을 때 캡슐화가 됐다고 생각하는가? 에 대한 나의 생각은
지훈이형이 찾은 이야기처럼 나도 아니라고 생각!

[audxo112]

결합도에 대해서 간과 했던 부분을 확인함

String, ArrayList 또한 클래스인데 여기에 대해서는 결합도를 생각해 본 적이 없었네

캡슐화란 무엇인가에 대해서 확실하게 와닿은 단원

단순히 데이터의 가시성을 가린것이 캡슐화가 아니며 그 예로든

• calculateAmountDiscountedFee
• calculatePercentDiscountedFee
• calculateNoneDiscountedFee

이 부분을 보며 조금 더 캡슐화에 대해 좀 더 이해됨

하지만 드는 의문

DiscountCondition 에서 type 에 따라 Discount 여부를 판단하기 위한 데이터가 다르게 필요한데 어떤 식으로 추상화할 수 있을까 ?