DeveloperRio DeveloperRio

JPA 에서는 프록시 객체를 사용하는 경우가 있다. entityManager 의 getReference 를 이용하며, 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체를 조회한 결과를 반환한다. 사용하는 입장에서는 굳이 진짜 객체인지, 프록시 객체인지 확인해가면서 쓸 필요는 없다. 이러한 특징을 이용하면, 지연로딩과 즉시로딩을 이용할 수 있다. 실무에서는 가급적 지연로딩을 사용한다. 즉시로딩은 어마어마한 쿼리가 실행될 수 있으니 지양한다. 상속과 별개로 영속성 명령어를 한꺼번에 실행되도록 전이시키는 설정을 CASCADE 라 한다. 편한 기능인 만큼, 성질을 잘 알고 써야 한다. 또한 고아 객체라는 것이 있다. 부모 엔티티와 연관관계가 끊어지면 자동으로 삭제해주는 기능이다. 삭제 그 이상 그 이하도 아..

상속과 같은 느낌으로 쓰이나 상속이 아니다. 처음 mapped superclass 를 봤을 때, 상속 관계의 테이블마다 전략과 동일한 것이 아닌가? 생각했었다. 하지만 결론적으론 다르다. 상속관계가 아니기 때문에 기능적으로 다르게 동작한다. 이 부분만 염두해두면 될 것 같다. 결국 mapped superclass 는 공통적으로 적용하고 싶은 필드가 있을 때 사용해야 한다. 필드 타이핑을 줄여준다. 그 이상 그 이하 의미도 없다.

3장에서는 세 가지를 알아본다. Observables, Observers, Subjects Observables Observable 을 설명하면서 Observer 가 필요하다. (이하 옵저버블과 옵저버) 옵저버블은 옵저버가 Pull 하는 방식을 갖고 있지 않다. 옵저버블은 옵저버(컨슈머) 에게 Push 하는 방식을 가지고 있다. 간단한 3단계를 보자. - 옵저버는 옵저버블을 구독한다. - 옵저버블이 그 내부의 아이템을 보내기 시작한다. - 옵저버는 옵저버블이 내보내는 모든 아이템에 반응한다. '구독' 이라는 단어가 생소하면서 어쩌면 당연하다는 생각이 든다. 옵저버블이 옵저버에게 Push 하는 방식이기 때문에 적어도 누구에게 Push 해야하는지는 알고 있어야 하지 않을까? 누구에게 할 지 미리 알고 있다는..

함수형 프로그래밍의 정의로 시작한다. 이 책은 정의를 먼저 언급하고 예시와 비교를 통해 추가 설명해주는 과정이 너무 좋다. 함수형 프로그래밍은 작고 재사용 가능한 선언적인 함수의 사용을 권장하는 선언적인 프로그래밍 패러다임이다. 함수형 리액티브 프로그래밍은 리액티브 프로그래밍과 함수형 프로그래밍을 혼합한 개념이다. 함수형 프로그래밍의 목적은 쉽게 모듈화가 가능한 프로그램을 구현하는 것이다. 모듈화된 프로그램은 반응형 프로그래밍을 구현하거나 필요에 따라 리액티브 선언문의 네 가지 원칙을 구현하는 데 필요하다. 좋은 정의다. 그냥 좋기만 하다. 아직은 이해할 수가 없다. 세부적인 내용들을 공부하면서 위 정의를 제대로 이해해보자. 일단 함수형 프로그래밍의 정의를 기준으로 세부적인 내용을 봐보자. 함수형 프로그..

코로나 사태로 인해 갑작스런 재택근무를 다시 하게 되었다. 이참에 새로운 느낌으로 기존에 공부하고 있던 JPA 를 슬쩍 닫아주고, 재택 기간동안 한권의 책을 파보자라는 생각으로 책을 구입했다. 01. 리액티브 프로그래밍 소개 리액티브 프로그래밍 정의는 '데이터 스트림과 변경 사항 전파를 중심으로 하는 비동기 프로그래밍 패러다임' 이다. 단어 하나하나가 이해가 안되는 건 아니다. 뜻도 알겠다. 하지만 와닿는 설명은 아니다. 책에서 예를 들어 주고 있는데 훨씬 와닿는다. 아래 예를 들어 설명한 내용을 보자. 리액티브란 구글 시트에서 함수를 적용하고, 셀에 입력한 숫자를 수정하면 다른 셀에 있는 숫자가 자동으로 변경되는데 이를 리액티브라고 한다. 다시 생각해보면 정의만 읽으면 어려워 보이지만 우리가 이미 이해..

상속관계가 있는 데이터를 어떤 식으로 디비에 저장하는 지에 대해서 정리한다. 아이템이라는 부모테이블 아래, 영화, 책 등등 데이터가 있는 구조가 있을 때, 자바 클래스는 차이가 없다. 아예 없진 않지만... Enum 값만 변경해주면 된다. 세가지 방법은, 조인전략, 단일테이블, 테이블마다전략. 간단히 이야기하면 분리하되 FK 를 둔다. 다 합쳐 놓는다. 아예 연관관계 없이 분리한다. 세가지 방법으로 테이블을 구성할 수 있다. 각각의 장단점이 있다. 일반적인 경우는 선호하는 것이 있겠지만, 각각 상황에 맞게 사용하면 될 것 같다. 개인적으로 선호하는 건, 없다... 다 뭔가 장단점이 있어서 상황에 맞게 사용하는 게 좋을 것 같다.

저자가 가장 중요하다고 한 챕터이다. 독자로서의 생각은 정말 중요하다고 생각하셨는지... 처음부터 조금씩 조금씩 계속 이야기하시던 것을 집합해서 길게 다시 한번 이야기해주는 느낌이었다. 덕분에 읽는 동안에 인지하고, 생각이라는 것을 하게 되었다. 객체라는 것은 결국 행위와 상태라는 것을 가지고 있는 단위다. 객체지향이라는 것은 그 객체들간의 세계를 만들고, 그 객체들간에 메세지를 주고 받으면서 살아가는 것을 말한다. 특이한 점은 객체는 책임과 역할이라는 것을 가지고 있지만, 그 책임과 역할을 수행하는 방식은 객체 자신에게 자율성이 있다. 즉, 내 역할, 내 책임은 있지만, 그걸 해결하기만 하면 될 뿐, 그걸 어떻게 해결하는지는 상관하면 안된다는 뜻이기도 하다. 저자는 사실 이 점을 처음부터 계속 은연 중..

다대다는 처음부터 '사용할 일이 없다' 라고 말하면서 시작한다. 정확히는 '사용하면 안된다' '사용하면 굉장히 불편해진다' 라고 표현하는게 맞는 것 같다. JPA 에서는 데이터를 객체지향적으로 다루는데 목적을 두고 있으므로 다대다에 기능을 제공하고 있다. 그 목적에는 충실하지만, DB 구조상으로 다대다는 굉장한 불편함을 가지고 있으므로 피해야 한다고 말하고 있다. 어떤 불편함이 있어서 --> 이런식으로 하면 편합니다 --> 하지만 처음의 불편함 때문에 이건 피해주세요 개발 공부를 하다보면 이런 경우가 가끔 있다. 와 이거 편하다. 이렇게 하면 좋아 라고 하는데 결국 기존 한계 때문에 다른 한계를 만들 때가 있다. 이런 경우 어떤 것이 더 편한가 불편한가를 따져야 하는지, 그래서 베이직이 더 중요하다라고 ..