덕토피아

프로그래밍에서 공통적인 문제를 쉽게 해결하기 위해 만들어진 가이드라인을 디자인 패턴(Design Pattern)이라고 합니다. 라이브러리처럼 실제 코드를 제공하지는 않지만, 특정 유형의 문제를 해결하는 방식을 제공합니다. 수학으로 비유해 보자면 '공식'이죠. 프로그래밍 전문가들의 땀과 눈물로 만들어진 결과물이라고 할 수 있겠습니다. 디자인 패턴으로 잘 알려진 감마 외 3인(Gang of Four, GoF)이 쓴 디자인 패턴 책에서는 23가지 기본 디자인 패턴을 소개하고 있습니다. 그러나 이번 포스팅에서는 주로 사용되는 싱글톤, 빌더, 옵저버 패턴에 대해 알아보겠습니다. 왜 디자인 패턴이 필요한가? 1. 재사용성: 디자인 패턴을 사용함으로써 개발자는 문제가 발생할 때마다 코드를 다시 구현하는 대신 기존 솔..

스프링 프로젝트를 진행하다 보면, 우연히 두 개 이상의 빈(bean) 타입이 중복되는 경우가 발생할 수 있습니다. 이런 경우에는 NoUniqueBeanDefinitionException 에러가 발생하여 어떠한 빈이 중복되었는지 알려줍니다. ! 문제 상황 발생 ! 그렇다면, 해당 에러가 발생했을 때는 어떠한 해결책이 있을까요? 우선 문제가 발생하는 상황의 예시를 봅시다. 같은 타입의 이름이 다른 두 개의 빈을 등록하였습니다. 등록할 때는 문제가 되지 않습니다. 에러가 발생하는 것은 실제로 해당 타입의 빈이 사용이 될 때입니다. 다음 예제를 볼까요? 스프링 부트 입장에서는 참 난감합니다. 같은 타입의 빈이 두 개가 있는데, 어떤 의존성을 주입하라는 건지 알 수가 없습니다. 불쌍한 스프링 부트를 위해 이 에러..

다 사용하고 난 자원을 반납하기 위해서 어떤 방법을 채택하시나요? 혹시, try-catch-finally 구문을 사용하지는 않으신가요? 맞다면, 축하드립니다! 더 간편한 방법을 사용할 수 있는 기회를 잡으셨습니다! try-catch-finally를 사용한다면 사용 후에 반납해야 하는 자원들은, 대부분 close 형태의 메서드를 가지고 있습니다. 사용 후에 자원을 해제하지 않는다면, 메모리 누수 및 성능 저하의 문제를 일으킬 수 있기 때문에 프로그램이 예상과 다르게 작동할 수 있습니다. 그렇다면 이제, 흔히 사용하는 try-catch-finally 형태의 자원 해제 예시를 살펴볼까요? 어떤가요? 꽤 괜찮아 보이지 않나요? 예외 처리가 발생하든 안하든 상관 없이 항상 자원을 해제할 수 있으니, 나쁘지 않아 ..

http://www.yes24.com/Product/Goods/18249021 『객체지향의 사실과 오해』는 객체지향이란 무엇인가라는 원론적면서도 다소 위험한 질문에 답하기 위해 쓰여진 책이다. 안타깝게도 많은 사람들이 객체지향의 본질을 오해하고 있다. 가장 널리 퍼져있는 오해는 클래스가 객체지향 프로그래밍의 중심이라는 것이다. 객체지향으로 향하는 첫 걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 이 책은 많은 사람들이 객체지향에 대한 오해를 하고 있다고 말하면서 시작합니다. 가장 널리 퍼져있는 오해는, 클래스가 객체지향의 중심이라는 것입니다. 객체지향은 클래스, 그리고 그것을 구현한 인스턴스로 이루어져 있던 게 아니었던 걸까요? 그렇다면 왜 그토록 수많은 문서와 책들은 클래스와 인스턴스로 ..

자바로 코딩을 하다 보면, 가끔 "Raw type을 사용하지 마라"라는 조언을 듣습니다. 실제로 Effective Java에서도 언급합니다. 그렇다면 Raw type은 무엇이고, 왜 사용하지 않는 것이 좋을까요? Raw type에 대해 알아보려면 우선 Generic type이 무엇인지 알아야합니다. Generic type 이란? Generic 이란 generalize(일반화하다)를 변형시킨 단어로 보입니다. 그래서 '데이터의 타입을 일반화하다' 로 뜻을 유추할 수 있습니다. 클래스와 인터페이스, 메서드를 정의할 때 타입을 지정하지 않고 파라미터로 사용할 수 있게 만듭니다. 이해가 안 된다면 아래 예시를 봅시다. 같은 Box 클래스를 사용하고 있지만, String, Integer, Boolean의 다양한 ..

