짱구의 개발공부 ✨

이번에는 Facade Pattern 에 대해서 알아봅시다. Facade Pattern 어떤 서브시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공. 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브시스템을 더 쉽게 사용할 수 있습니다. 이번에는 바로 디자인 원칙도 살펴보겠습니다. "최소 지식 원칙" 입니다. 객체 사이의 상호작용은 될 수 있으면 아주 가까운 사이에서만 허용하라는 원칙입니다. 퍼사드 패턴은 단순화된 인터페이스를 통해서 서브시스템을 더 쉽게 사용할 수 있도록 하기 위한 용도로 쓰입니다. 위의 예시에서 클라이언트는 HomeTheaterFacade 하나에만 상호작용을 하고 있습니다 (최소 지식 원칙) HomeTheaterFacade 는 클라이언트 대신 모든 서브시스템 구성요소를 관리해주..

다음은 함수 사용입니다. 코드를 짜다 보면 가장 많이 자바와 다른게 체감되는 부분입니다. private fun functionName(name: String, age: Int): String { } 형태를 먼저 적어봤습니다. 자바로 표현하면 아래와 같은 형태일겁니다. private String functionName(String name, int age) { } fun 이라는 키워드를 통해서 함수를 선언하고, 반환 타입의 위치도 다릅니다. 사실 여기까지의 문법만 적응된다면 나머지는 자바와 크게 다르지 않습니다. private fun functionName( name: String = "짱구", age: Int = 10 ): String { } 하지만 이런모양은 어떤가요? 매개변수의 기본값을 이렇게 할당 ..

코틀린에서의 제어문도 자바와 차이가 있는 부분입니다. 코틀린에서의 If-else 문은 그 자체로 하나의 표현식 (expression) 이 됩니다. 이는 if-else 문을 그대로 return 할 수도 있는 뜻이기도 합니다. Java에서 클린코드를 구현하다보면 else 문을 되도록 사용하지 않는 것을 권고합니다. Early return 을 통해 else 를 쓰지 않고 로직이 처리되는 것을 선호합니다. 그런데 코틀린에서는 그 자체가 하나의 표현식이라서 바로 return 문에서 활용이 가능합니다. fun getGradeWithIf(score: Int): String { return if (score >= 50) { "P" } else { "F" } } 위와 같은 표현이 가능합니다. switch-case 구문은..

코틀린을 공부해보고자 합니다. 현재 회사에서 사용하고 있는 언어이지만 학습해본적이 없어 시작해보려고 합니다. 현재 간단하게 인프런의 기본개념 강의를 들은 상태에서 지금까지 써왔던 Java 와 다른 몇가지를 먼저 작성해보고 어떻게 코틀린을 사용해서 클린코드를 만들 수 있을지 이어서 작성해보려고 합니다 :) 먼저 변수에 대한 것을 살펴보겠습니다. // 가변 var number1 = 10L // 불변 val number2 = 10L // 타입을 명시적으로 작성하지 않아도, 타입이 추론된다. // 초기값이 없으면 타입 지정해줘야함 var number3: Int val number4: Long // Long, long -> 코틀린은 연산이 필요한 경우, 알아서 primitive type 으로 변환한다. // nu..

