요즘 개발하며 중심으로 생각하는 것이,
객체가 직접 일하게 만들자
이다. 그동안 개발을 하며 테이블 중심으로 개발을 했었다.
그에 앞서서 객치지향
이란 무엇인가? 나의 정의는
역할을 가진 객체들끼리 메시지를 주고받으며 협력하는 공동체
라고 생각한다.
여기서 역할
이란, 자신의 관심사에 책임을 가진 채로 행하는 기능을 의미한다. (ex 바리스타는 커피를 만든다
는 관심사에 책임을 갖고 커피를 만든다
라는 역할을 가졌다.)
그리고 메시지
란, 한 객체가 자신의 관심사를 벗어나 있는 영역에 대해서는, 다른 객체에게 도움을 요청하게 된다. 이때 도움을 '요청'한 뒤에 필요한 정보를 얻는 것이지, 다른 객체의 사적인 영역에 침범해 원하는 정보를 가져가서는 안된다(객체의 캡슐화
). 이렇게 다른 관심사의 객체에게 보내는 요청
과 응답 받는 정보를 의미한다.
딱 세 가지 키워드만 뽑으라면 캡슐화
, 역할
, 협력
라고 생각이 든다.
public class Member {
private Long id;
private String name
public Long getId() {
return this.id;
}
public String getName() {
return this.id;
}
public void setId(Long id) {
this.id = id;
}
public void setName(String name) {
this.name = name;
}
}
이런 식으로 한 엔티티에 대해서는 속성을 담는 그릇, 즉 테이블로서 생각을 하고 개발을 했었다.
-> Getter와 Setter의 향연...
Getter와 Setter는 어쩌면 `객체지향`을 방해하는 요소라는 생각이 든다. 단순히 객체를 CRUD의 관점에서
접근하기 때문이다. 대부분의 사람들이 프로그래밍 언어를 배울 때, 이렇게 CRUD의 관점으로 배우기 시작한다.
나도 그렇다.
일하는 객체가 아닌, 테이블로서의 객체로 생각하는게 나의 생각에 박혀 있어서 아쉽다. 처음부터 제대로 `
객체지향`을 학습했다면... 이라는 생각을 많이 하게 됐다.
그래서 나는 개발을 할 때, 자존감 있는 객체
를 만들자는 생각을 개발을 한다. 이 부분은 뒤에서 다시 이야기하겠다.
데이터베이스 중심으로 개발을 하게 되면, 객체지향
이라는 큰 장점을 잃은 채로 Java를 사용하게 된다.
Spring이 Java를 기반으로 한 이유가 있다 이거야...
객체지향을 조금은 맛보고 적용해 본 입장에서 생각해봤을 때, 데이터베이스 중심으로 개발을 하게 되면,
- 가장 근본적으로,
객체지향
프로그래밍이 아니다.
- 객체의 캡슐화? 없다. Getter와 Setter로 외부에서 마음대로 값을 가져가고 수정한다.
- 객체의 역할? 없다. 테이블로서 작용하니 행하고 있는 기능이 없다.
- 객체의 캡슐화가 부족해, Getter와 Setter가 많아 객체의 속성 값을 마음대로 읽고 수정할 수 있다.
- 엔티티에 역할이 없으니, 도메인과 동떨어진다.
- Member 엔티티는 회원가입을 한다는 도메인이 존재한다.
하지만 코드 상에서는insertUser()
일 뿐...join()
이나singup()
이 더 도메인 지향적이다.
그리고 무엇보다도 객체지향
을 적용하고 새로운 개발을 하는 것처럼 느껴질 만큼 개발하는 것이 훨씬 재밌고, 능률이 좋아졌다.
위에서 언급한 자존감 있는 객체
는 객체의 캡슐화
를 기반에 두고 있다.
다른 객체에게 나의 private한 정보들에 마음대로 접근하지 못 하게 하고, 요청한 정보들에 내가 직접 처리해서 넘겨주자!!
를 의미한다.
예를 들어, Member 엔티티는 Team 엔티티에서 소속된 Member들을 확인하고 싶다.
이때 Team 엔티티는 immutable한 Member List를 제공하던지, 아니면 특정 멤버가 속해있는지 결과만 알려주는 등
직접 정보를 처리해 제공하게 하는 것이다.