'말하고 묻지 마세요' 원칙을 몇 초 만에 설명

객체 지향 프로그래밍(OOP)의 초석인 말하고 묻지 않는 원칙은 데이터와 해당 데이터를 조작하는 방법을 모두 캡슐화하는 객체 설계를 옹호합니다. 이 접근 방식은 캡슐화를 강화하여 더욱 유지 관리하기 쉽고 견고한 시스템을 조성합니다.

---

? "묻지 말고 말하고" 이해하기

'묻지 말고 말하고' 원칙은 데이터를 외부에서 검색하고 처리하는 대신 개체에게 수행할 작업을 지시하는 것을 강조합니다. 객체 자체 내에서 논리와 상태를 유지하도록 촉진합니다.

외부 결정을 내리기 위해 개체의 데이터에 액세스하는 대신 개체에 내부 작업을 수행하도록 직접 지시합니다. 이 전략은 코드를 단순화하고 종속성을 최소화하며 시스템 확장성과 유지 관리성을 향상시킵니다.

---

?‍?‍? 예: 센서 값 모니터링

센서 값과 이 값이 임계값을 초과할 때 트리거되는 알람과 관련된 시나리오를 살펴보겠습니다.

"질문" 접근 방식

<code>class AskMonitor {
  private int value;
  private int limit;
  private String name;
  private Alarm alarm;

  public AskMonitor(String name, int limit, Alarm alarm) {
    this.name = name;
    this.limit = limit;
    this.alarm = alarm;
  }

  public int getValue() { return value; }
  public void setValue(int value) { this.value = value; }
  public int getLimit() { return limit; }
  public String getName() { return name; }
  public Alarm getAlarm() { return alarm; }
}</code>

사용법:

<code>AskMonitor monitor = new AskMonitor("Temperature Sensor", 100, alarm);
monitor.setValue(120);

if (monitor.getValue() > monitor.getLimit()) {
  monitor.getAlarm().warn(monitor.getName() + " is too high");
}</code>

"말하기" 접근 방식

"Tell, Don't Ask"를 사용하면 해당 동작이 Monitor 클래스에 통합됩니다.

<code>class TellMonitor {
  private int value;
  private int limit;
  private String name;
  private Alarm alarm;

  public TellMonitor(String name, int limit, Alarm alarm) {
    this.name = name;
    this.limit = limit;
    this.alarm = alarm;
  }

  public void setValue(int value) {
    this.value = value;
    if (this.value > this.limit) {
      alarm.warn(name + " is too high");
    }
  }
}</code>

사용법:

<code>TellMonitor monitor = new TellMonitor("Temperature Sensor", 100, alarm);
monitor.setValue(120);</code>

"Tell" 버전은 setValue 메서드 내에 논리를 캡슐화하여 외부 의사결정을 제거합니다.

---

⭐ '묻지 말고 말하고'의 장점

✅ 강화된 캡슐화: 데이터와 동작이 긴밀하게 결합됩니다.
✅ Concise Code: 동작을 내부화하여 외부 로직을 최소화합니다.
✅ 유지관리성 향상: 기능 수정 및 확장이 더 쉬워졌습니다.

---

? "말"해야 할 때

✅ 캡슐화된 동작: 객체가 본질적으로 데이터 처리 방법을 알고 있는 경우.

예: 한계를 인식하는 Monitor 객체는 해당 한계를 초과하면 자동으로 경보를 발동해야 합니다.

✅ 상태 트리거 작업: 상태가 변경되면 후속 작업(예: 알림, 로깅)이 필요합니다.

예: UserProfile 개체는 프로필 수정 시 활동 로그를 자동으로 업데이트합니다.

---

? "질문"해야 할 때

✅ 데이터 검색: 객체의 상태를 변경하지 않고 데이터가 필요한 경우

예: User 개체의 이메일 주소를 검색합니다.

✅ 외부 의사결정: 결정이 외부 요인에 의존하는 경우.

예: 외부에서 적절한 인사말을 결정하기 위해 Person의 이름을 얻습니다.

✅ 책임 위임: 개체가 협력하고 의사 결정을 위해 다른 개체의 데이터가 필요한 경우.

예: Router가 트래픽 관리를 위해 Server의 로드를 쿼리합니다.

---

? 관련자료

관심이 있으신가요? ? 프로그래밍 원리 시리즈의 다른 게시물을 살펴보세요!

• 100초만에 설명하는 KISS 디자인 원리
• 100초만에 설명하는 DRY 원리

---

향후 게시물에 대한 최신 소식을 받아보세요:

• 링크드인
• 깃허브
• 트위터/X

위 내용은 '말하고 묻지 마세요' 원칙을 몇 초 만에 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!