객체와 자료구조
변수를 private으로 정의하는 이유
- 남들이 변수에 의존하지 않게 만들고 싶어서 private 변수를 선언해놓고, 왜 getter와 setter를 당연하게 public 으로 만들어 비공개 변수를 외부에 노출하는가?
- 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다.
- 구현을 감추려면 추상화가 필요하다.
- getter와 setter로 변수를 다룬다고 클래스가 되지는 않는다.
- 그보다는 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.
구체적인 클래스 예시
1
2
3
4
public interface Vehicle {
double getFuelTankCapacityInGallons();
double getGallonsOfGasoline();
}
추상적인 클래스 예시
1
2
3
public interface Veicle {
double getPercentFuelRemaining();
}
- 위의 구체적인 클래스보다는 아래의 추상적인 클래스가 더 좋다.
- 자료를 세세하게 공개하기보다는 추상화된 개념으로 표현하는 편이 더 좋다.
객체 자료구조의 상반된 역할
- 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
- 자료구조는 자료를 그대로 공개하며 별다른 함수를 제공하지 않는다.
- 객체지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적인 코드에서 어려운 변경은 객체지향 코드에서 쉽다.
- 새로운 타입이 필요한 경우 -> 객체지향 기법이 가장 적합
- 새로운 함수가 필요한 경우 -> 절차적인 코드와 자료구조가 더 적합
디미터 법칙
- 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙
- 잘 알려진 휴리스틱
- 객체는 자료를 숨기고 함수를 공개한다. 즉, 객체는 조회 함수로 내부 구조를 공개하면 안 된다는 의미다. 내부 구조를 노출하게 되니까 안 된다.
- “클래스 C의 메소드 f는 다음과 같은 객체의 메소드만 호출해야 한다”
- 클래스 C
- f가 생성한 객체
- f인수로 넘어온 객체
- C인스턴스 변수에 저장된 객체
- 위 객체에서 허용된 메소드가 반환하는 객체의 메소드는 호출하면 안 된다. -> 낯선 사람은 경계하고 친구랑만 놀라는 의미다.
디미터 법칙을 어기는 코드 예시
1
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
위의 코드는 나누는 편이 좋다.
1
2
3
Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();
- 위 코드가 디미터 법칙을 위반하는지 여부는 ctxt, Options, ScratchDir이 객체인지 아니면 자료구조인지에 달렸다.
- 객체 -> 내부구조를 숨겨야 하므로 디미터 법칙 위반
- 자료구조 -> 내부구조를 노출하므로 디미터 법칙이 적용되지 않는다.
조금 더 개선하자면 조회 함수를 사용하지 않아야 한다.
1
final String outputDir = ctxt.options.scratchDir.absolutePath;
- 자료구조는 무조건 함수 없이 공개변수만 포함하고, 객체는 비공개 변수와 공개 함수를 포함한다면 문제는 훨씬 간단하다.
- 하지만 단순 자료구조에도 조회함수와 설정 함수를 정의하라고 요구하는 프레임워크와 표준
이를테면 bean이 존재한다.
섞인 구조 - 절반은 객체, 절반은 자료구조
- 중요한 기능을 수행하는 함수도 있고, 공개 변수나 공개 getter, setter함수도 있다(비공개 변수를 그대로 노출한다).
- 함수나 타입을 공개할지 호가신하지 못해 어중간하게 해놓은 설계다.
- 이런 구조는 객체와 자료구조의 단점만 모아놓은 구조다. 따라서 되도록 피하는 것이 좋다.
