영속성 컨텍스트(persistence context) 쉽게 말하면 엔티티를 영구 저장하는 환경이다. 즉, 엔티티 메니저로 엔티티를 저장하거나 조회하면 엔티티메니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다. 영속성 컨텍스트는 엔티티 메니저 당 하나씩 할당한다 엔티티의 생명주기 엔티티는 4가지 상태가 존재한다. - 비영속 : 영속성 컨텍스트와 전혀 관계가 없는 상태 순수한 객체 상태이며, 아직 저장되지 않음. DB와 전혀 관련 없는 객체 - 영속 : 영속성 컨텍스트에 저장된 상태 - 준영속 : 영속성 컨텍스트에 저장되었다가 분리된 상태 영속성 컨텍스트가 관리하지 않으므로 거의 비영속 상태에 가깝고, 그렇기에 지연 로딩을 할 수 없다. 하지만, 식별자 값을 가지고 있다는 특징이 있다. - 삭제 : 삭제된..

엔티티 메니저 이름 그대로 엔티티를 관리하는 관리자다. 엔티티를 저장, 수정, 삭제, 조회 등 엔티티와 관련한 모든 일을 처리한다. JPA 대부분 기능은 엔티티 메니저에서 제공한다. 엔티티 메니저는 DB 커넥션과 밀접한 관계가 있으므로 스레드 간 공유하거나 재사용을 하면 안 된다. 엔티티 메니저는 엔티티 메니저 팩토리를 통해 생성된다. 엔티티 메니저 팩토리 이름 그대로 엔티티 메니저를 만드는 공장이다. 데이터 커넥션 풀도 생성할 정도로 생성 비용이 아주 크다. 즉, 엔티티 메니저 팩토리는 애플리케이션 전체에서 딱 한 번만 생성하고 공유해서 사용해야 한다.

객체지향 설계란 올바른 객체에게 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동이다. 적절한 비용 안에서 쉽게 변경할 수 있는 설계는 응집도가 높고 서로 느슨하게 결합되어 있다. 중요한 것은 객체의 상태가 아닌, 객체의 행동에 초점을 맞추는 것이다. 객체 지향 설계는 두가지 방법이 있다. 첫 번째 방법은 상태(데이터)를 분할의 중심축으로 삼는 방법이고, 두번째 방법은 책임을 분할의 중심축으로 삼는 방법이다. 객체지향 설계는 상태(데이터)가 아니라 책임에 초점을 맞춰야 한다. 객체의 상태는 구현에 속하기 때문이다. 허나 책임은 인터페이스에 속한다. 인터페이스(책임) 뒤로 구현(상태)을 갭출화해야 안정적인 설계를 얻을 수 있다. 즉, 데이터를 중심으로 설계하면 안 된다. 이 ..

객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다. 객체지향의 핵심은 적절한 객체를 찾고, 적절한 책임을 할당하는 과정에서 드러난다 # 협력 객체는 고립된 존재가 아닌 다른 객체와 협력하는 사회적인 존재이다. 객체들은 협력하여 시스템 기능이라는 큰 목표를 달성한다. 두 객체 사이 메시지 전송/수신 을 통해 커뮤니케이션하며 목표를 이룬다. 매시지를 수신한 객체는 스스로 메시지 처리할 방법을 선택하여 내부에 구현한 메서드를 실행해 요청에 응답한다. 각 내부 구현은 외부에서 직접 접근을 못하게 캡슐화를 한다. 정리해보면, 객체가 자신이 할당된 책임을 수행하던 중에 외부의 도움이 필요하면 적절한 객체에게 메시지를 전송해서 협력을 요청한다. 이러한 협력이 연쇄되어 애플리케이션의 기능이 구현된다. 상태는..

# 영화 예매 시스템 영화관 예매 시스템을 만든다고 가정해보자. 영화표를 구매할 때 할인을 받을 수 있다. 할인액을 결정하는 데 두 가지 규칙이 존재하는데, 하나는 할인 조건(discount condition), 다른 하나는 할인 정책(discount policy)가 있다고 보자. 할인 조건은 할인 여부를 결정하며 '순서 조건'과 '기간 조건'이 있다. 순서 조건은 상영 순번이 일치하면 할인을 해주는 것이고, 기간 조건은 상영 시작 시간이 해당 기간 안에 포함하면 할인해주는 것이다. 할인 정책은 '금액 할인 정책' 과 '비율 할인 정책'이 있다. 금액 할인 정책은 예매 요금에서 일정 금액을 할인해주는 방식이며, 비율 할인 정책은 일정 비율만큼 할인해주는 방식이다. 영화별로 하나의 할인 정책만 할당 가능하..

# 들어가며 이론이 먼저일까 실무가 먼저일까? 글래스의 주장에 따르면 초기에는 실무가 먼저 급속할 발전을 이룬다고한다. 이론이 정립할 수 없기 때문이다. 실무가 어느 정도 발전하고 나서야 실용성을 입증하는 이론이 모습을 갖춰가고, 해당 분야가 충분히 성숙해지는 시점에 이르러서야 이론이 실무를 추월하게 된다고 한다. 즉, 이론보다 실무가 먼저다. SW 분야도 마찬가지이다. 아직까지 다른 공학에 비해 역사도 짧다. 컴퓨터가 세상에 나온 이후 수많은 SW가 설계되고 개발되었으나, 이론은 1970년대 돼서야 슬슬 모습을 비추기 시작했다. 이 이론들 역시 실무에서 반복적으로 적용되던 기법들을 이론화한 것을디 대부분이다(디자인패턴, 리팩터링 등) 유지보수에 대한 이론은 거의 전무하다. 따라서 SW에 대한 설계/유지..