6장 - 데이터 보호

6.1 getter 없이 캡슐화하기

📌 Boolean이 아닌 필드에 setter, getter 사용하지 말기

Coupling (결합)

• 서로 상호작용하는 시스템들간의 의존성

Tight Coupling(긴밀한 결합)

• 강하게 결합된 객체는 다른 객체에 대한 많은 정보를 필요로 하고 보통 두 객체간의 인터페이스들에게 서로 높은 의존성을 가지고 있음. 하나의 객체를 변경하는 것은 많은 다른 객체들의 변경을 요구함.

Loose Coupling(느슨한 결합)

• 하나의 컴포넌트의 변경이 다른 컴포넌트들의 변경을 요구하는 위험을 줄이는 것을 목적으로 함. 컴포넌트간의 내부 의존성을 줄이는 것.

👍🏻 푸시 기반 아키텍처

• 가능한 한 데이터에 가깝게 연산을 이관
• 데이터 가져오는 대신 인자로 데이터 전달

👎🏻 풀 기반 아키텍처

• 데이터를 가져와 중앙에서 연산 수행
• 기능 수행하는 메서드 없이 ‘수동적인’ 데이터 클래스와 여기저기서 데이터를 혼합해 모든 작업 수행하는 소수의 ‘관리자’클래스로 이어짐.
• 데이터와 관리자 사이함 데이터 클래스 간에도 긴밀한 결합 가져옴.

Law of Demeter (디미터 법칙 or 데메테르 법칙)

• 최소한의 지식 원칙 (The Principle of Least Knowledge)
• 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다…

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

📌 코드에 공통 접두사나 접미사가 있는 메서드나 변수가 없어야 함.

• 접두사, 접미사를 붙이면 코드를 더 읽기 쉽게 만들 수 있지만 여러 요소가 동일한 접사를 가질 때는 그 요소들의 긴밀성을 나타내기도 함.
• 클래스를 사용해서 메서드와 변수를 그룹화하면 외부 인터페이스를 완전하게 제어할 수 있음.
• 또한 도우미 메서드를 숨겨 전역 범위를 오염시키지 않을 수 있음.

단일 책임 원칙

• 단일 책임 = 특정 주제의 기능 집합
• 단일 책임으로 설계하려면 원칙 & 개요 필요
• 단일 책임 원칙 준수 유무에 따른 가장 큰 특징 기준 척도: 기능 변경이 일어났을 때의 파급 효과

데이터 캡슐화

• 변수와 메서드를 캡슐화하여 접근할 수 있는 지점을 제한하고 구조를 명확하게 만들 수 있음.
• 메서드를 캡슐화하면 이름을 단순하게 만들고 응집력을 더 명확하게 하는 데 도움됨.
• 범위 제한하면 클래스 내의 메서드만 데이터를 수정할 수 있으므로 이 메서드들만 그 속성에 영향을 줄 수 있게 됨. -> 불변속성 검증해야 할 경우 클래스 내부의 코드만 확인하면 됨.