전체 글

복합키란? 복합 키(Composite Key)는 두 개 이상의 PK를 하나로 PK로 지정하는 것을 말한다. 이러한 복합키를 가지고 있는 논리 모델은 식별 관계와 비식별 관계로 구분되어 사용한다. 식별 관계 부모테이블의 기본키를 상속 받고 자식 테이블의 기본키 + 외래키의 구조로 사용되는 구조 입니다. 비식별 관계 비식별 관계는 부모 테이블의 기본키만 받아서 자식 테이블의 FK로 사용하는 것이 비식별 관계입니다. 이러한 관계는 FK가 Null이냐 아니냐에 따라서 필수적 비식별 관계와 선택적 비식별 관계로 구분되어집니다. JPA는 이러한 식별, 비식별 관계를 모두 제공합니다. JPA에서의 복합키 JPA에서는 아래와 같은 두개의 식별자를 사용하려면 오류가 발생하기 때문에 별도의 식별자 클래스를 만들어야합니다...

데이터 베이스에서 상속 관계 관계형 데이터베이스에서는 상속이라는 개념이 존재하지 않는다. 그래서 보통 슈퍼타입과 서브타입으로 분리시키는 방식으로 구현을 한다. 이러한 논리 모델을 구현하기 위해서는 세가지 방법이 존재하는데 각각 방법에 대한 장점과 단점을 알아보자 조인전략: 각각의 테이블로 변환 각각의 논리 모델을 모두 테이블로 만들고 부모테이블의 PK를 받아서 기본키와 외래키를 통해 사용하는 전략이다. 해당 방법을 사용할 때 주의할 점은 객체에서는 타입으로 구분할 수 있지만 데이터베이스에는 그런 개념이 없기 때문에 타입을 구분하는 전략을 사용해 주어야한다. Table 구조 Entity 구조 부모 클래스(Product) @Entity @Inheritance(strategy = InheritanceType...

JPA를 공부하다가 1:1 관계에서는 FetchType.LAZY 를 사용해도 지연 로딩이 되지 않고 바로 객체를 불러온다고 한다. 책에 있는 내용을 통해 해당 링크를 찾아봤지만 어떠한 원리로 일어나고 해결방법은 어떤 것이 있는지 알고 있어야 실무에 실제로 사용할 때 주의할 수 있을 것 같다. 발생 원인 class A { private Set bees; public Set getBees() { return bees; } public void setBees(Set bees) { this.bees = bees; } } class B { // Not important really } 보통 하이버네이트에서 프록시객체를 생성할 때 위와 같은 클래스 구조가 있고 하이버네이트가 Class A를 호출하게 되면 일단 초기..

결합도가 낮은 설계는 서로 의존하는 정도가 낮으면 결합도가 낮다고 한다. 하지만 이러한 추상적인 의미는 실무하는데 있어서 크게 메리트가 없는 내용이다. 내가 결합도가 높은 코드를 짰을 때에도 이러한 조건에 충족이 되기 때문이다. 아래의 예제를 보면 public class RevervationServiceImpl implements RevervationService{ public Receipt reservation(List tickets) { for (Ticket ticket : tickets) { if(ticket.getMovieType == MovieType.WEEKEND) { } else if(movieType == MovieType.WEEKDAY) { ``` } else { ``` } } } } 이..

객체지향 설계를 접하다보면 흔히들 하는 이야기가 결합도가 낮고 응집성이 높고 캡슐화가 잘되어 있어야 한다고 한다 하지만 이런 전통적인 관점에서 응집도, 결합도, 캡슐화와 실무적인 응집도, 결합도, 캡슐화는 매우 다르다고 한다. 전통적인 관점 응집도 모듈 내부 요소들이 서로 관련이 있는 정도 모듈 내부의 기능적인 집중도 응집도가 높거나 낮다로 표현하며 좋은 설계는 응집도가 높다 결합도 한 모듈이 다른 모듈에 의존하는 정도 한 모듈이 다른 모듈에 대해 알고 있는 지식의 양 결합도가 강하다/느슨하다고 표현하며 좋은 설계는 결합도가 느슨하다. 캡슐화 상태와 행동을 함께 모음 데이터를 감추고 공용 메서드를 외부의 공개 이러한 전통적인 관점에서 응집도, 결합도, 캡슐화는 설계하는데 있어서 도움이 되긴 어렵다. 코드..

오브젝트 세미나 참여 이유? 요즘 클린 코드책과 소프트웨어 장인을 읽으면서 비록 개발팀 규모는 작지만 우리도 이러한 좋은 품질의 코드를 추구하고 변경되기 전보다 변경된 후가 더 깔끔해진 코드를 보고 작은 성공을 경험하고 성장한다는 것을 전파하고 싶었다. 그렇기에 내가 먼저 바뀌어야 했고 어제보다 더 발전해야했다. 그러다 우연히 개발자 커뮤니티에서 객체지향의 사실과 오해, 오브젝트를 집필하신 조영호 개발자님이 디어코퍼레이션에서 세미나를 여신다는 것을 보게 되었고 참여하게 되었습니다. 도메인이란? 입사를 하고 인수인계를 하게 되면 가장 먼저하는 것이 도메인에 대한 이해이다. 개발지식 만큼 가장 중요하게 생각하는 것이 도메인에 대한 지식이다. 조영호님은 이것을 실무적인 관점으로 간단하게 요약했는데 오프라인에서..