01 협력하는 객체들의 공동체

객체란 상태(필드)와 행위(메서드)를 하나의 단위로 묶는 자율적인 존재라고 한다.

객체의 자율성은 객체가 다른 객체들과 명확히 구분되는것(캡슐화)으로부터 시작되고,

객체 지향의 핵심은 ‘클래스(설계도)’가 아닌 ‘객체(Object)’라고 한다. 또한 중요한것은 메시지를 주고받는 객체들의 동적인 관계 라고 한다. 그러므로 저자는 클래스의 구조와 메서드가 아니라, 역할, 책임, 협력에 집중하라고 한다.

 

또한, 객체는 두가지 덕목을 지녀야 한다고 한다.

1. 객체는 ‘협력적’ 이어야 한다.
2. 객체는 ‘자율적’ 이어야 한다.

 

• ‘객체는 협력적이어야 한다’ 는 말은 어느정도 희미하게나마 이해가 되는것 같았다. 객체지향 설계원칙에서는 모든 객체는 하나의 책임만을 져야 하기 때문에(단일 책임 원칙), 하나의 책임을 가지고 다른 객체들과 협력하여 하나의 결과물을 만든다.

 

• 하지만 ‘객체는 자율적이어야 한다’는 말은 이해가 잘 가지 않았다.
  
  "자율적이라고? 객체가 스스로 행동하고 결정해야한다는 말이야? 이게 무슨 말이지? 프로그래밍의 객체는 사람도, 하물며 인공지능도 아닌데, 어떻게 스스로 행동한다는거야? "
  
  ‘자율적’ 이라는 단어를 스스로의 행동을 결정(메서드)하고, 책임을 진다(단일 책임 원칙)는 의미에서 본다면, 객체는 메서드를 통해 스스로 동작하고 책임을 지는 존재, 즉 자율적인 존재여야 한다는 의미로 보여진다.

 

 

 

 

 

 

 

---

 

이를 기반으로 했을때, 현재 작업중인 Member 클래스의 필드를 보면 단일 책임원칙을 어기고 있다.

회원의 개인정보, 구독, 체육관 정보 등을 한번에 담고 있기 때문이다.

 @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    private String email;
    private String password;
    private String name;
    @Lob
    private String profileImage;
    private LocalDate birthdate;
    private String phoneNumber;
    private String address;
    @Enumerated(EnumType.STRING)
    private Gender gender;
    private Long height;
    private Long weight;
    //
    private String occupation;
    private String note;
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "team_id")
    private Team team;
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "gym_id")
    private Gym gym;
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "schedule_id")
    private Schedule schedule;
    private Role role = Role.MEMBER;
    //체육관 등록일
    private LocalDate gymJoinDate;
    //결제일
    private LocalDate subscribeDate;
    //만료일
    private LocalDate endSubscribeDate;
    //결제여부
    private boolean isSubscribed;

 

읽은 내용을 토대로 다시 재구성한다면 이런식으로 재구성할 수 있다.

 

  @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    @Embedded
    private PersonalInformation personalInformation;
    @Embedded
    private BodyProfile bodyProfile;
    @Embedded
    private GymInformation gymInformation;
    @Embedded
    private SubscribeInformation subscribeInformation;
    private String note;
    private Role role = Role.MEMBER;

그런데 의문이 생겼다. 객체란, 행동과 상태를 하나의 단위로 묶는것이라고 했는데, gymInformation 과 subcribeInformation은 각각 메서드(행위)와 필드(상태)를 가지고 있기 때문에 객체라고 부를 수 있다고 볼 수 있다.

 

그렇다면 필드와 생성자만을 가지고 있는 personalInformation, bodyProfile 은 객체인가? 객체가 아닌가?

-> '생성자 메서드'도 '메서드' 이기 때문에 객체이다.

 

이전까지는 참 많은 필드들을 그냥 한 클레스에 담아 넣었다.

잘 모르기도 했던것도 있고, 구현하기에 급급했던것도 있다. 이제와서 클레스들을  객체지향적으로 수정하자니, 프로젝트를 구현조차 제대로 되지 않은 상황에서  더 시간을 쓰는것은 아닌가 고민된다.

 

현재 내가 가진 고민은 다음과 같다.

1. 객체지향적으로 엔티티를 수정하면서 생기는 시간비용을 감수하면서까지 진행하는게 맞을까,
   아니면 구현이 우선일까?
2. 객체를 생성할때마다 메모리를 사용한다고 알고있는데, 그렇다면 어떻게 메모리를 효율적으로 사용할수있을까?