이제 마지막이다.! 최근 부터 제목 짓는게 어려워서 그냥 목차를 사용하고 있다. 경로 표현식 이것을 이해 하기 위해 잠시 sql을 작성해보자. select * from A; 대충 이런 sql이 존재한다고 가정하자. 이것을 JPQL로 바꾼다면 select m from A m 이런식으로 수정할 수 있다. 여기서 m이 경로 표현식이다. m은 * 즉 와일드 카드로 대체가 되어진다. 그 말은 이것은 엔티티라는 뜻이 된다. 그럼 결국은 m다음에 나올 수 있는 값들이 어떤것이 있을까? 엔티티는 다음으로 준비하였다. @Id @GeneratedValue private Long id; private String server; private String name; @OneToMany(mappedBy = "school", f..
"한빛미디어 활동을 위해서 책을 제공받아 작성된 서평입니다." 지금 으로부터 약 9년전 나는 프로그래밍 보다 네트워크를 더 좋아했었다. 네트워크를 더 좋아했었던 이유는 프로그래밍이 마냥 어렵다고 느꼈고 또, 그 때 네트워크를 가르쳤던 교수님께서 정말 잘 가르쳐줬기 때문에 네트워크를 더 좋아했었다. 그 당시에 가장 유명했던(?) 네트워크 서적인 후니의 쉽게 쓴 시스코 네트워킹이라는 책을 재미있게 읽었던 기억이 아직도 생생하다. (지금 확인해보니 개정판이 4판이 나온것 같다. 이름도 바뀌고) 뭐 어쩌다 보니 네트워크보다는 프로그래밍을 더 좋아하게 되어서 네트워킹 공부를 깊게 하지 않았었는데 우연히 이 책을 리뷰를 하게 되어 영광으로 생각합니다. 약간은 지루할 수 도 있지만 1장에서는 네트워크에 대한 배경 지..
지금까지 JPA를 학습하면서 어떻게 쿼리를 이용할 수 있는지에 대해 학습했다. 근데 의문이 생겼다. 의문의 정체는 바로 조인이다. 물론 JPA자체에서도 조인을 제공하지 않는것은 아니다. 엔티티로만으로도 조인만을 사용하는 것은 가능하다. 하지만 조건문이 들어간 조인도 가능할까? 가능할 수 도 있겠지만 내가 알기로는 불가능한걸로 알고 있다. 예를들어 다음과 같이 학교와 학생이 존재한다고 가정해보자. @Entity public class School { @Id @GeneratedValue private Long id; private String name; @OneToMany(mappedBy = "school", fetch = FetchType.LAZY) private List students = new Arr..
자바를 학습을 하게 되면 늘 기본적으로 primitive를 학습하게 된다. 이들의 특징은 공유 대신에 복사를 이용한다는 점인데 이 점때문에 안전한 코딩을 할 수 있다고 한다. 예를들어 int a = 3; int b = a; b = 5; System.out.println(a); System.out.println(b); 이런코드가 존재할때 a와 b가 서로 다르다는 것을 알 수 있다. 이점은 복사가 이뤄졌기 때문이라고 한다. 하지만 이것을 객체로 작성하게 된다면 얘기가 달라진다. 객체를 이용하게 되면 값을 복사하는 것이 아니라 주소값을 복사해온다는 점이 달라진다. 이게 위에서 말한 공유인데 위 코드를 다시 작성하면 Integer a = 3; Integer b = a; b = 5; System.out.print..
퍼사드는 사실 불어다. 건물 외각이라는 뜻을 가졌다. 퀴즈를 하나 낼 태니 한번 맞춰보시길 이 회사에는 현재 몇명의 개발자가 일하고 있는가? (어디든 앉아서 일하고 있는 사람만) 이 회사는 어떤 회사일까? 첫 번째 질문 같은 경우는 즉, 화장실에 갔던가 휴가 중인 인원 등을 제외하라는 뜻이다. 아마 100%확률로 틀릴 것이다. 심지어 이 회사를 다니고 있는 사람들 모두 이 문제를 틀릴 것이다. 왜냐하면 화장실를 간 사람들을 일일이 세면서 이 문제를 맞출 이유는 없기 때문이다. 아니 애초에 말도 안되는 문제이기 때문이다. 어떻게 외각만을 보고 문제를 맞춘다는 건 말이 되지 않기 때문이다. 하지만 두 번째 질문은 대답이 가능하다. 이런식으로 외부 코드만 확인해서 외부 코드만 보고서 어떤 동작을 하는지 대략적..
프록시 프록시란 과연 무엇일까? JPA에서 프록시를 이용한다고 하는데 도대체 어디에서 이용을 하는 걸까? 들어가기전에 프록시에 대해 간략하게 소개하면 프록시의 역할은 총 2가지로 구분이 되어진다. 1. 대리 기능 2. 추가 기능 대리 기능은 우리가 흔히 아는 캐싱 기능이고 추가 기능은 부가적인 기능을 추가할 수 있는 기능이다. 과연 JPA는 언제 프록시 기능을 사용하는 것일까? 내가 생각할때는 대리 기능을 사용하는 것으로 생각이 들어진다. 그 이유는 추후에 얘기를 해보자. 그전에 GOF의 디자인 패턴을 살펴보는 것이 좋을 것 같다. 왜냐하면 프록시를 설명하고 있는 패턴이 존재하기 때문이다. 디자인 패턴 중 프록시 패턴과 데코레이터 패턴이 프록시 역할을 한다고 한다. 근데 이상하다 프록시 패턴은 그려려니 ..
ㅁ오랜만에 JPA 포스팅 JPA는 데이터베이스를 객체지향으로 표현한 ORM이라고 알고 있다. 그렇다는 소리는 객체지향 처럼 상속을 제공한다는 뜻이 된다. 일반적으로 상속은 extends를 사용하게 되어진다. 간단하게 코드를 작성해봤다. @Entity public abstract class School { @Id @GeneratedValue private Long id; private String name; } @Entity public class HighSchool extends School {} 이렇게 작성하고 나서 SQL를 확인했다. create table School ( DTYPE varchar(31) not null, id int8 not null, name varchar(255), primary..
디자인 패턴을 공부하면서 놓쳐서면 안되는 사실은 절대로 코드로 학습을 하면 안된다는 사실이다. 나는 브릿지 패턴을 공부하면서 이에 더 실감했다. 물론, 코드 자체도 디자인 패턴이지만 사실 그것 보다 중요한 건 어떻게 그 코드를 작성했는가가 중요하다. 인터페이스를 사용하고 클래스를 사용하는 건 그렇게 까지 중요한건 아니다. 아무튼 지금 내가 작성 하는 부분은 브릿지 패턴이다. 브릿지는 다리라는 뜻이다. 즉, 코드 상에서 다리를 내려줘야 하는데 어떤걸로 하는 것이 유리할까? 클래스로 해도 상관없고 인터페이스로 해도 상관없다. UML을 보면 인터페이스로 되어있는데 이는 사실 인터페이스 interface 이게 아니다. 그냥 추상적으로 표현 할 수 있다는 뜻이다. 저번 포스팅에서 전략 패턴에 대해 공부하였다. 전..
이 패턴 생각보다 쉽지 않다. 패턴에 대해 간략하게 설명하면 전략을 구분짓는 패턴이다. 당연한 이야기 지만 이런이야기는 누구나 할 수 있다. 그러면 다음 코드를 보고 이것이 어떤 패턴인 맞출 수 있을까? Template template = new Template(new Action()); 지금까지 학습한 팩토리, 추상 팩토리, 빌링, 프로토 패턴인데 이것만 봐도 아쉽게도 전략패턴인지 확신을 가질 수 없다. 이는 저번 포스트에서 말했듯이 관점에 따라 패턴의 이름이 달라질 수 있다. 디자인 패턴을 공부하면서 빌더 패턴 처럼 딱 떨어지는 패턴이 있는 반면에 대부분 패턴들은 딱 떨어지지 않는다는 사실을 알 수 있다. 누군가가 위 코드는 추상 팩토리 패턴이라고 말한다면, 틀린것일까? 지금은 추상 팩토리와 전략 패..
디자인 패턴을 공부하면서 하나씩 공부할때는 생각보다 쉬운데 여러개를 동시에 공부하거나 다른 패턴을 공부를 해야 되는 상황이라면 헷갈리는 경우가 굉장히 많았다. 디자인 패턴에서는 이러한 양상이 종종 발생이 되며, 대표적으로 팩토리 메소드 패턴이랑 추상 팩토리 패턴이 존재한다. 이렇게 비슷한 패턴들이 많은 이유는 관점때문이라고 한다. 그러면 이 두개의 패턴은 어떻게 관점이 다른지 확인해보자. 어떻게 보면 두 개모두 팩토리 즉, 공장에서 무언가를 만드는 듯한 느낌을 준다. 그러면 뭐가 다른 걸까? 이름 부터 이 두가지 패턴은 다르다는 느낌을 강력하게 받는다. 처음에 팩토리 패턴을 생각했을 때, 인터페이스 또는 추상 클래스를 통해 만든것을 직접적으로 사용한다고 생각했다. 물론, 이게 맞을 수 있겠지만, 이 접근..
싱글톤 패턴은 내가 생각하기에 가장 만들기 쉬우면서 가장 위험한? 패턴이라 생각이 든다. 원래 블로그를 작성하지 않고 머릿속에 정리할 생각이 었지만 아무리 생각해도 답이 나오지 않다는 생각에 이렇게 작성하게 되었다. 일단 싱글톤 패턴이 무엇인지 부터 생각 해야 된다. 싱글톤 패턴은 싱글, 즉 객체가 하나로 나오는 패턴이다. 우리가 알기로는 일반적으로 객체는 생성할때마다 다른 객체가 나오는 것이 당연한이야기다. 다시말해 사람이라는 클래스가 존재한다면, 각자 다른 사람인것 처럼 객체도 마찬가지로 생성할때마다 다르게 나오는게 정상이다. 싱글톤 패턴은 이 정상적인 행동을 제약하는 패턴이라 생각이 든다. 위에서 언급했듯이 싱글톤 패턴을 이용하게 되면 아무리 객체를 많이 만들어도 같은 객체가 나온다는 뜻이다. 근데..
JPA에서 공부하면서 곰곰히 생각해봤다. 내가 과연 어떻게 테이블을 작성했는지... 또, 마이바티스를 어떻게 이용했는지 생각해봤다. 1년전에 보이지 않는 내용들이 점차 눈에 들어오기 시작했다. 가장 눈에 띄이는건 JOIN관계다. 애초에 테이블을 만들때 JOIN을 사용하지 않는다. SQL은 반드시 외래키를 사용해야 된다는 제약 사항이 전혀 없다. 오히려 외래키를 사용하지 않고 DB를 구축하기도 한다. 그래서 JOIN문을 사용할때 외래키를 사용하지 않고 쿼리 작성하는것이 가능하다. 신기하게도? JPA는 JOIN문을 쿼리 생성하기 전에 미리 만들어 둔다. 무조건 JOIN문을 사용해야 되는것은 아니지만, 이러한 점이 SQL을 작성할때와의 차이점이라 생각이 든다. 그렇다면 어째서 JPA는 이러한 전략을 택했을까?..