[Clean Code] Chap6. 객체 vs 자료구조

자료구조 vs 객체

• 자료구조 vs 객체
• 

//자료구조
public interface Vehicle {
    double getFuelTankCapacityInGallons();
    double getGallonsOfGasoline();
}

public class Car implements Vehicle {
    double fuelTankCapacityInGallons;
    double gallonsOfGasoline;

    public double getFuelTankCapacityInGallons() {
        return this.fuelTankCapacityInGallons;
    }

    public double getGallonsOfGasoline() {
        return this.gallonsOfGasoline;
    }
}

자료구조는 값을 가져올 뿐 비즈니스 로직이 없다.

public interface Vehicle {
    double getPercentFuelRemain();
}

public class Car implements Vehicle {
    double fuelTankCapacityInGallons;
    double gallonsOfGasoline;

    public Car(double fuelTankCapacityInGallons, double gallonsOfGasoline) {
        if (fuelTankCapacityInGallons <= 0) {
            throw new IllegalArgumentException("zero"); // 0보다 커야된다는 예외 설정을 통해 인스턴스 생성 제한
        }
        this.fuelTankCapacityInGallons = fuelTankCapacityInGallons;
        this.gallonsOfGasoline = gallonsOfGasoline
    }

    public double getPercentFuelRemain() {
        return this.gallonsOfGasoline / this.fuelTankCapacityInGallons * 100;
    }
}

단순히 값을 가져오는 것이 아니라 그 값을 계산을 해서 넘겨준다. (비즈니스 로직이 존재)

음수일 경우처럼 메서드를 만들 때 Validation을 생각하자.

• 휴대폰 배터리처럼 실제 수치는 중요하지 않고, 퍼센트만 중요하다면?
  • 사용자 관점에 맞춰서 퍼센트만 보여주기 위해 객체로 만드는 것이 적합하다.

새로운 도형이 추가된다면? 새로운 else if ~ 라면?을 추가해야 한다.

절차적인 코드(자료구조)는 새로운 자료 구조를 추가하기 어렵다. 함수를 고쳐야 한다.

객체지향 코드는 새로운 클래스를 추가하기 쉽다. 하지만 함수를 추가(area 메서드)해야 한다.

즉, 상황에 맞는 선택을 하면 된다.

자료구조는 기본 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽지만, 자료구조를 추가하기 어렵다.

객체는 새로운 클래스를 추가하기 쉽지만, 새로운 함수를 추가하기 어렵다. (area 말고 새로운 메서드가 생성될 경우)

객체 - 디미터 법칙

• 휴리스틱 : 경험에 기반하여 문제를 해결하기 위한 방법 (의사결정 단순화)

기차 충돌

• 디미터의 법칙에 어긋나는 상황

연쇄적으로 다른 메서드를 호출하는 경우 디미터 법칙에 어긋난다.

단, 객체 지향적 코드의 관점에서 발생한다.

DTO

• 다른 계층 간 데이터를 교환할 때 사용 (자료구조로 봐도 무방하다.)
• 로직 없이 필드만 갖는다. (getter/setter 를 갖기도 한다.)
• Beans
  • Java Beans : 데이터 표현이 목적인 자바 객체
  • 멤버 변수는 private 속성
  • getter / setter를 가진다. (setter 대신 public으로 인스턴스를 공개하는 경우도 존재)

Activate Record

• Database row를 객체에 매핑하는 패턴
• 비즈니스 로직 메서드를 추가해 객체로 취급하는 건 바람직하지 않다.
• 현업에서는 Entity에 간단한 메서드를 추가해 사용하기도 한다.
• 즉, 객체가 row를 담을 뿐 아니라, db에 대한 접근을 포함한다.
  • 속성을 담을 뿐 아니라, 수정, 생성도 객체 안에서 수행할 수 있다. (Repository 기능도 Entity에 들어가있는 상황)

public class Employee extends ActiveRecord{
    private String name;
    private String address;
    ...
}

Employee bob = Employee.findByName("Bob");
bob.setName = ("Robert C. Martin");
bob.save();

Entity와 비슷해 보이지만 비즈니스 로직이 존재한다.

Data Mapper

• row를 담는 객체와 db에 접근할 객체가 분리
• 속성을 담는 엔티티와, 생성, 수정 등 액션 처리는 매퍼에서 담당

---

본 포스팅은 Clean Code (Robert C. Martin), 제로베이스-한달한권(클린코드)를 참고하여 작성하였습니다.