전체 보기 (112) 썸네일형 리스트형 Spring Boot 개발하면서 요즘 드는 생각 첫번째. 정말 많은 객체들의 동작들이 서로 연결되어 있다. 지금 하는 개발이 다른 객체들에게 어떤 영향을 주는지를 정확하게 알아야 하고, 역할을 분리해야 하고 등등.. 처음에 각 도메인들 CRUD 식으로 도메인 개발할 때야 쉬웠지만, 심화되다보면 빼먹은 비즈니스 로직, 변하는 비즈니스 로직에 따라서 이 어찌어찌 얽혀있는 것들을 계속 풀어내야 한다. 그쯤되면 앱이 더러워 보이고, 키기 무서워지고, 다시 하고 싶거나, 그만하고 싶어진다. 이럴 때 믿을건 Test 코드들 뿐인 건 공감한다. 하지만 Test 들도 언제나 프로젝트 처음 시작할 때 만든 나의 Test 는 개판이고 쓰레기라, 유지보수 덩어리로만 보인다. 이 임계지점을 넘어야 하는 것 같다. 그래야 SW 가 나오는 것 같다. 토이성 프로젝트로 만드는 .. [JPA] 연관 객체 불러오기.. Fetch Join 정말 괜찮을까? 결론부터 말하자면 약간 뻘짓한 글이다. 그래도 긍정적으로 본다면 고민을 해봤다는 의의는 있으니.. 초보자의 수준에서 한 번 고민을 공유한다고 생각하면 될 것 같다. (1) 개요 서비스단을 개발하다 고민하게 된 부분이 있어서, 정리해보면서 결론을 만들어 나가보기로 했다. 우선 개요는 다음과 같다. Group 객체가 있고, Group 활동 안에 게시물인 Post 객체가 있으며, Post 에는 댓글인 Comment 객체가 있는 다음과 같은 상황이다. 아래에는 표시되어 있지 않지만, Member 객체가 당연히 있으며, Member 와 Group 사이에는 현재 상태가 기록되고, [강퇴 / 휴면 / 활동] 의 세 가지 상태로 관리된다. 이와 같은 관계는 많이 발생하는 일반적인 상황으로, 모두 비식별 관계이다. 이 .. [Design Pattern] Structural - 브릿지 패턴 (Bridge Pattern) 브릿지 패턴은 abstract object structure 와 implementation object structure 의 계층이 분리되어 coupling 을 약화시키는 방향의 패턴이다. 여기서는 역할 Object 와 구현 Object 의 분리를 말한다기보단, 개념적은 측면으로서 역할 계층과 구현 계층을 확실하게 분리해주는 방향을 말한다. 문제 개요 위와 같은 UML 로직을 만든다고 해보자. 초기 요구사항에 맞춰서 Rectangle 을 그리기 위해서 Rectangle 을 abstract 화 하였고, 어떤 Rectangle 을 그리느냐에 따라 다른 방식으로 그릴 수 있도록 만들어줬다. public abstract class Rectangle { public void draw(){ // Rectangle .. [Design Pattern] Structural - 컴포지트 패턴 (Composite Pattern) Composite Pattern 은 한 인터페이스를 통해 Object Hierarchy 를 정의하여 생성할 수 있을 때 사용되는 패턴이다. 이 패턴을 사용하면 Tree 형태의 Hierarchical 한 구조를 표현할 수 있으며, 그렇게 표현된 Object 들을 동일한 역할체로 취급할 수 있다. 설명을 읽으면 이해가 안될 수 있는 꽤나 복잡한 패턴으로, 코드를 같이 보면서 이해해 나가길 권장한다. Composite Pattern 은 위와 같이 가상 상위 클래스를 두고, Hierarchy 상 최상단에 위치하는 Root Node 와 가상 클래스를 Inheritance 하며 Associate 하는 형태로 만들어준다. 이는 Decorator Pattern 에서도 봤던 모습이다. 그리고 abstract 상위 클래스.. [Design Pattern] Structural - 아답터 패턴 (Adapter Pattern) Adapter Pattern 은 Wrapper 라고도 불리는 패턴으로, Wrapping 과 같은 방법을 사용해서 서로 다른 일을 하게 된 두 interface 역할체들을 묶어주는 일을 해줄 때 사용하는 패턴이다. 현실에서 아답터처럼, 제공해주는 interface 를 다른 interface 와 연결해준다는 의미를 가지고 있다고 보면 된다. Adapter Pattern 에서는 Client 가 기대하고 있고 호출하는 interface 를 Target Interface 라고 한다. 아답터는 이 호출을 다른 인터페이스 측의 함수를 호출하게 되는데, 이 인터페이스는 Adaptee Interface 라고 한다. Client 는 이 Adapter 의 존재를 모른채 호출을 하기 때문에 Interface 연동성에 큰 도움.. [Design Pattern] Structural - 데코레이터 패턴 (Decorator Pattern) 데코레이이터 패턴은 이미 존재하고 있는 객체들에 대해서 dynamic wrapping 을 하여 그들의 [책임]을 변경 / 추가 하기 위해서 사용되는 패턴이다. 보통 동종 객체에서 다른 책임을 부여하기 위해서는 Inheritance 를 많이 사용하지만 Sub-Class 를 무분별하게 만들지 않고 책임지는 영역을 넓히기 위한 구조패턴이다. 해당 경우에서 각 구현체 안에서 동일한 특성들이 추가되어야 한다고 해보자. 가령, 각 커피에 휘핑크림이 들어가는지, 우유가 들어가는지, 모카가 들어가는지 등에 대한 속성들이 추가되어야 한다. 일반적으로는 Beverage 자체에 attribute 를 추가하는 방식을 생각할 것이다. 물론 틀린 것은 아니지만, 속성이 위와 같이 늘어날 때마다 계속 attribute 가 추가되는.. [Design Pattern] Creational - 싱글톤 패턴 (Singleton Pattern) 싱글톤 패턴은 매우 유명한 패턴이며, Spring 개발 경험이 있다면 매우 익숙한 디자인 패턴이다. Spring 이 자체적으로 객체를 Singleton 패턴으로 관리하는데, 이를 Bean 이라고 부르며 Bean 들을 보관하는 공간을 Singleton Container (Spring Container) 라고 부르기 때문이다. 싱글톤 패턴은 애플리케이션 내에서 단 하나의 객체만 존재하도록 보장하는 패턴이다 (사실 원하는 갯수만큼 보장이다). 따라서 인 앱 로직 객체보단, Thread Pool Manager, Caches, Logging, Factory 등 관리 측에서 여러 개가 있으면 오히려 더 SW 관리가 어려워지는 객체들에 한해서 많이 사용한다. 하지만 다음과 같은 상황들에 대해서 생각해볼 필요가 있다... [Design Pattern] Creational - 빌더 패턴 (Builder Pattern) Spring 을 통해 개발을 해본 개발자라면 너무나 익숙할 Builder 패턴이다. 빌더 패턴은 Factory Method 처럼 최종적인 Product Object 생성을 위한 Creational 패턴이며, 그 Product 을 위해 여러 Part Object 들이 조립되어 생성되는 모습이 특징이다 (Spring 에서는 @Builder 를 사용해 빌더 패턴을 적용시킬 수 있다). 빌더 패턴 같은 경우 최종적인 Product 를 위해 Builder 들이 생성하게 되는 Part Object 들은 큰 의미가 없다. 그런 부분이 Builder 라는 Interface 를 사용해 Client 가 어떤 파트들이 등장하는지 알 필요 없게 만드는 이유이다. Builder 패턴에서 최종 Build 된 Product 가 어.. [Design Pattern] Creational - 팩토리 메소드 패턴 (Factory Method Pattern) Java 기준으로 객체를 생성할 때는 new 연산자를 통해서 Class Template 을 사용하여 Object Instance 를 찍어낸다. Interface 역할체를 생성할 때는 다음과 같은 연산을 통해서 구현체를 지정하기도 한다. Pizza a = new CheesePizza(); Pizza b = new PepperoniPizza(); 이와 같은 방식은 해당 로직이 있는 클래스에서 Concrete 구현체인 CheesePizza 와 PepperoniPizza 에 대한 의존성이 발생하게 된다. 만약 의존성 없이 이를 해결할 수 있다면, 유지 보수에 훨씬 용이할 것이다. 다음과 같이 Type 을 받아서 생성만을 전담하는 Class 를 만들어보자. public class SimplePizzaFactory.. [Design Pattern] Behavioral - 중재자 패턴 (Mediator Pattern) Mediator Pattern 은 Communication 중심의 디자인 패턴으로, Communication 이 Objects 들 간에 매우 복잡하게 진행되고 있을 때 그 역할을 위임하는 방식 등의 Controller 를 도입하는 패턴이다. Communication 을 하고자 하는 Colleague 들이 1:1로 직접 하는 것이 아니라, 중앙 Control Tower (Mediator) 을 둠으로써 Meidator 객체가 지속적으로 통신을 수집 / 분배하는 역할을 하게 된다. (통신 Colleague 들이 직접 수행을 한다면 N^2 의 Path 가 발생하여 복잡성이 증대된다) 1. Object 들 간의 상호 관계성을 encapsulate 한다 2. Colleague 들 간의 Coupling 을 약화시킨다.. 이전 1 2 3 4 5 6 7 ··· 12 다음