http://www.yes24.com/Product/Goods/109366833 구글 엔지니어가 말하는 좋은 코드 작성법 좋은 코드를 작성하기 위한 이론과 실전을 소개한다. 단순히 해야 할 일과 하지 말아야 할 일을 나열하기보다, 여섯 가지 원칙을 바탕으로 각 개념과 기술의 장단점, 그리고 이면의 핵심 논리를 설명한다. 책에서 설명하는 즉시 사용 가능한 수십 가지의 기술을 익힌다면, 숙련된 프로그래머의 사고법과 코드 작성의 노하우를 이해할 수 있다. 효과적인 테스트 방법도 설명하므로 더 나은 코드를 작성하는 데 도움을 줄 것이다. 좋은 코드 작성법에 대한 것을 소개합니다. 총 3부로 이루어져 있으며, 각각은 다음과 같습니다. 1부: 소프트웨어 엔지니어로서 코드를 작성하는 우리의 접근 방식을 형성하는 일반..

http://www.yes24.com/Product/Goods/97584812 개발자가 코딩만 잘하면 된다? 고객의 요구사항 분석을 제대로 글로 옮기지 못한다면 무슨 일이 발생할까? 장애 발생 시 공지문을 작성해야 하는데, 빠짐없이 정확하게 작성할 수 있을까? 오류와 확인 메시지는 제대로 쓸 수 있을까? UI에 들어가는 텍스트는? 소프트웨어 제품 출시 후 사용자 가이드는 어떻게 만들어야 할까? 개발자는 코딩 영역 외에도 이렇게 수많은 글쓰기 문제에 직면한다. 이를 위해 저자는 테크니컬 라이터로서 20년 이상 개발자와 함께하며 얻는 핵심 노하우를 이 책 한 권에 정리하였다. 옆에 두고 항상 참고할 수 있는 개발자만을 위한 글쓰기 가이드이다. 테크니컬 글을 작성하고 싶다면, 도움이 될 책입니다. 글을 자주 ..

참 다사다난한 한 해였습니다. 회고 포스팅을 12월 초부터 계획하였는데, 정말 달의 끝의 끝까지 가서야 쓰게 되었네요. 저의 미루기 스킬에 또 한 번 찬사를 보냅니다. (_ _) 회고 글은 처음 작성해 봅니다. 습관이 되어서 매 년 작성을 할 수 있게 되면 좋겠네요. 많은 분들의 회고 포스팅과 퍼블리의 회고 템플릿을 참고하였는데, 카테고리 별로 글을 작성해 보려고 합니다. 좋았던 점은 파란색으로, 아쉬웠던 점은 빨간색으로 표시하였습니다. [일과 커리어] 원하는 회사에 이직하기 올해의 가장 큰 사건 중 하나가 아니었을까요? 여러 가지 이유로 정든 회사를 떠나서 새 회사로 가게 되었고, 6개월이라는 길다면 길고 짧다면 짧은 기간 동안 적응하느라 정신없이 보냈었습니다. 그래서 깃허브 잔디 관리라던지 포스팅에 ..

5월에 시작한 글또가 벌써 마지막 글 제출일이 다 되었네요. 그래서 오늘은 글또 7기를 겪으면서 이루었던 점, 아쉬웠던 점, 그리고 앞으로 이룰 것을 간략하게 적어보도록 하겠습니다. 글또 7기를 참여하면서 글또 7기에 참여한 동기는 다음과 같습니다. 글또 7기 다짐글 에서 볼 수 있습니다. 나태한 나를 채찍질 하면서 초심을 되찾기 위하여 다른 많은 개발자 분들과 좋은 관계를 구축하기 위해 우선 1번 항목을 달성했는지 본다면, 초심까지는 아니지만 그래도 미제출 없이 약 5개월을 잘 달려온 것 같습니다. 사실 여기서만 얘기하는 건데, 처음에는 “한 번도 PASS권 사용하지 않고 달려봐야지!”란 거대한 다짐을 가지고 시작하였습니다. 그런데 결과는…(PASS 2회권 모두 사용). 꾸준히 글 쓰시는 분들 정말 모..

Spring Boot를 사용하면 대부분 사람들이 가장 먼저 배우는 MVC 패턴! 가장 기초적인 패턴이라 인터뷰 질문에 많이 나오기도 합니다. 오늘은 그 MVC 패턴에 대해서 알아보도록 하겠습니다. MVC 패턴의 구조 동작 방식은 간단합니다. 쉽게 설명하기 위해 학생이 과제 게시판을 보고 싶다고 가정하겠습니다. 1. 학생이 컨트롤러에게 과제 게시판 조회를 요청한다. 2. 컨트롤러는 모델에게 과제 게시판 데이터들을 달라고 요청한다. 3. 모델은 가져온 데이터들을 컨트롤러에게 전달해 준다. 4. 컨트롤러는 가져온 데이터들로 뷰를 만들어서 사용자에게 UI로 전달해준다. 여기서 나오는 컨트롤러, 모델, 뷰가 바로 MVC의 Model, View, Controller 입니다. 예시에서 파악할 수 있다시피, 모델은 데..