요약Windows가 제공하는 컨트롤을 쓰지 않고, Win32 창·메시지 루프·GDI 위에 Frame / Component / Container 계층을 직접 구현한 프로젝트입니다.그림은 WM_PAINT에서 repaint()로, 클릭은 좌표로 컴포넌트를 찾아 onClick()으로 전달합니다. 메뉴의 펼침은 자식을 그리기 목록에 넣고 빼는 방식입니다.다시 읽어 보니 기존 글의 "선 그리기", "observer 패턴 활용"은 코드와 맞지 않아 정정하고, 실제로 확인되는 한계도 함께 정리합니다.들어가며예전에 만든 프로젝트(GitHub)의 코드를 다시 읽으며 정리한 글입니다. 기존 글에 따르면 교내에서 약 2달간 진행한 프로젝트이고, 주제는 "C++과 Windows API를 이용한 그림판"이었습니다.같은 컨셉의 J..

요약Swing의 JFrame은 창 역할만 맡기고, 메뉴·툴바·버튼·패널은 KComponent 계층으로 직접 구현한 프로젝트입니다.그리기는 "컨테이너가 자식에게 paint()를 위임", 이벤트는 "좌표로 가장 깊은 자식을 찾아 전달(hit-testing)"하는 방식입니다.다시 읽어 보니 Composite / Adapter / Observer 구조로 해석되는 부분이 있고, 저장/불러오기 표기나 그룹 이동 등 실제와 다르거나 미완성인 부분도 있어 함께 정리합니다.들어가며예전에 만든 프로젝트(GitHub)의 코드를 다시 읽으며 정리한 글입니다. 이 프로젝트의 특징은 Swing 위젯(JButton, JMenu 등)을 쓰는 것이 아니라 위젯 역할을 하는 클래스를 직접 만들고 그 위에 그림판을 올렸다는 점입니다.두 ..

이전글 : [의존이란 무엇이고, 왜 인터페이스로 끊어야 하나 (1/2)]1편에서는 구체 클래스 의존이 왜 문제인지, 인터페이스로 어떻게 끊는지를 다뤘습니다. 이 글은 학습하며 정리한 예시 코드로 그 패턴을 Spring 환경에 적용해 보고, 주입 방식을 비교합니다.TL;DR결제·외부 API처럼 경계에 있는 협력 객체를 인터페이스로 감싸면, 환경별 구현 교체와 테스트가 설정만으로 가능하다.같은 인터페이스를 구현한 캐시 데코레이터로 외부 API 호출 최적화를 기존 코드 수정 없이 끼워 넣을 수 있다.주입 방식은 생성자 주입을 기본으로 하고, 세터/필드 주입은 이유가 있을 때만 쓴다.먼저 용어 정리: DIP / DI / IoC세 용어는 자주 섞여 쓰이지만 서로 다른 층위입니다.용어층위의미DIP (의존 역전 원칙..

들어가며프로젝트 초기에는 new로 객체를 직접 생성하는 게 간단해 보입니다. 시간이 지나면 테스트 코드 작성이 어려워지고, 작은 변경에도 여러 클래스를 함께 수정하게 됩니다. 이 글은 그 원인인 클래스 간 의존을 정리합니다.TL;DRnew로 구체 클래스를 직접 만들면 생성 방식·시그니처 변경이 호출한 쪽까지 전파되고, 외부 API 호출을 테스트에서 대체할 수 없다.변경 가능성이 높은 경계(외부 API, 결제, 메시지 발송 등)에만 인터페이스를 두고, 구현체는 생성자로 주입한다.그러면 Client 클래스를 수정하지 않고 구현을 교체할 수 있고(OCP), 고수준·저수준 모듈이 모두 추상에 의존하게 된다(DIP).1편 (이 글): 의존의 정의 → 구체 클래스 의존이 생기는 경로 → 강한 결합의 문제 → 인터페..

들어가며: 왜 우리는 계속 "차세대"를 만드는가많은 회사와 팀이 "차세대"라는 이름으로 같은 시스템을 몇 년마다 다시 만듭니다. 만들고, 오픈 초기에 장애를 겪고, 안정화시키고, 안정화된 시스템이 확장에 발목을 잡히면 다시 차세대를 준비하죠. 이 굴레는 금전적 비용을 넘어 개발자의 시간과 에너지, 궁극적으로는 사람들의 커리어까지 갉아먹습니다.이 굴레를 완전히 피할 방법은 없겠지만, 적어도 주기를 늦추고 지속적으로 확장 가능한 소프트웨어를 만들 방법은 있습니다. 최근 본 강의 「지속 성장 가능한 소프트웨어를 만들어가는 방법」에서는 그 방법을 비즈니스 로직 / 레이어 / 모듈이라는 세 가지 축으로 풀어내는데, 듣다 보니 정리하지 않고는 못 배기겠더라고요. 이 글은 그 내용을 정리하고, 예시 코드를 붙이고, ..