클래스 연관을 풀어서 클래스를 더 이식성 있고 재사용할 수 있게 만드는 방법
같은 인스턴스를 하나의 객체로 대체하고 싶을 때 해당 객체를 참조 객체로 변경
규모가 작고 관리하기 불편한 참조객체를 값 객체로 변경
값을 구현하는 게 더 쉬움
객체의 중요한 속성이 바뀌지 않는다면 쿼리를 반복할 때마다 객체 값은 동일한 결과를 반환될 것이다. 그렇다면 많은 객체가 같은 것을 나타내도 문제가 없다.
🥔💬
감자의 부족한 영어실력으로 번역하다보니 말이 좀 이상한데...
크롬 자동 번역은 여엉...😞
대충 갱신을 하지 않는 것을 참조하는 거였다면 중복될지언정 구현하기 더 쉽게 값으로 넣어라 인 것 같다!
GUI 컨트롤에서만 사용가능한 도메인 데이터가 있고 도메인 메소드를 이용해야 한다면 데이터를 도메인 객체로 복사하고 두개의 데이터를 동기화하기 위해 관찰자(observer)를 설정
비즈니스 로직 클래스와 프리젠테이션 클래스 간에 책임을 나누어서 프로그램을 더 읽고 이해하기 편하게 만듬 (참고. 단일 책임 원칙)
개방 폐쇄 원칙(Open/Closed Principle)을 지키므로 새로운 프레젠테이션 클래스를 추가할 때 비즈니스 로직을 건드릴 필요가 없음
필드에 직접 접근하지만 필드 처리가 불편하다면 해당 필드에 대한 get, set 메소드를 생성하여 접근
- 필드의 데이터를 설정하거나 수신할 때 복잡한 작업 수행 가능
필드 값의 지연 초기화 및 유효성 검사를 필드 getter 및 setter 내에서 구현- 하위 클래스에서 getter와 setter 재정의 가능
추가 데이터나 동작이 필요한 데이터 항목을 객체 안으로 이동
일부 요소가 다른 것을 의미하는 배열이 있다면 각 요소에 대한 필드를 가지는 객체로 변경
클래스의 필드는 배열의 요소보다 문서화하기가 쉬움
배열에서 변경된 객체는 메인 클래스나 다른 클래스에 저장된 모든 관련 동작을 배치할 수 있음 ...?
서로의 기능을 사용하는 두개의 클래스를 가지고 있지만 연관은 단방향일 때 백 포인터를 추가하고 수정했을 때 양쪽을 모두 업데이트하도록 변경
양반향 연결은 단반향 연결보다 구현 및 유지 관리가 어려움
양반향 연결은 클래스를 상호 의존적으로 만듬
클래스들이 양방향으로 참조하고 있지만 하나의 클래스가 더이상 다른 클래스를 필요로 하지 않는다면 결합 제거
관계가 필요하지 않은 클래스를 단순화
더 적은 코드는 더 적은 유지 관리와 같음
클래스 간의 종속성 축소
클래스에 대한 변경 사항은 해당 클래스에만 영향을 미치므로 독립 클래스를 유지 관리하기 쉬움
📑 참고 자료
🥔💬
데이터 구성은 너무 많아서 힘들다
나눠서 해야지... 😂