😃 책에서 기억하고 싶은 내용을 써보세요.
- 보통 변수를 비공개로 정의하고, get() 과 set()을 공개 함수로 설정해 비공개 변수를 외부에 노출한다. 구현을 외부로 노출하는 셈. 변수 사이에 함수라는 계층을 넣는다고 구현이 감추어지는 게 아니라 추상화가 필요하다.
- 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스
- 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
- 자료구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다
- 절차적 방식 예시: 각 도형 클래스는 간단한 자료구조이고, 도형이 동작하는 방식은 Geometry class에서 구현한다. (class Square, class Rectangle, class Circle, class Geometry)
- 객체 지향적 방식 예시: (class Square{ area() }, class Rectangle{ area() }, class Circle{ area() }) 여기서 area() 함수는 다형 Polymorphic 메서드다. Geometry 클래스는 필요없다.
- 객체와 자료구조는 양분되는 특징이 있다. 자료구조를 사용하는 절차적 방식은 새 함수 추가하기 쉽다. 그러나 새 자료구조를 추가하기 어렵다. 모든 함수 수정해야. 객체를 사용하는 객체지향 방식은 새 클래스를 추가하기 쉽다. 그러나 새 함수를 추가할 때 모든 클래스 고쳐야.
- Law of Demeter 디미터 법칙: 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다. 예시: ctxt.getOptions().getScratchDir().getAbsolutePath() -> train wreck 발생. 코드를 나눈다고 해도 각 오브젝트가 객체인 경우 내부 구조 숨기지 않으므로 디미터 법칙 위반. 자료구조인 경우 당연히 내부 구조 노출하므로 적용 안됨.
- 각 오브젝트가 객체인 경우에는 사용 목적에 따라 객체에 적절한 함수 생성해주는 것이 좋다. 내부 구조를 드러내지 않으며, 해당 함수가 자신이 몰라야 하는 여러 객체를 탐색할 필요 없도록.
- 잡종 구조: "자료구조는 무조건 함수 없이 공개변수만 가지고, 객체는 비공개 변수 + 공개 함수"만 적용된다면 간단하지만 절반은 객체이고 절반은 자료구조인 잡종 구조 존재. 중요한 기능 수행하는 함수 포함하거나, 공개 변수, 조회/설정 함수 등등. 되도록 피하는 편이 좋다. 함수나 타입을 공개할지 보호할지 확신하지 못해 어중간한 설계.
- Data Transfer Object, DTO 공개 변수만 있고 함수가 없는 클래스. 데이터베이스 정보를 코드화 할 때 사용. Bean구조 - private 변수를 조회/설정 함수로 조작하는 구조. 사이비(?) 캡슐화
- 활성 레코드: 특수 형태 DTO, save() find()등 탐색 함수 제공. 활성 레코드에 비즈니스 규칙 메서드를 추가해 객체로 취급하는 개발자가 흔하지만 이는 잡종 구조를 만들게 되어 지양한다. 활성 레코드는 자료구조로 취급하고 비즈니스 규칙을 담으면서 내부자료(활성 레코드의 인스턴스)를 숨기는 객체를 따로 생성하는 것이 좋다.
🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- bean 구조가 깨끗한 코드가 아니라는 것은 생각도 못했던 것이다.
- 사실 늘상 object oriented 만 사용해와서 절차적 방법이 있다는 것이 생소했다.
- 레거시 코드를 다루다 보면서 잡종 구조를 종종 본 듯 하다. 어쩌면 나도 잡종 구조를 사용하고 있었는지 모르겠다.
- DTO는 약간 넓은 개념의 orm같은 느낌이 든다.
🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- 활성 레코드라는 것은 좀 더 찾아봐야겠다.