Kim-Baek 개발자 이야기

디자인 패턴 중, 비지터 패턴에 대해서 강의를 듣고 정리해보았다. 위의 다이어그램이 비지터 패턴의 다이어그램이다. 중요한 것은 Element( 자료구조 ) 는 변화하지 않는다는 것과 vistor ( 서비스 로직 ) 가 추가되는 기능을 가진다는 것이다. 비지터 패턴은 일반적으로 프로그래밍을 하는 과정에서 생각하는 것과는 약간 다른데, 아래와 같다고 보면 된다. 일반적 : 방문자는 “구매” 라는 기능을 가지고 가게에 간다. 버거킹에 가면 “햄버거”를 사고, 피자헛에 가면 “피자"를 산다. 비지터패턴 : 가게에 방문자가 들어간다. 가게가 방문자에게 자신의 정보를 주고, 방문자는 정보에 따라 “버거킹의 햄버거 구매”, “피자헛의 피자 구매” 라는 기능을 호출한다. 코드 예시를 통해서 살펴보도록 하자. 비지터 패..

자바의 컬렉션은 가변이다. 이 때문에 발생하는 문제를 먼저 살펴본다 6.1 package travelator; public class Suffering { public static int sufferScoreFor(List route) { Location start = getDepartsFrom(route); List longestJourneys = longestJourneysIn(route, 3); return sufferScore(longestJourneys, start); } } start 가 별게 없어서 인라인 한다. (6.2) 6.2 public static int sufferScoreFor(List route) { List longestJourneys = longestJourneysIn(rou..

POJO? Plain Old Java Object public class CoffeePOJO { public String name; private List ingredients; public CoffeePOJO(String name, List ingredients) { this.name = name; this.ingredients = ingredients; } void addIngredient(String ingredient) { ingredients.add(ingredient); } } 자바 빈(Java Bean) 공식 자바 빈 문서에 따르면 자바 빈은 아래의 조건을 모두 충족하는 POJO이다. (DTO라고도 한다함) 모든 객체 변수는 Private 제한자를 가지며 getter 와 setter 함수를 ..

함수형 프로그래밍의 핵심은 바로 람다 계산법이다. 람다 계산법은 프로그래밍보다 먼저 등장한 개념인데, 어떤 것인지 사례를 보면서 살펴보도록 하자. 정수를 제곱하기 public class Squint { public static void main(String args[]){ for(int i = 0; i { int i = 0; while (!stopRequested) i++; }); backgroundThread.start(); TimeUnit.SECONDS.sleep(1); stopRequested = true; } } 이 코드는 backgrounThread 가 실행된 후, 1초뒤에 정지될 것으로 보이는 코드이다. 하지만 실제 동작은 그렇게 되지 않을 수 있다. CPU1 이 backgroundThread..

객체지향이란 무엇일까? 면접에서 자주 물어보는 질문이기도 하다. "데이터와 함수의 조합" 이라고 말하는 사람도 있고, "실제 세계를 모델링하는 새로운 방법"이라고 대답하는 사람도 있다고 한다. 하지만 두 개 모두 만족스러운 답변이라고는 하지 않는다. 캡슐화, 상속, 다형성을 통해서 설명하는 사람들도 있는데 그렇다면 이 세 가지 개념이 어떤 것인지 한번 살펴보도록 하자. 캡슐화 데이터를 응집력 있게 구성하고, 구분선 바깥에 데이터는 숨겨지고, 일부함수만 외부에 노출되는 것을 말한다. 객체 지향 언어에서는 private, public 등을 통해서 이를 표현한다. 하지만 객체 지향에서만 해당 개념이 있는 것이 아니다. c언어에서의 사용하는 방법인데, point.c로 구현을 하고, point.h 파일로 해당 기..

구조적 프로그래밍의 발견 구조적 프로그래밍은 1960년대 네덜란드의 데이크스트라라른 프로그래머에 의해서 발견되었다. 이 때 프로그래밍은 진공관으로 이루어진 컴퓨터로 하던 시기였는데, 컴퓨터가 거대하고, 쉽게 손상되고 느리고 결과까지 믿을 수 없는 상태였다. 데이크스트라는 프로그래밍이 어렵고, 프로그래머가 프로그래밍을 잘하지 못한다는 문제를 인식했다. 그래서 조그만 세부사항이라도 간과하면 프로그램이 정상동작하지 않는 것을 볼 수 있었다. 데이크스트라는 프로그래머가 작성한 코드가 올바르게 동작하기를 원했고, 코드가 올바르게 동작한다는 사실을 수학적인 원리를 적용해서 풀려고했다. 수학적 증명 자세한 수학적인 기법은 설명하지 않지만, 예전에 배웠던 수학적 귀납법이 기억나는가? p(1)이 참이고, P(n)이 참이..

클린 아키텍처의 챕터2는 프로그래밍 패러다임이다. 3장부터 시작해서 6장까지가 해당 내용에 속한다. 가장 먼저 3장인 패러다임 개요에서는 프로그래밍 패러다임 3가지에 대해서 간략하게 설명한다. 구조적 프로그래밍 객체 지향 프로그래밍 함수형 프로그래밍 개발자라면 세 가지 모두 익숙하게 들어봤을 것이다. 구조적 프로그래밍 대학교에서 처음 C언어를 배우면서 절차 지향프로그래밍이다라고 배웠던 기억이 있다. 구조적 패러다임은 최초로 적용된 프로그래밍이고, 데이크스트라에 의해서 발견된다. 데이크스트라는 무분별한 점프 ( goto 문장 ) 이 프로그램 구조에 해롭고, 이는 다른 if/then/else 나 do/while/until 로 대체할 수 있다고 한다. 구조적 프로그래밍은 제어흐름의 직접적인 전환( goto )..

이전에 본 1장과 이번에 보는 2장까지는 왜 클린 아키텍쳐가 중요한지를 알려주는 대목이라고 생각하고 편하게 보면된다. 소프트웨어 시스템이 이해관계자에게 두 가지 가치를 제공하는 데, 그것에 대한 설명을 하고 있다. 1. 행위 행위란 말그대로 프로그래머가 제품을 만들어서 어떠한 기능을 하도록 하게 하는 것이다. 이것을 통해서 기계가 수익을 창출하거나 기존에 사용하던 비용을 절약하는 것을 목표로 한다. 많은 사람들이 이것이 프로그래머게 해야할 일의 전부라고 생각한다. 2. 아키텍처 소프트웨어라는 뜻을 한번 살펴보자. "Soft"는 부드럽다는 것이고, "ware"는 제품이다. 소프트웨어는 부드러운 제품, 즉 변경하기 쉬운 제품이라는 것이다. 그렇기 때문에 소프트웨어에 대한 변경사항이 생기면 간단하고 쉽게 적용..

개발자에게 중요한 능력은 무엇일까라는 고민을 많이 하게된다. 신기술을 빠르게 배우고 적용하는 능력, 누구보다 빨리 코딩을 하는 능력 등 여러가지 가 있을 수 있겠다. 회사에서 일을 하다 보니, 여러 사람이 봐도 이해할 수 있는 코드를 짜는 것이 정말 중요한 능력이 아닐까? 라는 생각이 많이 든다. 그래서 해당 능력을 기르기 위해 클린아키텍처라는 책을 읽으면서 스터디를 진행하게 되었다. 1장 - 설계와 아키텍처란? 아키텍쳐는 고수준의 무언가 설계는 저수준의 무엇인가라고 생각하기 쉽지만, 둘은 아무런 차이가 없다고 한다. 중요한 것은 이것의 목표이다. 소프트웨어 아키택쳐의 목표는 필요한 시스템을 만들고 유지보수하는데 투입되는 인력을 최소화하는 데 있다. 좋은 설계로 만들어진 소프트웨어는 많은 사람이 없어도 ..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에는 컨테이너에 등록된 모든 빈을 조회해보았다. 이번에는 하나의 빈을 조회하는 방법들에 대해서 기본적으로 사용되는 방식들에 대해서 알아볼 수 있도록 하겠다. 먼저 이전과 동일하게 스프링 컨테이너인 ApplicationContext의 구현체를 만들어서 빈을 가져오게 된다. 줄여서 ac 라고 사용할 수 있도록 하겠다. ac 에서 빈을 가져오는 메소드에 대해서 알아보겠다. ac.getBean ( 빈이름, 타입 ) ac.getBean ( 타입 ) 위의 두 가지 방식으로 빈을 가져올 수 있는데, 상황에 맞게 본인이 필요한 것을 쓰면 되겠다. 그런데 조회 대상의 스프링 빈이 없으면 어떻게 될까? NoSuchBeanDefin..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에 스프링을 사용해서 빈을 어떻게 등록하는지 알게되었습니다. 실제로 등록이 되었다고는 하는데, 정말 등록이 된게 맞는지 직접 확인을 해볼 필요가 있습니다. 그래서 컨테이너에 등록된 빈을 한번 조회해보도록 하겠습니다. package core.order.beanfind; import core.order.AppConfig; import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.Test; import org.springframework.beans.factory.config.BeanDefinition; import org.springframework..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이전에 AppConfig를 스프링으로 전환하는 과정을 진행했다. 스프링 컨테이너가 이제 그 역할을 해주는 것이라고 설명을 하였는데, 이번에는 스프링 컨테이너가 생성되는 과정을 한번 살펴보고자 한다. ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext 를 우리는 스프링 컨테이너라고 한다. ApplicationContext 는 인터페이스이다. 그 말은 여러가지 구현체를 사용할 수 있다는 뜻이다. 스프링 컨테이너는 XML을 기반으로 할 수도 있고, 애노테이션 기반의 자바..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지금까지 강의의 내용은 순수하게 자바만 사용해서 하는 것이였다. 그렇다면 스프링을 사용하면 어떤 좋은 점이 있는지를 알아야 하지 않을까? 이번부터 지금까지 생성한 내용을 스프링으로 변경하면서 진행을 하게 된다. 먼저 AppConfig를 스프링 기반으로 변경한다. package core.order; import core.order.discount.DiscountPolicy; import core.order.discount.RateDiscountPolicy; import core.order.member.MemberRepository; import core.order.member.MemberService; import co..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이번에는 IoC와 DI, 컨테이너에 대해서 설명을 한다. 스프링을 하는 사람들은 다들 많이 들어본 내용일텐데, IoC, DI, AOP까지 해서 스프링 관련된 중요한 개념이라고 생각된다. 어려운 내용은 아니고 지금까지 우리가 강의를 통해서 해왔던 내용들이 다 여기에 담겨있어서 어떤 내용들과 매칭되는지 다시한번 기억을 되살려서 살펴보도록 하자. 제어의 역전 IoC ( Inversion of Control ) 우선 제어의 역전을 알아보기 전에 기존 프로그램의 동작과정을 살펴보도록 하자 클라이언트가 필요한 서버 구현 객체를 생성하고, 연결하고 실행했다. 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 일반적으로 이게 개..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지금까지 만들어오면서 적용한 객체 지향 설계의 원칙에 대해서 살펴보고자 한다. 객체 지향 설계의 5가지 원칙은 이전에 작성한 글에도 잘 정리가 되어있으니 생각이 나지 않는다면 해당 내용을 다시한번 보는 것을 권장한다. 1. SRP ( 단일 책임 원칙 ) - 한 클래스는 하나의 책임만 가져야 한다는 원칙이다. 우리가 처음에 만들었던 클라이언트 객체는 직접 구현 객체를 생성하고, 연결하고 실행까지 하는 다양한 첵임을 가지고 있었다. SRP 원칙에 따라서 관심사를 분리하게 된다. 더 이상 클라이언트는 구현 객체를 생성하거나 연결하지 않고, AppConfig 가 해당 역할을 담당하게 된다 클라이언트 객체는 실행하는 책임만 담..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이제는 이전에 해보려고 했었던 할인 정책을 변경을 해보고자 한다. 기존에는 정액 할인 정책을 사용하여 어떤 주문이 들어오더라도 1000원만큼만 할인이 이루어졌다. 바꾸려고 하는 것은 정률 할인 정책으로 주문가격의 10%를 할인해주는 정책이다. FixDiscountPolicy -> RateDiscountPolicy 로 변경을 하게 되는데 이제 어떤 부분을 바꿔주면 되는지 살펴보자. 우리는 AppConfig를 만들게 되면서 애플리케이션이 실제 로직이 수행되는 사용 영역과 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. 현재 애플리케이션의 구조는 이와 같은 상태라고 할 수 있다. 그렇다면 할인정책은..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에 AppConfig를 만들어서 관심사를 분리해서, 각자 역할들이 본인들의 역할의 수행에만 집중할 수 있는 코드를 완성했다. 그런데 다시한번 보면 AppConfig가 중복이 있고, 역할에 따른 구현이 잘 안보이는 문제가 있다. 우리가 원하는 그림은 이런 것 일 것이다. 역할이 있고 구현 객체들이 어떤 것인지 명확하게 보이는 그림이다. package core.order; import core.order.discount.FixDiscountPolicy; import core.order.member.MemberService; import core.order.member.MemberServiceImpl; import c..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 다시 처음으로 돌아가서 한번 생각을 해보자. 공연에서 각각 인터페이스는 배역이라고 할 수 있다. 그렇다면 이 배역을 연기하는 배우는 누가 선택을 하게 되는게 맞을까? 현재까지 작성한 코드는 로미오와 줄리엣이라는 공연에서, 로미오 역할을 하는 배우인 레오나르도 디카프리오 ( 구현체, 배우 ) 가 줄리엣 역할을 하는 여자 주인공 ( 구현체, 배우 )를 직접 캐스팅하는 것과 마찬가지인 내용이다. 디카프리오는 직접 공연도 하고, 여자 주인공도 캐스팅하는 다양한 역할을 하고 있는 셈이다. 관심사의 분리 - 배우는 자신이 맡은 배역을 수행하는 역할만 수행하는 데 집중하는 것이 맞다. - 디카프리오는 상대 여자 주인공이 어떤 사람..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에 새로운 할인 정책을 만들어서 테스트까지 했으니 이제 실제 코드에 적용을 해보는 시간이다. public class OrderServiceImpl implements OrderService { // private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); } FixDicountPolicy를 RateDiscountPolicy 를 위와같이 적용하면 된다. 이 코드는 어떤 상태라고 생각이 될까? 역할과 구현을 분리한 것은 ..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지금까지 할인 정책은 얼마를 주문하던 1000원을 할인해주는 정액 할인 정책이였다. 하지만 맨 처음 기획을 보면 이 정책은 언제든지 바뀔 수 있는 것이였다. 기획자가 이제 1000원이 아니라 주문 금액의 10%를 할인해주는 정률 할인 정책으로 변경해달라는 요구가 들어왔다. 그렇다면 개발자인 우리는 이것을 변경해서 적용해볼 수 있도록 하자 . 기획자는 애자일 소프트웨어 개발 선언에 따라서 계획을 따르기보다는 변화에 대응하라는 말을 한다. 열받는 말이지만 우리도 이 말에 맞게 대응을 해볼 수 있도로 한다. package core.order.discount; import core.order.member.Grade; impo..