[5, 6주차] 6, 7장

[hongbiii]

12월 3일 일요일 아침 10시

12월 10일 일요일 아침 10시에 6, 7장 진행

[hongbiii]

• p.171 예제 6.10의 setColor는 앞서 설명한 의미의 setter가 아니라는데 g를 인자로 받아서 set 하기 때문일까??..
  • 멤버변수를 set 하는 것이 아니라 인자로 받은 객체의 속성을 set 하고 있어서 사이드이펙트를 유발
• p.173 getter 제거하기 예제
  • 오브젝트 책에서 봤던 '정보 전문가 패턴'이랑 같은 말인 듯
  • 그 정보를 알고 있는 객체에게 물어봐라 라는 내용인데, (물어본다 === 메서드 라고 이해해도 될 듯)
  • 예제 6.13에서 보면 BlogPost의 this.author의 타입이 User고, User 클래스가 username이라는 정보를 가진 정보전문가이기 때문에
  • 6.17에서 getAuthorName 이라는 메서드를 만들어 this.author.getUsername 을 사용하여 User 클래스에게 물어보는 것!
• p.177 삼항연산자 제거.. 무슨 뜻인지는 알겠는데 클래스를 사용하지 않고 코드를 짜는 경우에도 적용이 되는 내용인 건가?

[ha3158987]

6장 노트

6.1

• getter나 setter를 비권장 하는 이유 (p.167):
  • getter는 캡슐화를 해제시켜 전역적으로 불변속성 발생. 반환받은 곳에서 객체를 더 많은 곳에 전달할 수 있어 제어권을 잃음.
  • setter는 새로운 데이터 구조를 반환하도록 getter를 수정하기 때문에 '밀 결합(tight coupling)'의 형태가 된다.
• 풀 기반(pull-based) 아키텍처보다 푸시 기반(push-based) 아키텍처를 사용해야하는 이유 (p.167 ~ 169):
  • 푸시 기반 아키텍처는 데이터를 가져오는 대신 인자로 데이터를 전달해 가능한 데이터에 가깝게 연산을 이관한다. (p.168 다이어그램)
  • 반면, 풀 기반 아키텍처에서는 데이터를 가져와 중앙에서 연산을 수행. 수동적인 데이터 클래스와 소수의 관리자 클래스로 이어져 데이터 클래스 간 밀 결합을 가져온다.
  • 밀 결합이 되어 있다면 사용자는 getter/setter를 가진 객체의 내부 구조에 대해 알고 있어야 하고, 이전 데이터 구조를 획득하는 방법을 계속 지원해야만 데이터 구조를 변경할 수 있다.
  • 푸시 기반 아키텍처는 '메서드'를 노출하기 때문에 내부 구조에 대해 신경 쓸 필요가 없다.
• getter/setter 없애기의 핵심은 '클래스로의 코드 이관'

6.2

• 공통 접두사나 접미사가 있는 메서드/변수는 요소들간의 긴밀성을 나타낸다. -> '클래스'로 대체 권장 (p.179)
  • 공통 접사가 암시하는 것은 메서드와 변수가 공통의 책임을 공유한다는 뜻. 공통 책임을 전담하는 하나의 클래스로 분리.
• 데이터를 숨김으로써 불변속성이 클래스 내에서만 관리되게. 지역 불변속성은 유지보수가 더 쉽다. (p.180)
• public 한 접근을 매개변수로 대체하면 클래스를 사용하기 전에 강제로 인스턴스화해야 하므로 클래스를 전역 범위에서 다룰 때 발생할 수 있는 null 참조 오류를 방지할 수 있다. (p.191)
• 핵심은 '데이터 캡슐화' (p.187)

6.4

• 호출순서를 유지하고 싶을 때: 메서드를 생성자(constructor)로 변경 (p.200 ~ 201):
  • 생성자 내에 선언된 메서드를 다른 메서드보다 먼저 호출하도록 강제해 불변속성을 제거
  • 순서 불변속성(sequence invariant) a.k.a 순서 강제화를 할 수 있음

6.5

• 열거형은 메서드를 가질 수 없기 때문에 열거형은 제거하는 것을 권장.
• 제거 방법 (p.205):
  • 생성자를 private으로 만들어 클래스 내부에서만 객체 생성하기 - 존재하는 인스턴스 수 제어 가능
  • 인스턴스를 공개(private)상수에 넣으면 열거형으로 사용 가능

7장 노트

7.1

• 장점: 도달성 검증하기 (p.214)
  • 메서드가 모든 경우에 return 이 되는 지 확인하는 것. return 없이 메서드를 벗어나지 않도록 하기.
  • 완전 검사(exhaustiveness check) 함수 활용 (p.215)
• 약점: 산술 오류(arithmetic errors)를 잡지 못함 (p.219)
  • 산술 연산에서 컴파일러는 큰 도움이 되지 않음.
  • 0으로 나누기를 확인하지 않음. 정수를 0으로 나누면 프로그램이 손상됨.
