Skip to content

[additional] 부록 A, B, C 를 읽으며.. #63

@leejaeseung

Description

@leejaeseung

연관 챕터

부록

조사 내용

부록을 읽으며 궁금증이 들었거나 와닿은 부분을 정리해 봅니다.
일단 올려놓고, 추후에 조사할 예정입니다.

[부록 A - 계약에 의한 설계]

  1. 자바에서는 계약에 의한 설계를 왜 안 지원할까? (assert 로 하면 되지 않나??)
  2. 리턴 타입 공변성 : 부모 클래스의 메서드를 자식 클래스에서 오버라이딩할 때, 메서드의 리턴 타입의 서브 타입으로 할 수 있다. (언어에 따라 다름. 자바는 지원, C# 은 무공변성) → C# 은 왜 리턴 타입 공변성을 지원하지 않는 거지? 이론적으로 괜찮지 않나?

[부록 B - 타입 계층의 구현]

  1. 타입이 먼저다! - 타입을 중심으로 객체들의 계층을 구현하라.
  2. 인터페이스의 메서드는 private 을 쓸 수 없다. → 추상화된 메서드를 구현할 때 캡슐화를 보장받을 순 없을까? private 메서드를 추상 메서드에 한해서만 오버라이딩할 순 없는걸까..?

[부록 C - 동적인 협력, 정적인 코드]

  1. 몬스터 설계하기
    요구사항 분석 및 설계의 중요성 문제인 듯 하다.
    첫 요구사항은 다음과 같았을 것이다.
  • 몬스터에 드래곤과 트롤이 존재합니다. (더 추가되는 부분은 고려하지 말아 주세요!)
  • 만약 추가되는 부분을 고려해 주세요! 라고 했다면 Breed 의 형태로 처음부터 설계하는게 맞겠지?
  • 실제 업무 중에도 “OOO 은 아직 고려하지 않아도 됩니다” 와 같은 말이 많이 오가는데, 이런 부분에 대해 명확하게 정책을 정하고 설계하는게 중요한 듯 하다
  • 설계의 범위에 대해 생각하고, 오버 프로그래밍과 유연성에 사이에서 잘 정할 수 있는게 능력이지 않을까..

Metadata

Metadata

Assignees

No one assigned

    Labels

    additional책 내용에는 없지만, 추가적으로 조사한 내용

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions