[스터디2] 01. 객체의 종류

목차

 

 

 

 

 

  제목: 자바/스프링 개발자를 위한 실용주의 프로그래밍

  저자: 김우근

  출판사: 위키북스

  가격: 32,000원

 

 

다시 제대로 배우는 애플리케이션 개발

 

 

 

 

 

데이터베이스 스터디가 끝난 후, 같은 스터디원들과 함께 자바/스프링 스터디를 진행하기로 했습니다. 이전까지 하던 방식과 동일하게 블로그에 학습 내용을 정리한 후, 자신이 배운 내용을 설명하는 식으로 할 것 같습니다.

 

이 책의 첫인상은 쉬운 언어로 이해하기 쉽게 설명하며, 같은 말을 여러 번 반복하면서 기억에 남게 해준다는 것입니다. 이번 파트에서는 객체지향에 대해 몰랐던 내용과 DTO, DAO에 대해 애매하게 알고 있던 지식을 바로 잡을 수 있었습니다.

1장. 객체지향

• 객체지향: 복잡한 문제를 역할과 책임에 따라 개별 객체로 분해함. 분해한 각기 다른 특성과 기능을 가진 수많은 객체들이 상호작용하고 협력해 소프트웨어가 당면한 문제를 해결하는 방법임.

1. 절차지향과 비교하기

▲ 은행에서 돈을 송금하는 작업 예

먼저, 예시를 통해 각 프로그래밍에 대해 이해함. 위 그림에서 은행에서 돈을 송금하는 작업에 대해 두 방식을 비교하면 다음과 같음.

• 절차지향 프로그래밍
  • 작업이 함수 단위로 나뉘어 있으며, 하나의 함수가 끝나면 다음 함수가 호출됨.
  • 데이터와 작업(로직)이 분리되어 있으며, 함수들이 데이터를 처리함.
  • 대표 언어: C, Fortran, Pascal

• 객체지향 프로그래밍
  • 작업이 각각 객체 단위로 분리됨.
  • 각 객체는 자신의 책임(계좌 검증, 송금 처리 등)을 알고 있으며, 메시지(요청)를 받아 이를 수행함.
  • 데이터와 로직이 객체 내부에 캡슐화되어 있음.
  • 대표 언어: Java, C++, Python, Ruby

절차지향(procedure oriented) 이전에 순차지향(sequential oriented)이라는 패러다임도 있었음.

• 순차지향 프로그래밍은 코드가 위에서 아래로 순차적으로 실행되는 프로그래밍 방식임.
• 순차지향과 절차지향은 같은 말이지만 다른 패러다임임. 원래 명칭을 잘 해석해보면 알 수 있음.
  • 순차지향은 '순차적으로(sequential)' 라는 뜻으로 코드를 위에서 아래로 읽겠다는 의미임.
  • 절차지향의 'procedure(절차)'는 컴퓨터 공학에서 말하는 'Procedure(사실 함수)'이다. 따라서 절차지향 프로그래밍은 함수 지향 프로그래밍으로, 복잡한 문제를 개별 함수로 분해하고 여러 함수를 이용해 문제를 해결하는 방식임.

절차지향 코드를 객체지향적으로 바꾸면 다음과 같음.

• 객체에 어떤 메시지를 전달할 수 있게 됨.
• 객체가 어떤 책임을 지게 됨.
• 객체는 어떤 책임을 처리하는 방법을 스스로 알고 있음.

객체지향은 가독성 보다는 책임에 집중함.

• 캡슐화: 객체끼리 협력하지만, 서로의 내부 동작 방식은 신경 쓰지 않음.
• 테스트 코드: 객체 간 협력에서 계약(책임)을 지키는지 확인하기 위해 사용됨. 테스트 코드는 요구사항 만족 여부를 검증함.

1.1 책임과 역할

---

C언어가 객체지향 언어가 아닌 이유는 다음과 같음.

• C언어의 구조체(struct)는 추상의 개념을 지원하지 못함.
• 자바의 인터페이스처럼 다형성을 지원하는 기능이 없음.
• 구조체는 데이터를 한 곳에 모으는 것이 목적이며, 추상화를 지원하려고 만들어진 기능이 아님.

1.2 TDA 원칙

---

• TDA 원칙: 'Tell, Don't Ask(물어보지 말고 시켜라)'의 줄임말로, 객체에게 값에 관해 물어보지 말고 일을 시키라는 의미임.
• 무분별하게사용되는 게터(getter)와 세터(setter)를 줄이라는 의미로 해석할 수 있음. 

2. 객체의 종류

2.1 VO(Value Object: 값 객체)

---

어떤 객체가 아래 3가지 특징을 만족할 때 VO라고 부름.

1. 불변성(Immutability): 값은 변하지 않음.
   • final 키워드를 활용하여 상태를 변경할 수 없도록 설정함.
   • final로 선언되어도 객체의 불변성이 지켜지지 않으면 불변성이 깨질 수 있음. 즉, final 키워드 자체로는 불변성을 보장하지 않음.
2. 동등성(Equality): 값의 가치는 항상 같음.
   • equals와 hashCode 메서드의 오버라이딩(재정의)를 통해 동등성을 확보함.
   • Lombok의 @Valuer 애너테이션을 사용하면, 다음과 같은 기능이 자동으로 추가되어 값 객체를 만들 때 해당 객체를 명시적으로 VO로 나타낼 수 있음.
     • equels와 hashCode 메서드가 객체의 상태에 따라 비교하는 메서드로 자동 생성됨.
     • 멤버 변수가 final로 선언됨.
     • 클래스가 final로 선언됨.
3. 자가 검증(Self-validation): 값은 그 자체로 올바름.
   • 클래스 스스로 상태가 유효한지 검증할 수 있음. 즉, 유효하지 않은 상태의 객체가 만들어질 수 없음.
   • 생성 시점에 검증 로직을 추가하여 객체가 유효한 상태인지 확인함.

2.2 DTO(Data Tranfer Object: 데이터 전송 객체)

---

• DTO: 데이터 전송에 사용되는 객체

// DTO 예시
public class UserCreateRequest {
	
    public String username;
    public String password;
    public String email;
    public String address;
    public String gender;
    public int age;
}

// UserCreateReaquest 클래스는 메서드를 호출할 때 매개변수로 사용할 수 있음.
userService.create(userCreateRequest);

• DTO는 데이터를 하나하나 일일이 나열해서 전달하는 게 불편해서 데이터를 하나로 묶어서 보내려고 만들어진 객체임.
•  DTO에 관한 오해
  1. DTO는 프로세스, 계층 간 이동에 사용됨.(△)
     • DTO의 목적은 데이터를 전달하는 것으로, 데이터를 전달하고 싶은 상황이라면 어디서든 사용될 수 있음.
     • 따라서 DTO가 어디에서 사용되느냐는 중요하지 않음. 데이터 전송이 필요한 모든 곳에서 사용 가능함.
  2. DTO는 게터, 세터를 갖고 있음.(X)
     • 게터, 세터는 내부 데이터를 전달하기 위한 방법 중 하나일 뿐임.
     • 게터, 세터 없이 멤버 변수를 public으로 선언하면 내부 데이터를 전달할 수 있음.
     • 더 나아가 JSON 같은 형식을 활용해 문자열로 데이터를 주고받을 수도 있음.
  3. DTO는 데이터베이스에 데이터를 저장하기 위해 사용되는 객체임.(X)
     • DTO는 데이터를 전송하기 위한 객체로, '데이터=데이터베이스 데이터'로 착각하고 있음.
     • API 통신에 사용되는 요청 본문(request body), 응답 본문(response body)을 받는 데 사용되는 객체도 DTO고, 객체도 DTO고, 데이터베이스에서 데이터를 불러오고 저장하는 데 사용되는 객체도 DTO고, 객체 간 데이터를 주고받기 위한 객체도 DTO임.

2.3 DAO(Data Access Object: 데이터 접근 객체)

---

• DAO: 데이터베이스 접근과 관련된 역할을 지닌 객체
• DAO의 역할
  • 데이터베이스와의 연결을 관리함.
  • 데이터베이스에 연결해 데이터에 대한 CRUD 연산을 수행함.
  • 보안 취약성을 고려한 쿼리 작성함.
• DAO의 목적은 도메인 로직과 데이터베이스 연결 로직을 분리하기 위한 것임.

2.4 엔티티(Entity: 개체)

---

• 엔티티는 JPA의 @Entity로 선언된 클래스다.(X)
• 헷갈리기 쉬운 엔티티 3가지
  1. 도메인 엔티티: 식별 가능하고 비즈니스 로직을 갖고 있으며, 조금 특별하게 관리되는 클래스로 만들어진 객체
  2. DB 엔티티: 데이터베이스에 표현하려고 하는 유형, 무형의 객체로써 서로 구별되는 것 
  3. JPA 엔티티: 관계형 데이터베이스에 있는 데이터를 객체로 매핑하는 데 사용되는 클래스

2.5 객체의 다양한 종류

---

• 영속성 객체(PO: persistent object): 데이터베이스와의 연동을 추상화하고, 데이터 액세스를 담당함으로써 애플리케이션의 비지니스 로직과 영속성 로직을 분리하려는 목적으로 사용됨.
• SO(service object): 영속성 객체를 통해 도메인을 불러와 도메인에 업무를 지시하기도 하고, 비지니스 로직이라 불리는 애플리케이션의 코어 로직을 처리하는 객체를 의미함.
• 개념을 외우고 엄격한 기준을 적용하는 것보다는 각 개념이 만들어진 이유와 목적을 생각하는 것이 바람직함. 그리고 지금까지 배운 가치(불변성, 예측 가능성, 역할의 분리, 항상성)에 집중하는 것이 중요함.

이 글은 『자바/스프링 개발자를 위한 실용주의 프로그래밍』 책을 학습한 내용을 정리한 것입니다.