• 약점: 아웃-오브-바운드 오류(out-of-bound)를 잡지 못함 (p.219)
  • 직접 데이터 구조에 접근할 때 (ex. 배열의 인덱스에 직접 접근해서 -1을 반환 받는다던지)

7.2

• 6장에서 제시한 방법이 다수 중복 (p.238 요약)
  • 도달성 분석
  • 확정할당 사용
  • 접근 제어 (private, public)
  • null 확인
  • 나누는 숫자가 0이 아닌지 확인
  • 오버플로우 언더플로우 확인
  • 아웃 오브 바운드 에러 확인
  • 무한 루프 방지
  • 단일 스레드 사용 / 스레드 문제 방지
• 처리를 강제한 예외를 사용하기 (try, catch문) = impossible 예외가 발생할 위험은 항상 존재하기 때문. (p.232)

7.3

• 컴파일러 경고를 무시하지 말아야 할 이유 (p.237):
  • 경보 피로(alarm fatigue): 경고나 런타임 오류가 일상이 되면서 조금씩 주의를 덜 기울이게 되는 것. 😨
  • 깨진 유리창 이론 (the broken window theory): 어떤 것이 나쁜 상태가 되는 즉시 그 주위에 나쁜 상태가 추가되는 것을 개의치 않게 되는 현상.

[damilog]

6. 데이터 보호

6.1.1. 규칙: getter와 setter를 사용하지 말 것

• 객체의 필드에 대한 getter가 존재하는 순간 캡슐화를 해제하고 불변속성을 전역적으로 만들게 됨

  • 객체를 반환 받은곳에서 이 객체를 더 많은 곳에 전달할 수 있으며, 전달은 우리가 제어할 수 x
  • 객체를 얻는 곳에서 public 메서드를 호출하고, 객체를 수정할 수 있음

• setter는 내부 데이터 구조를 변경한다.

  • setter 사이에 간접 레이어 (입,출력 유지용)를 도입 가능

    • 이때는 setter를 통한 새로운 데이터 구조를 반환하도록 getter를 수정해야됨

      → 밀 결합(tight coupling) 형태가 됨

• 푸시 기반 아키텍처: 가능한 한 데이터에 가깝게 연산을 이관

  • 데이터를 가져오는 대신 인자로 데이터를 전달
  • 예제6.2) constructor에서 generateLink 호출

• 풀 기반 아키텍처: 데이터를 가져와 중앙에서 연산을 수행

  • 풀 기반의 아키텍처는 아래 클래스가 이어짐
    • 기능을 수행하는 메서드 없이 수많은 수동적인 데이터 클래스
    • 여기저기서 데이터를 혼합해서 모든 작업을 수행하는 소수의 관리자 클래스
  • 예제 6.1) getter 사용

디미터 법칙

• 낯선 사람(참조를 얻을 수 있는 객체)에게 말하지 말라
• 주로 getter를 통해 발생되는 문제

6.2. 간단한 데이터 캡슐화하기

6.2.1. 규칙: 공통 접사를 사용하지 말 것

(p.179)

• 동일한 접사를 가진 때는 그 요소들의 긴밀성을 나타냄 → 클래스를 사용해서 이런 메서드와 변수를 그룹화하는 장점은 외부 인터페이스를 완전하게 제어할 수 있다는 것
• 데이터를 숨김으로써 해당 불변속성이 클래스 내에서 관리되게 하면 지역 불변속성이 되어 유지보수하기가 더 쉬워짐

단일 책임 원칙

• 메서드는 한 가지 작업만 해야한다
  → 클래스의 경우, 클래스에는 단 하나의 책임만 있어야한다는 의미

• 공통 접사가 암시하는 구조는, 해당 메서드와 변수가 공통 접사의 책임을 공유한다는 것을 의미함
  → 이런 메서드는 이 공통 책임을 전담하는 별도의 클래스에 있어야 한다.

• 이 규칙은 애플리케이션이 발전하고 시간이 지남에 따라 책임이 발생할 때 어떤 클래스가 책임을 가지는지 파악하는데 도움이 됨

6.2.3 리팩터링 패턴: 데이터 캡슐화

(p.187)

• 변수, 메서드 캡슐화 → 접근할 수 있는 지점을 제한하고 구조를 명확하게 만든 수 있음
• 메서드를 캡슐화 하면 이름을 단순하게 만들고 응집력을 명확하게 하는데 도움이 됨
• 사람들은 클래스를 만드는데 너무 소극적이다
• 변수를 캡슐화 하는데서 큰 이점을 얻을 수 있음

6.4. 순서에 존재하는 불변속성 제거하기

• 순서 불변속성: 무언가가 다른 것보다 먼저 호출되어야 하는 것

6.4.1. 리팩터링 패턴: 순서 강제화

• 컴파일러에게 프로그램이 어떻게 실행되기를 바라는지 가르쳐 줄 수 있어야 멋진 리팩터링

7.2.2 컴파일러와 싸우지 말 것

기본값

(p.230)

• 기본값을 사용하는 대신 개발자가 무엇을 추가하거나 변경할 때 마다 직접 처리하게 하십시오