변수를 비공개로 정의하는 이유는, 남들이 변수에 의존하지 않게 만들고 싶어서이다. 하지만, 대부분의 프로그래머는
get
과set
을 당연하게도public
으로 정의한다.
// 구현을 외부로 노출, 좌표값의 설정과 조회를 개별적으로 하도록 강제함
public class Point {
public double x;
public double y;
}
// 구현을 숨기고 있음, 자료구조를 명백히 표현
public interface Point {
double getX(); // 조회할 때는 하나씩
double getY();
void setCartesian(double x, double y); // 값을 설정할 때는 두 값을 한 번에
double getR();
double getTheta();
void setPolar(double r, double theta);
}
private
으로 변수를 설정하더라도 값마다 get
와 set
함수를 둔다면 구현을 외부로 노출한다고 볼 수 있다. 변수 사이에 함수라는 계층을 넣더라도 구현이 감춰지는 것이 아니다. 구현을 감추기 위해서는 추상화가 필요하다. 추상 인터페이스를 제공해 사용자가 구현 부분을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 클래스이다.
// 연료 상태를 구체적인 숫자로 나타냄
public interface Vehicle {
double getFuelTankCapacityInGallons();
double getGallonsOfGasoline();
}
// 연료 상태를 백분율이라는 추상적인 개념으로 알려줌
public interface Vehicle {
double getPercentFuelRemaining();
}
자료를 세세하게 공개하는 것보다는 추상적인 개념으로 표현하는 것이 좋다. 아무 생각 없이 조회/설정 함수를 추가하는 방법은 나쁘다.
객체는 추상화 뒤에 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
자료 구조는 자료를 그대로 공개하며 별다른 함수를 제공하지 않는다.
Point와 Vehicle 예제는 자료 구조와 객체 간의 차이를 나타낸다. 이 두 가지는 본질적으로 상반된 의미를 가진다.
public class Square {
public Point topLeft;
public double side;
}
...
public class Geometry {
public double area(Object shape) throws NoSuchShapeException {
if(shape instanceof Square) {
Square s = (Square) shape;
return s.side * s.side;
}
else if
...
}
}
위의 코드는 절차적인 도형 클래스이다. Square과 같은 도형 클래스는 메소드를 제공하지 않는 간단한 자료 구조이다. 도형이 동작하는 방식은 Geometry 클래스에서 구현한다. Geometry 클래스에 새로운 함수를 추가하더라도 기존의 도형 클래스는 아무런 영향도 받지 않는다. 하지만 새로운 도형을 추가한다면 Geometry 클래스에 속한 함수를 모두 고쳐야 한다.
public class Square implements Shape {
private Point topLeft;
private double side;
public double area() {
return side * side;
}
}
이번에는 객체 지향적인 도형 클래스이다. area 메소드는 다형 메소드이며, 앞선 코드와는 다르게 Geometry 클래스를 필요로 하지 않는다. 따라서 새로운 도형을 추가하더라도 기존 함수에는 영향을 미치지 않는다. 하지만 새로운 함수를 추가하고 싶다면 도형 클래스 전부를 고쳐야 한다.
결국, 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다.
구현하려는 시스템에 자료 구조와 객체 중 더 적합한 것을 사용하자.
디미터 법칙이란, 모듈은 자신이 조작하는 객체의 내부를 몰라야 한다는 법칙이다. 객체는 자료를 숨기고 함수만을 공개하는데, 이는 조회 함수 등을 통해 객체 내부의 구조를 공개하면 안 된다는 의미이다.
더 정확하게 표현하면, 클래스 C의 메소드 f는 다음과 같은 객체의 메소드만 호출해야 한다.
또한, 위의 허용된 메소드가 반환하는 객체의 메소드는 호출하면 안 된다.
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
이 코드는 디미터 법칙을 어기고 있는 것처럼 보인다. 각 메소드가 반환하는 객체의 메소드를 호출하고 있기 때문이다.
이렇게 생긴 코드를 기차 충돌이라 부른다. 조잡하다고 여겨지는 방식이기 때문에 피하는 것이 좋으며, 여러 줄로 나눠 작성하는 것이 좋다.
// 나눠서 작성한 코드
Options opions = ctxt.getOptions();
File scratchDir = options.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();
이제 이 코드가 디미터 법칙을 위반하는지를 살펴보자. 이것을 판단하기 위해서는 ctxt, Options, ScratchDir이 객체인지 자료 구조인지를 알아야 한다. 객체라면 반드시 내부 구조를 숨겨야 하기 때문에 디미터 법칙을 위반한 것이고, 자료 구조라면 내부 구조를 드러내기 때문에 법칙이 적용되지 않는다.
자료 구조는 무조건 메소드를 제외한 공개 변수만 포함하고, 객체는 비공개 변수와 공개 메소드만 포함한다면 혼동이 생기지 않을 것이다. 하지만 이를 위반하는 프레임워크와 표준이 있기 때문에 절반은 객체, 절반은 자료 구조인 잡종 구조가 생겨난다.
잡종 구조는 새로운 함수나 자료 구조를 추가하기 어렵다. 클래스와 자료 구조의 장점은 사라지고 단점만 남은 것이다. 따라서 최대한 피하는 것이 좋다.
ctxt, Options, ScratchDir이 진짜 객체라면 기차 충돌 코드를 생성하지 않아야 한다. 그러면 어떤 방법으로 코드를 작성해야 할까?
ctxt.getAbsolutePathOfScratchDirectoryOption();
ctxt.getScratchDirectoryOption().getAbsolutePath();
첫 번째 코드는 ctxt 객체가 구현해야 하는 메소드가 많아질 우려가 있다. 두 번째 코드는 getScratch~~ 메소드가 자료 구조를 반환한다고 가정하고 작성했는데, 이 방법도 마음에 들진 않을 것이다.
ctxt가 객체라면 내부를 들여다 보는 것이 아니라 어떠한 동작을 하라고 명령을 내려야 한다. 임시 디렉토리(ScratchDir)의 절대 경로가 왜 필요한지 찾아서 해결 방안을 찾는 것이 좋은 방법일 것이다.
// 같은 모듈 내 outputDir을 사용하는 부분
String outFile = outputDir + "/" + className.replace('.', '/') + ".class";
FileOutputStream fout = new FileOutputStream(outFile);
BufferedOutputStream bos = new BufferedOutputStream(fout);
결국 절대 경로를 얻는 이유는 임시 디렉토리의 경로를 통해 임시 파일을 생성하기 위해서였다. 여기서 임시 파일을 생성하는 동작을 ctxt가 수행하도록 변경한다면,
이러한 장점을 지니게 되고, 최종적으로 디미터 법칙을 위반하지 않게 된다.
계속해서 말하지만, 자료 구조는 공개 변수만 있고 함수는 존재하지 않는 클래스이다. 때로는 자료 구조를 DTO(Data Transfer Object, 자료 전달 객체)라고 부르는데, DB와 통신하거나 소켓을 통해 받은 메세지를 분석할 때 유용하게 사용할 수 있다.
DTO는 주로 DB 등에 가공되지 않은 형태로 저장된 정보를 어플리케이션 코드에서 사용할 객체로 변환하는 단계에서 가장 처음으로 사용하는 구조체이다.
좀 더 일반적인 형태로 bean
구조가 존재하는데, 이는 private
변수를 조회/설정 메소드로 조작하기만 할 뿐 별다른 이익을 제공하지는 않는다.
public class Address {
private String street;
private String streetExtra;
private String city;
private String state;
private String zip;
public Address(String street, String streetExtra, String city, String state, String zip) {
this.street = street;
this.streetExtra = streetExtra;
this.city = city;
this.state = state;
this.zip = zip;
}
public String getStreet() {
return street;
}
... getters
}
활성 레코드는 DTO의 특수한 형태이다. public
변수가 있거나, private
변수에 조회/설정 함수가 존재하거나, save나 find와 같은 함수도 제공하는 경우가 있다.
활성 레코드에 비즈니스 규칙 메소드를 추가하여 자료 구조를 객체로 취급하는 것은 앞서 말한 잡종 구조가 될 수 있기에 피하는 것이 좋다. 활성 레코드는 자료 구조로 취급하고, 비즈니스 규칙을 담으며 내부 자료(활성 레코드의 인스턴스)를 숨기는 객체를 따로 생성한다.
// 잘못된 코드
public class Person {
private String name;
private String phone;
public Person(String name, String phone) {
this.name = name;
this.phone = phone;
}
public void call() {
...
}
...
}
// 올바른 코드
public class Person {
private String name;
private String phone;
public Person(String name, String phone) {
this.name = name;
this.phone = phone;
}
...
}
public class Caller {
private Person receiver;
public void call() {
...
}
}
시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 적합하며 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 적합하다.
우수한 개발자는 직면한 문제에 최적인 해결책을 선택해야 한다.