이번에는 영속성 전이에 대해서 보겠습니다. cascade 라는 옵션으로 설정을 하게 될텐데, 먼저 "영속성 전이" 에 대한 개념부터 짚고 넘어가겠습니다. 영속성 전이라는 개념이 왜 필요한지에 대해서 이해를 하면 쉽습니다. JPA는 엔티티를 DB에 저장할 때 (flush) 영속성 컨텍스트에 엔티티가 올라가 있는 상태여야 된다는 것은 이제 알고있는 사실입니다. 그렇다면 부모 엔티티가 있고 자식 엔티티가 있다고 가정할 때, DB에 저장하고 싶으면 이들 모두가 영속 상태여야 하죠. 이런 경우에 영속성이 전이가 된다면, 다르게 표현해서 부모를 영속 상태로 만들 때 자식까지 영속 상태로 만들 수 있다면 더 편하겠죠. @Entity public class Parent { ... @OneToMany(mappedBy="..

어댑터 패턴에 대해서 알아보겠습니다. 이번에는 코드를 예제로 보여드리지는 않을건데요, 개념 자체가 어렵다고 생각되지는 않는 패턴입니다. Adapter Pattern 한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환합니다. 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있습니다. 책에서 이렇게 설명을 하고 있는데요, 그림을 보면 이해가 바로 됩니다. 흔히 저희가 해외 여행갈 때 콘센트가 안맞아서 그걸 변환하기 위해 가져가는 것도 어댑터라고 표현을 합니다. 이렇게 중간에서 모양을 맞춰주는 것을 어댑터라고 표현하고, 이것이 객체지향 코드에서는 어떤 인터페이스를 클라이언트에서 요구하는 형태의 인터페이스에 적응히켜주는 역할을 하게 됩니다...

이번에는 즉시 로딩과 지연 로딩에 대해서 이야기해보겠습니다. JPA를 처음보면 모든게 낯선 개념이지만 이 지점부터는 점점 생각할게 많아지는 영역이라고 생각합니다. 최적화와 관련이 있고 N+1 문제 등 이슈와 관련이 있는 내용입니다. 물론 나중에 작성할 내용이지만 관련이 있다는 생각을 하고, 이 주제에 대해 공부를 시작하면 도움이 된다고 생각합니다. 즉시 로딩(Eager Loading) 엔티티를 조회할 때 연관된 엔티티도 함께 조회한다. 지연 로딩(Lazy Loading) 연관된 엔티티를 실제 사용할 때 조회한다. 간단한 특징이자 정의입니다. 이름 그래도 동작하기 때문에 사실 정의라고 할 것이 없습니다. 필요할때 조회해오느냐 아니면 먼저 조회해서 가지고 있느냐 의 차이입니다. 먼저 즉시 로딩을 보겠습니다...

저번 글에 이어서 프록시에 대해서 더 알아보겠습니다. JPA에서 식별자로 엔티티를 조회할 때는 EntityManager.find() 를 사용합니다. 그런데 이렇게 조회하면 조회한 엔티티를 사용하든 사용하지 않든 데이터베이스를 조회하게 됩니다. 그런데 저번에 봤듯이 항상 연관된 객체들이 모두 필요한 것은 아니죠. EntityManager.getReference() 를 사용하면 JPA 는 데이터베이스를 조회하지 않고 실제 엔티티 객체도 생성하지 않습니다. 바로 프록시 객체를 반환하죠. 위의 그림처럼 프록시 객체를 리턴해줍니다. 본격적으로 프록시 객체가 어떤건지 알아보겠습니다. 전에 작성한 글에서 프록시 서버, 리버스 프록시 와 같은 이야기도 했는데요, 여기서 다룰 프록시는 프록시 패턴에 관련되어 있습니다. ..

연관관계를 마무리하고 프록시로 넘어가려고 합니다. 상속이나 고급매핑 등을 더 다루려고 했으나, 제 경험상으로는 JPA를 사용하면서 연관관계를 너무 복잡하게 맺으면 유지보수나 개발 측면에서 어려움이 있었습니다. OOP를 염두해두고 개발을 하다보면 안그래도 객체간의 관계에 집중을 하게되고, 어떻게 캡슐화를 시킬지 은닉할지 메시지를 주고받게 할지 많은 고민을 하게됩니다. 그런데 연관관계가 너무 복잡하면 OOP의 난이도도 너무 많이 올라간다고 생각합니다. 적당한 선에서 코드 품질을 유지하고, 꼭 필요한 매핑이 있다면 저도 그때그때 찾아가면서 개발을 하는 편입니다. 그러면 이번부터는 프록시에 대해서 알아보겠습니다. Proxy proxy 는 사전적 의미로 다른 사람을 대신 할 권한이 있는 대리인, 다른 사람을 위해..

이번에는 양방향 연관관계에서의 저장과 편의메소드를 다뤄보겠습니다. 왜 이 주제를 따로 다뤄야 하는지는 저번에 이야기 했었던 연관관계의 주인과 연관이 있습니다. 연관관계의 주인이 아닌 쪽은 읽기만 할 수 있다고 적었었는데요, 그 말은 연관관계의 주인 쪽에서 저장을 할 수 있다는 말과 같습니다. public void testSaveNonOwner() { Member memebr1 = new Member("member1", "회원 1"); em.persist(member1); Member memebr2 = new Member("member2", "회원 2"); em.persist(member2); Team team1 = new Team("team1", "팀 1"); team1.getMembers().add(m..