ONLINE CLASS

객체지향 디자인 패턴

COURSE FOCUS

이 강의에서 배우는 핵심 실무

객체의 책임과 클래스 사이의 관계를 UML로 표현하며 객체지향 디자인 패턴이 필요한 상황을 살펴봅니다. DI와 서비스 로케이터를 비교하고 Bridge·Strategy·Composite, Observer·Memento·State 패턴의 역할을 학습합니다. 클래스 다이어그램에서 시퀀스와 상태 다이어그램까지 연결해 프로그램의 구조와 동작을 구분하여 설계하는 관점을 익힙니다.

?

수강 전 꼭 확인하세요

수강 전 자주 묻는 내용을 간단히 안내드립니다.

Q초보자도 교재 없이 수강 가능한가요? 프로그램 정보는?

A

네, 영상과 실습자료로 쉽게 학습할 수 있습니다. 알지오는 원격평생교육원으로 프로그램 관련 정보는 제공하지 않습니다.

◆

기업이 선택한 신뢰 강의

검증된 커리큘럼과 전문 강사진으로 높은 만족도를 제공합니다.

자세히 보기 >

REAL REVIEW

수강생 리얼후기!

실제 수강생의 학습 경험을 확인해 보세요.

수강후기를 불러오는 중입니다.

RECENT Q&A

최근 수강질문

최근 등록된 수강질문을 작성순서대로 확인해 보세요.

전체 수강질문 보기

ALZIO DEEP GUIDE

객체지향 디자인 패턴을 더 깊게 이해하기

20강에서 UML·객체 책임·캡슐화·다형성·설계 원칙·DI를 익히고 생성·구조·행위 패턴과 마지막 UML 다이어그램으로 연결합니다. 패턴 목록을 암기하는 대신 해결할 변경과 협력 문제를 읽는 흐름입니다.

공식 기술정보 확인20강 커리큘럼 연결2026 현재 기술정보

객체지향 디자인 패턴 · 20강 · 19시간 52분

01

객체지향 디자인 패턴은 무엇인가

디자인 패턴은 반복되는 설계 문제의 구조와 해결 방향을 설명하는 지식입니다. 특정 라이브러리를 설치하는 것과 다르며 객체의 책임·협력·변경 요구를 함께 봅니다. UML은 구조와 동작을 표현하는 모델링 언어입니다.

02

관련 플랫폼과 개발도구의 관계

객체지향 언어는 구현 수단이고 UML은 설계를 표현하며 DI는 의존 객체를 제공하는 방식입니다. GoF 객체 패턴과 시스템 규모의 클라우드 패턴은 서로 다른 층입니다. 패턴 이름이 같아도 문제와 비용을 먼저 확인합니다.

03

객체지향 디자인 패턴의 핵심 기능

기술 자체의 기능과 이 강좌의 직접 학습 범위는 다릅니다. 아래 연결 표시는 저장된 공개 커리큘럼에 근거합니다.

책임·캡슐화

자료와 동작의 경계를 정합니다. 변경 이유가 어디에 있는지 설명합니다. 모든 코드를 클래스로 감싸는 것과 다릅니다.

기술 참고 · 직접 학습 여부는 아래 회차 연결표에서 확인

추상화·다형성

다른 구현을 같은 계약으로 다룹니다. 교체와 재사용의 조건을 정합니다. 상속만이 유일한 방법은 아닙니다.

기술 참고 · 직접 학습 여부는 아래 회차 연결표에서 확인

DI·설계 원칙

의존성과 생성 책임을 나눕니다. 테스트와 교체 범위를 이해합니다. 도구 설치만으로 원칙이 적용되지는 않습니다.

기술 참고 · 직접 학습 여부는 아래 회차 연결표에서 확인

생성·구조 패턴

객체 만들기와 연결 문제를 구분합니다. Factory·Builder·Adapter 등을 목적과 연결합니다. 모든 패턴을 함께 넣을 필요는 없습니다.

기술 참고 · 직접 학습 여부는 아래 회차 연결표에서 확인

행위 패턴

요청·상태·알림·알고리즘의 협력을 정리합니다. 변경과 호출 흐름을 설명합니다. 클래스 수 증가의 비용도 살펴야 합니다.

기술 참고 · 직접 학습 여부는 아래 회차 연결표에서 확인

UML

구조와 상호작용을 모델로 표현합니다. 코드의 관계와 시나리오를 전달합니다. 다이어그램만으로 실행 결과를 보장하지 않습니다.

기술 참고 · 직접 학습 여부는 아래 회차 연결표에서 확인

04

이 과정의 실제 작업 흐름

1~4강은 모델·UML 관계·객체 책임·캡슐화·추상 타입·상속과 조립 재사용이고 5~6강은 SOLID·DI·서비스 로케이터·GoF 개요입니다.

7~14강은 생성 패턴과 Iterator·Adapter·Template Method·Singleton·Prototype·Bridge·Strategy·Composite·Decorator·Visitor·Chain·Facade·Mediator입니다. 15~19강은 Observer·Memento·State·Flyweight·Proxy·Command·Interpreter이며 20강은 구조·행위 다이어그램입니다.

객체·UML
책임·캡슐화
추상화·재사용
설계 원칙·DI
패턴별 협력
다이어그램 점검

05

핵심 구조를 이해하는 방법

생성·구조·행위라는 분류는 객체 생성과 연결·협력의 문제를 나눕니다. 상속·합성·인터페이스로 책임을 표현하고 실제 변경이 어느 객체에 영향을 주는지 확인합니다. 패턴을 많이 쓰는 것 자체가 좋은 설계의 기준은 아닙니다.

06

실무 적용과 결과 확인

4~6강을 복습할 때 의존 객체를 바꾸는 요구가 어느 클래스에 영향을 주는지 기록해 보세요. 상속과 조립을 비교하는 추가 연습입니다. 실제 요구 없이 패턴 수를 늘리지 않습니다.

11~19강은 상태 변경·알림·요청 전달의 순서를 그려 보고 20강의 시퀀스·상태 다이어그램과 연결하세요. 서로 다른 패턴으로 같은 문제를 비교하는 것은 응용 제안입니다. 공개 자료에 없는 언어·완성 프로젝트를 추측하지 않습니다.

07

이 강좌에서 집중할 전문주제

전문 축은 설계 원칙에서 구체적인 패턴으로 연결하는 것입니다. 5~6강의 책임·의존성을 7~19강의 객체 협력과 대조하면 추상화의 이유를 설명할 수 있습니다.

UML은 앞뒤에서 학습합니다. 1~2강의 클래스 관계와 20강의 유스케이스·활동·상태·시퀀스를 나누어 읽으면 구조와 실행 시나리오를 함께 정리할 수 있습니다. 모든 클라우드 아키텍처 패턴을 직접 범위에 포함하지 않습니다.

08

현재 기술과 강좌 환경의 관계

패턴은 특정 제품 릴리스 하나의 기능이 아닙니다. 공개 목록만으로 구현 언어나 도구 버전을 확정하지 않습니다.

현재 .NET의 DI·Observer 문서는 개념 확인용 예시입니다. .NET 구현을 본 강좌의 언어로 추정하지 않습니다. UML 규격 번호도 강좌 환경 번호와 구분합니다.

09

목적에 맞는 기술 선택과 비교

아래 비교는 목적과 작업 구조를 선택하기 위한 안내입니다. 다른 기술 전체를 본 강좌에서 가르친다는 뜻은 아닙니다.

목적에 맞는 기술 선택과 비교
선택지	작업 접근	이 강좌와의 관계
상속	타입 관계와 구현 확장	4강의 재사용
합성·조립	객체 협력과 교체	4강의 다른 재사용
UML	구조·동작의 표현	1~2·20강

10

기술개념과 알지오 커리큘럼 연결

회차는 공개 커리큘럼의 실제 순서입니다. 실습 후 응용 제안과 현재 기술 참고정보를 강의에서 제공하는 실습으로 해석하지 않습니다.

기술개념과 알지오 커리큘럼 연결
기능·개념	무엇인가	실무 의미	강좌 회차	학습 상태
객체·UML·재사용	책임·관계·캡슐화·추상 타입	변경 경계	1·2·3·4강	강좌에서 직접 학습
원칙·DI	SOLID·의존 객체·패턴 개요	교체 책임	5·6강	강좌에서 직접 학습
생성·구조·협력	Factory부터 Mediator까지	문제별 선택	7·8·9·10·11·12·13·14강	강좌에서 직접 학습
알림·상태·요청	Observer부터 Interpreter까지	호출과 자료 흐름	15·16·17·18·19강	강좌에서 직접 학습
UML 다이어그램	구조·행위·상호작용	설계 전달	20강	강좌에서 직접 학습

11

처음 배울 때 자주 생기는 오해

패턴은 라이브러리인가?

설계 문제의 구조입니다. 구현 도구와 구분합니다. 6~7강에서 목적을 먼저 읽으세요.

상속이 언제나 재사용의 답인가?

조립도 선택지입니다. 변경 조건이 다릅니다. 4강의 두 방식을 비교하세요.

DI와 서비스 로케이터가 같은가?

의존 객체를 얻는 방식이 다릅니다. 6강에서 역할을 구분합니다. 테스트와 생성 책임을 함께 봅니다.

Singleton이면 동시성도 안전한가?

인스턴스 수와 공유 자료 조건은 다릅니다. 9~10강을 동작과 연결하세요. 안전성을 이름만으로 보장하지 않습니다.

Observer가 호출 비용을 없애나?

알림 협력을 정리합니다. 구독과 실행 비용은 남습니다. 15~16강에서 흐름을 확인하세요.

UML이 동작을 증명하나?

설계 표현입니다. 구현과 테스트는 따로 확인합니다. 20강의 시나리오를 실제 결과와 대조하세요.

12

다음 학습 방향

C++ (기초+실무)

C++ 클래스와 객체 기반 구현을 별도로 보강합니다.

자료 보기 →

스프링 프레임워크

DI를 사용하는 웹 프레임워크의 실제 구성을 비교합니다.

자료 보기 →

객체지향 디자인 패턴 관련 과정 비교

입문·실무·심화 과정의 실제 커리큘럼을 목적에 맞게 비교합니다.

자료 보기 →

실습과 복습 계획

새 환경에서 예제를 확인하고 학습 계획을 세우는 방법을 살펴봅니다.

자료 보기 →

객체지향 디자인 패턴

객체지향 디자인 패턴

객체지향 디자인 패턴

강의구성
(20강) 전체 : 19시간 52분|평균 : 59분36초

이용기간/강사
1개월2개월
알지오 R&D [IT] ▶ 프로필 보기

증빙가능
수료증, 수강증, 학습진도

수강료
190,000원95,000원

?

수강 전 꼭 확인하세요

수강 전 자주 묻는 내용을 간단히 안내드립니다.

Q 초보자도 교재 없이 수강 가능한가요? 프로그램 정보는?

A

네, 영상과 실습자료로 쉽게 학습할 수 있습니다. 알지오는 원격평생교육원으로 프로그램 관련 정보는 제공하지 않습니다.

01.56분 디자인 패턴과 객체지향 part1
디자인 패턴의 필요성, 스크린UI 추가, 메뉴별 클래스 생성 방법, 모델의 역할, UML 모델링 언어, 구조 다이어그램, 행의 다이어그램, 클래스 다이어그램, 재귀적 연관 관계

객체지향과 디자인 패턴의 필요성, 소프트웨어의 설계가 제대로 되지 않았을 때 발생하는 문제점, application클래스 살펴보기, 화면구성 확인, 코드 리스트 작성, 화면 전환을 위한 코드, clicked메소드에서 이벤트 처리, currentmenu에 각각 해당되는 메뉴명 저장, 버튼2 추가, clicked메소드 확인, 같은 상황을 객체지향 방식으로 처리, 메뉴가 선택되면 해당 화면 출력, 버튼1을 클릭하면 선택된 메뉴화면에서 적절한 처리 수행, screenUI타입 정의, show메소드, handlebutton1click메소드, 메뉴별로 screenUI 인터페이스를 구현한 클래스 작성, clicked메소드 확인, show메소드 호출, button1을 클릭했을 때 처리하는 부분, clicked메소드에서 정리해야 할 코딩 부분, 두 종류의 버튼처리 코드, clickde메소드를 메뉴처리 부분과 버튼처리 부분으로 분리, 버튼2 추가, 인터페이스에 handlebutton2click추가, 버튼2 처리 내용 작성, 최종적으로 수정된 코드 내용, if/else구문 사용, 메뉴3을 추가 할 경우, screenUI타입을 추가시키고 메뉴별로 클래스 만드는 방법 구현 완료, 필요한 내용을 분리함으로 얻을 수 있는 장점, 객체지향 기법, 객체지향 모델링, 모델의 역할, 모델링 언어 UML, 다양한 다이어그램의 제공 이유, 구조 다이어그램, 행위 다이어그램, 클래스 다이어그램, 주요 구성 요소, 클래스 설명, 고양이를 만들어내는 설계도, 클래스의 속성과 연산을 기술, public/private/protected/package, 분석 단계, 설계 단계, 관계 설명, 연관 관계(association), 두 클래스 사이의 연관 관계, 두번째 다이어그램 확인, 두 클래스 사이의 연관 관계를 나타내는 화살표, 숫자로 객체 범위를 표현, 다중성의 표현, 연관 관계의 방향성, 클래스 다이어그램을 소스코드로 구현, 클래스로 표현, 메소드는 public으로 선언, 연관 관계가 표현되어 있는 클래스 다이어그램도 소스코드로 구현, 속성의 이름이 역할의 이름 활용, 단방향 연관 관계, 소스코드 구현, setter/getter메소드, 다중성 구현, 소스코드 구현, vector이용, course객체와 student객체의 관계, 다중성 수정, 소스코드 구현, class student와 class course가 독립적으로 선언, course class변화, 연관 클래스(association class), 연관 관계에 추가할 속성이나 행위가 있을 때 사용, 연관 클래스 구현 방법, 예제 확인, transcript클래스, student클래스와 transcript클래스의 연관 관계의 다중성, 일반 클래스로 변환 한 예, transcript를 소스에 적용, transcript생성 자료, 클래스 다이어그램 추가, borrowing연관 관계, 재귀적 연관 관계, 관계의 루프
02.54분 객체지향 part2
클래스 다이어그램, 일반화 관계, 집합 관계(합성 관계, 집약 관계), 의존 관계, 실체화 관계, 절차지향과 객체지향의 차이점, 객체의 정의, 객체의 책임과 크기

일반화 관계(generalization), 자식클래스(서브클래스)/부모클래스(슈퍼클래스), is a kind of 관계, 추상 메소드, 추상 클래스, 일반화 관계를 클래스 다이어그램으로 표현, 집합 관계(composition, aggregation), 합성 관계(composition), 부분 객체가 전체 객체에 속하는 관계, 집약 관계(aggregation), 부분 객체와 전체 객체가 독립적, 소스코드 비교, 속성은 모두 동일, 합성 관계 모델링, 집약 관계 모델링, 의존 관계(dependency), 클래스의 속성에서 참조할 때, 연산의 인자로 사용될 때, person과 car의 연관 관계 소스코드 구현, gaspump추가, 실체화 관계(realization), 인터페이스, turn_on/turn_off기능, 클래스 다이어그램 확인, 스테레오로 interface입력, 키워드, 인터페이스와 클래스 사이의 실체화 관계, can do this 관계, 객체지향에 대한 자세한 설명, 절차지향, 프로시저들이 데이터를 조작, 프로시저를 이용한 프로그래밍 기법, 여러가지 문제 발생, 객체지향, 객체들로 구성, 프로시저는 자신이 속한 객체의 데이터에만 접근 가능, application.java는 절차지향으로 구현, 절차지향-프로그램 수정이 어려운 구조, 객체지향-프로그램 수정이 쉬운 구조, 객체(object)알아보기, 객체가 제공해야 할 기능-소리크기 제어 객체, signature(기능식별이름, 파라미터, 결과값), 인터페이스, 클래스, 소리크기 제어 객체, 파일 읽기 객체, 암호화 처리 객체, 메시지, 객체의 책임과 크기, 객체의 책임을 정의-인터페이스, 프로그램을 만들기 위해 필요한 기능의 목록 정리, 객체의 구성, 규칙, 절차지향 방식과 동일한 구조, 객체지향의 장점, 단일 책임 원칙(single responsibility principle), 의존, 다른 객체 이용, 흐름제어 객체 소스코드 구현, 다른 객체를 생성/다른 객체의 메소드 호출, 파라미터 전달, 스트링 타입으로 파일 경로를 받도록 수정될 경우, 스트링 변수 추가, 변경은 의존 관계에 따라 전이, 순환 의존의 특성, 의존의 양면성을 확인하는 코드, authenticator클래스에 의존, try/catch문에 exception을 통해 구분, authenticate메소드의 변경, 의존이 상호간의 영향을 주는 것 의미, 캡슐화(encapsulation), 소스코드 확인, 절차지향적인 코딩, 만료시 처리, 만료 여부를 확인하는 규칙의 변경을 코드에 반영, 버그 발생 가능성, 문제 발생의 이유, 객체지향적으로 코드 재 구현, 캡슐화 기능, 만료 여부 확인 구현을 캡슐화, 만료시 처리 부분 확인, 만료 여부 규칙의 변경, 기능을 사용하는 곳의 영향을 최소화
03.53분 객체지향 part3
캡슐화 기능 구현, 캡슐화를 위한 규칙, 객체지향 설계과정, 객체지행의 원리

캡슐화를 위한 2가지 규칙, tell, don't ask, 만료 일자 데이터를 가진 member객체에게 만료 여부 확인, isexpired를 member클래스에서 구현, 데미테르의 법칙(law of demeter), 파라미터로 받은 객체의 메소드만 호출, 기능 구현의 캡슐화를 향상, 예제 코드 확인(신문 배달부 예제), 고객과 지갑에 대한 클래스 확인, 신문 배달부 클래스, 신문 배달부가 고객의 지갑을 확인하지 않을 경우, 데미테르의 법칙을 어기고 있는 코드, 데미테르의 법칙을 지키지 않는 증상, 객체지향 설계과정, 제공해야 할 기능 찾고 알맞은 객체에 할당, 객체 간에 어떻게 메시지를 주고 받을 지 결정, 파일 데이터 암호화 기능 목록, 각 객체의 연결 그림, 객체의 크기는 구현을 진행하는 과정에서 명확, 객체를 새로 만들어 분리, 설계를 할 때 변경되는 부분 고려, 객체지향의 원리, 추상화, 필요로하는 속성이나 행동을 추출하는 작업, 추상화의 정의, 캡슐화, 응집도/결합도, 객체지향 설계 원리, 정보은닉, 일반화 관계, 일반화의 개념, 예제 소스코드 확인, 코드를 수정할 필요가 없도록 작성, 서브클래스 캡슐화, 일반화 관계와 위임, 예제 확인, 예제 소스코드 확인, 메인 메소드 확인, stack에서 사용해서는 안되는 메소드, is a kind of 관계의 성립, 위임, 일반화를 대신해서 위임을 사용하는 방법, arlist객체 생성-this로 초기화, arlist 객체를 참조할 수 있도록 변경, 클래스의 일반화 관계 제거, isempty/size메소드의 위임메소드를 서브클래스에 추가, 집합론 관점으로 본 일반화 관계, disjoint/complete 제약조건 사용, 예제 확인, 일반화의 역관계 특수화, local/non local, 다중 분류, 분류 가능한 조합에 각각 대응되는 클래스 생성, 집합론 관점, 다형성, 예제 소스코드 확인, 다형성의 개념, 다형성을 사용하지 않고 작성한 예제 코드, 메인코드 확인, 다형성을 사용한 코드, 피터코드의 상속 규칙, 클래스 다이어그램의 예제, 연관관계-집약관계 사용, 다형성과 추상타입, 재사용, 다형성과 상속, 자바-정적타입 언어, 자바스크립트,루비,그루비-동적타입 언어, 예제 소스코드 확인, 타입의 상속-인터페이스 상속,구현 상속, 상속받은 인터페이스에 정의된 메소드 실제 구현, 구현상속
04.51분 다형성과 추상타입, 재사용
추상 타입과 유연함, 상속과 재사용, 조립을 이용한 재사용

실제 코드 확인, 추상 타입과 실제 구현의 연결, 클래스 다이어그램 확인, collector, collector객체타입의 collect메소드 호출, socketlogreader, 추상 타입을 이용한 구현 교체의 유연함, 각각의 기능에 따라 나눈 클래스, flowcontroller의 코드 보기, file read부분 수정, 생성자 boolean, flowcontroller 설명, 기존 요구사항과 추가된 요구사항, 구현 추상화, byteSource.java 인터페이스 추가, socketDateReader추가해서 byteSource상속받기, flowcontroller코드는 byteSource를 사용하도록 수정 가능, source.read메소드 호출, byteSource타입의 객체를 생성하는 부분, byteSource타입 객체 생성기능 분리, 생성자를 이용, byteSource전달받기, 문제 해결, create메소드 보기, singleton pattern적용한 부분, flowcontroller 수정, http를 이용해 암호화할 데이터를 읽어오라는 요구 발생, 변경되는 클래스는 byteSourceFactory에 적용, 추상화 과정을 통해 얻은 2가지 유연함, 데이터 읽는 부분과 생성하는 부분 추상화, 변화되는 부분을 추상화하기, 추상타입으로 교체, 추상화가 되어있지 않은 코드, 인터페이스에 대고 프로그래밍하기, 인터페이스는 새롭게 발견된 추상개념을 통해 도출, program to interface규칙, 인터페이스를 사용해야할 경우, 인터페이스는 인터페이스 사용자 입장에서 만들기, 소켓을 이용해 데이터를 읽어오는 기능이 필요할 경우, ByteSource, 인터페이스와 테스트, testProcess클래스 작성, byteSource인터페이스를 사용하도록 프로그래밍 되어있는 경우, mock객체를 이용해 테스트, mock객체를 만드는 방법, 상속과 재사용, 웹 요청을 처리하기 위한 클래스 제공, BaseCommandController, BaseCommandController가 AbstractController기능 확장, 상속의 단점, 의존하는 클래스 코드가 변경되면 자식 클래스에 영향, 상속을 통한 재사용의 단점, 클래스의 불필요한 증가, 압축을 먼저 하고 암호화한 저장소가 필요할 경우, 상속의 오용, 조립을 이용한 재사용, 4개의 객체를 조립한 예제, Encryptor클래스 재사용, 조립을 이용하면 불필요한 클래스 증가 방지, 조립방식의 또 다른 장점, 상속보다는 객체 조립 사용, 조립을 사용할때의 단점, 위임(delegation), 상속을 사용할 경우, 클래스 계층의 특징, 조립으로 전환하는 부분 고려
05.56분 설계 원칙과 DI와 서비스 로케이터 part1
단일 책임 원칙, 개방 폐쇄 원칙, 리스코프 치환 원칙, 인터페이스 분리 원칙, 의존 역전 원칙, 어플리케티션 영역, 메인 영역

설계 원칙(SOLID), 단일 책임 원칙(Single responsibility principle), 단일 책임 원칙을 위반했을 경우의 문제, updateGui메소드, http프로토콜에서 소켓프로토콜로 변경이될 경우, 단일 책임 원칙을 위반했을 경우의 또 다른 문제, 단일 책임 원칙을 준수할 경우, 데이터 읽기, 데이터 보여주기, 단일 책임 원칙을 지킬 수 있는 방법, 개방 폐쇄 원칙(Open-closed principle), 기능을 확장하면서도 기존코드는 변경되지 않는 것을 의미, 변화되는 부분을 추상화해서 표현, 개방 폐쇄 원칙을 구현하는 또 다른 방법, ResponseSender클래스 예제, sendHeader, sendBody, ResponseSender를 상속받은 클래스, ResponseSender클래스는 확장에는 열려있지만 변경에는 닫혀있는것 의미, 개방 폐쇄 원칙이 깨진 것이 아닌지 확인해야할 특징, 다운캐스팅, 타입확인, instanceof 타입확인 연산자, drawSpecific메소드, 비슷한 if-else블록, Enemy클래스에 새로운 경로패턴을 추가할 경우, 경로패턴 추상화, 리스코프 치환 원칙(Liskov substitution principle), 가장 대표적인 예제(직사각형, 정사각형) 확인, square클래스가 rectangle클래스를 상속받도록 구현, increseHeight메소드 살펴보기, instanceof연산자 사용, LSP는 계약과 확장에 대한 것, 리스코프 치환 원칙을 어길 경우, instanceof연산자를 사용해서 확인, 상위타입의 추상화가 되지않아 생긴 문제, item클래스와 specialitem클래스 소스코드 확인, instanceof연산자를 사용하던 코드를 클래스만 사용하도록 구현, 인터페이스 분리 원칙(Interface segregation principle), 클라이언트는 자신이 사용하는 메소드에만 의존, 인터페이스 분리 원칙을 지키지 않았을 경우, ArticleService의 목록 읽기 기능의 변경 발생, 게시글 목록 기능에만 변경이 됐어도 모든 소스를 다시 컴파일, 용도에 맞게 인터페이스 분리, 인터페이스를 분리하는 기준-클라이언트, 의존 역전 원칙(Dependency inversion principle), 고수준 모듈과 저수준 모듈, 고수준 모듈과 저수준 모듈의 예제, 저수준 모듈이 고수준 모듈을 의존하게 만들어 해결, 의존 역전 원칙은 타입의 소유도 역전, 배포 기준이 되는 패키지, 의존 역전 원칙을 적용하지 않을 경우, DI와 서비스 로케이터, 어플리케이션 영역 / 메인 영역, 비디오 포맷 변환기 예제, 요구사항 분석, 비디오 포맷 변환기 설계 확인, 개방 폐쇄 원칙, worker클래스 코드 살펴보기, jobQueue를 구현한 객체 구하기, Locator객체 사용, Locator클래스는 transcoder패키지에 위치, Locator객체의 초기화, 메인 영역, 어플리케이션 영역의 객체들을 생성, 설정, 실행, 서비스 locator방식
06.58분 설계 원칙과 DI와 서비스 로케이터 part2
DI를 이용한 외존객체 사용 방법, 서비스 로케이터를 이용한 의존 객체 사용, 디자인 패턴의 이해, GoF 디자인 패턴, UML과 디자인 패턴, 각 디자인 패턴들

DI를 이용한 의존 객체 사용방법, 서비스 로케이터를 사용할 경우, worker생성자, main클래스 변경, DI를 통해 의존 객체를 관리할 경우, main클래스가 조립기의 역할, Assembler작성, getWorker, getJobCLI를 제공, DI를 이용한 의존 객체 사용, 생성자 방식, 설정 메서드 방식, 조립기는 생성자와 설정 메서드를 이용해 의존 객체 전달, DI와 테스트, 클래스 구현이 완료되지 않은 상황, springframework살펴보기, worker는 생성자 방식, jobCli는 설정 메서드 방식 이용, property태그, classPathXmlApplicationContext클래스, string 조립기의 역할, xml설정파일을 사용하는 방식, xml을 사용할 때의 문제점을 해결하는 방법, xml파일을 java코드 기반으로 교체한 예제, 의존 객체를 변경해야 하는 경우, 서비스 로케이터를 이용한 의존 객체 사용, 실행 환경의 제약때문에 DI패턴을 적용할 수 없는 경우, serviceLocator, 서비스 로케이터가 올바르게 동작 하려면, 서비스 로케이터를 구현하는 방식, 객체 등록 방식, 서비스 로케이터 접근 위한 static메서드 제공, 메인 영역의 코드 확인, 어플리케이션 영역 코드 확인, 서비스 로케이터가 제공할 객체의 종류, 어플리케이션 영역에서 의존 객체 변경 가능, 상속, abstract를 이용해 구현, 의존 객체를 필요로 하는 코드, myServiceLocator정의, main영역에서 클래스의 객체 생성, 지네릭 / 템플릿, serviceLocator의 단점, jobQueueLocator와 transcoderLocator를 따로 생성, 지네릭이나 템플릿을 이용해 서비스 로케이터를 구현할 경우, 지네릭 방식의 예제, static메서드만으로 구성, jobQueue에만 의존, 서비스 로케이터의 가장 큰 단점, 서비스 로케이터 보다는 DI사용, 디자인 패턴, 디자인 패턴의 이해, 디자인 패턴의 구조, GpF 디자인 패턴, 생성패턴, 구조패턴, 행위패턴, UML과 디자인 패턴, 컬레보레이션(Collaboration), 객체와 역할 사이의 관계, 객체들이 특정 상황에서 수행하는 상호작용, 구체적인 상황의 콜라보레이션 적용 표현, 순차 다이어그램(Sequence diagram), 생명선, 객체 사이의 메시지는 화살표로 표시, 열려있는 화살표는 비동기 메시지, 채워져 있는 화살표는 동기 메시지, <>객체생성 메시지, <>객체소멸 메시지, 메시지를 표현하는 형식, 시퀀스 번호, 가드, 응답 메시지, 도서대여 관련 순차 다이어그램 예제, ref키워드 사용, 객체사이의 상호작용을 효과적으로 나타내는 여러가지 연산 제공, 순차 다이어그램과 클래스 다이어그램의 관계, 차이점, 클래스x와 클래스y의 연관관계 성립
07.50분 디자인 패턴들 part1
생성 패턴, 구조 패턴, 행위 패턴, Abstract Factory, Builder

각 디자인 패턴들 알아보기, Abstract Factory, 예제-엘리베이터 부품 업체 변경, 각 제조 업체별로 부품 개발, 추상클래스로 Motor와 Door를 정의, Motor클래스는 Door클래스의 getDoorStatus메소드 호출, Motor클래스의 move메소드 기능, 일반적인 흐름은 동일하지만 특정 부분만 다른 동작을 하는 경우, 템플릿 메서드 패턴 활용, Door클래스의 open메소드 기능, lgDoor와 hdDoor의 class코드 작성, Door는 추상클래스로 정의, Door코드 보기, close는 템플릿 메서드, 하위 클래스에서 오버라이드 될 부분은 primitive 또는 hook메서드, open과 doOpen, 추상클래스 Door를 상속받는 lgDoor와 hdDoor코드 보기, doClose와 doOpen구현, 클래스 다이어그램 확인, open의 대표적인 역할, 문을 제어하는 클래스가 필요, LGMotor와 HDMotor생성 부분 확인, MotorFactory클래스의 createMotor메서드, MotorFactory코드 보기, vendorID에 따라 LGMotor, HDMotor생성, DoorFactory코드 보기, Client클래스, open명령을 사용, move메서드 기능, 추상팩토리가 필요한 이유, 다른 제조업체의 부품을 사용해야 하는 경우, 설정 부분 변경, 부품별 클래스 보기, 총 10개의 Factory객체를 사용해서 엘리베이터를 구성하는 코드, 새로운 제조업체의 부품을 사용할 경우, DoorFactory클래스 보기, enum에 SS업체 추가, client에서 HD를 SS로 변경, LGElevatorFactory, HDElevatorFactory, createMotor메서드와 createDoor메서드 제공, ElevatorFactory클래스 다이어그램, 추상클래스로 정의되는 ElevatorFactory클래스 보기, 추상메서드 createMotor와 createDoor선언, client코드 보기, 새로운 제조업체의 부품을 지원하는 경우, SSElevatorFactory생성, SSElevatorFactory클래스, SSDoor클래스, SSMotor클래스 보기, client수정, 해당 제조업체의 부품을 생성하는 factory클래스 추가, 클래스 다이어그램 확인, Abstract Factory, 추상팩토리 패턴의 컬레보레이션 다이어그램, 추상팩토리 패턴에서 나타나는 역할, AbstractFactory, ConcreteFactory1, AbstractProductA, 추상팩토리 순차 다이어그램, client부터 순차적으로 보기, LGElevatorFactory와 HDElevatorFactory클래스에 추상팩토리 패턴을 적용한 클래스 다이어그램, ElevatorFactory클래스는 AbstractFactory역할, 예제-슈팅게임 만들기, 클래스 다이어그램 보기, Stage클래스 코드 확인, 코드의 문제점, 추상팩토리 적용 결과 확인, EnemyFactory추가, EnemyFactory구현, 객체 생성을 위한 팩토리 메서드, EasyStageEnemyFactory와 HardEnemyFactory정의, Factory를 사용하도록 변경된 Stage클래스, enemyFactory를 사용해 객체 생성, Builder, Builder패턴 설명, 예제 확인, 유연한 자료구조 필요, Builder패턴의 클래스 다이어그램, client내용 확인
08.57분 디자인 패턴들 part2
Iterator, Adapter, Template Method

추상팩토리 패턴에 Factory Method패턴과 Template Method패턴, 패턴들의 순서, Iterator패턴, 배열 arr의 모든 요소를 표시하기 위해 for문 사용, i변수 확인, i를 하나씩 증가, Iterator패턴 설명, 예제 확인, 클래스 다이어그램 확인, 인터페이스 Aggregate, Aggregate의 소스 보기, 인터페이스 Iterator, Iterator에 필요한 메서드, hasNext메서드, next메서드, Book클래스 보기, BookShelf클래스, BookShelf클래스 소스 보기, books필드를 private으로 한 이유, BookShelfIterator클래스 소스 보기, hasNext메서드, next메서드, Main클래스 만들기, while의 조건, Iterator패턴의 4가지 역할, Iterator, ConcreteIterator, Aggregate, ConcreteAggregate, Iterator패턴을 사용하는 이유, 동일 자료형의 여러 객체 순차 접근, Adapter패턴, wrapper패턴, 클래스에 의한 Adapter패턴(상속), 예제 확인, Banner클래스, 인터페이스 Print, PrintBanner가 Adapter의 역할을 담당, Banner클래스 보기, Print인터페이스 보기, PrintBanner클래스 보기, printWeak메서드와 printStrong메서드, Main보기, 인스턴스에 의한 Adapter패턴(위임), 클래스 다이어그램 확인, Print와 Print2의 소스 차이, printWeak메서드와 printStrong메서드, 역할 살펴보기, Target의 역할, Client의 역할, Adaptee의 역할, Adapter의 역할, 위임을 사용한 경우, 만들어진 클래스를 새로운 인터페이스에 맞게 개조 시킬 경우, 버전 업, Template Method, 예제 확인, HDMotor클래스, enumeration인터페이스 필요, HDMotor클래스의 move메소드를 순차 다이어그램으로 표현, 소스 코드 구현, Door클래스 보기, HDMotor클래스 보기, move메서드 보기, Client클래스 보기, LGMotor를 추가할 경우, LGMotor를 구현한 예제, 코드 중복의 문제, Motor클래스 구현, HDMotor와 LGMotor의 소스 코드 보기, 상속을 활용해 코드 중복 피하기, 클래스 다이어그램 확인, move메서드를 Motor클래스로 이동시킨 모습, HDMotor확인, 소스 코드 확인, Motor클래스의 move메서드 보기, 코드 중복 최소화에 유용, move메소드-템플릿 메소드, moveMotor메소드-Primitive메소드 또는 hook메소드, 콜라보레이션 다이어그램 확인, Client는 templateMethod메소드 호출, 템플릿 메소드 패턴을 Motor예제에 적용한 경우, 템플릿 메소드 패턴의 특징, 리스코프 치환 원칙, 상위 클래스 입장, 추상 클래스 개념, 상위 클래스와 하위 클래스의 협조
09.57분 디자인 패턴들 part3
Factory Method, Singleton

Factory Method패턴, 인스턴스를 생성하는 공장을 Template Method로 구현, idcard를 만드는 예제, framework살펴보기, Product클래스 확인, 클래스 다이어그램으로 소스 구현, Product클래스, Factory클래스, 제품을 만들고 등록하는 구현작업은 하위클래스에서 수행, create메소드, 추상메소드로 정의, IDCard패키지 살펴보기, IDCardFactory클래스, createProduct, registerProduct, Main클래스, Factory Method패턴 상세히 알아보기, 여러대의 엘리베이터 예제, 스케줄링, 복수의 엘리베이터를 스케줄링해서 이동시키는 클래스 다이어그램, ElevatorManager클래스 소스, 주어진 수만큼의 ElevatorController를 생성함, requestElevator메소드, ElevatorController클래스, ThroughputScheduler클래스, 소스 구현의 문제점, 동적 스케줄링을 지원할 수 있도록 수정된 ElevatorManager클래스 코드, requestElevator의 코드 변화, 현재 시간에 따라 적절한 스케줄링 객체 생성, 클래스 다이어그램에 적용, 새로운 스케줄링 전략이 추가되는 경우, 문제점을 해결을 위한 방법, SchedulerFactory클래스 추가, SchedulerFactory클래스 소스 구현, getScheduler메소드 호출, SchedulerFactory클래스를 이용할 수 있도록 수정된 ElevatorManager클래스, 스케줄링 전략을 설정, Client클래스 코드 보기, 상황에 따라 적절한 객체를 생성하는 코드 자주 중복, Factory Method패턴의 개념을 잘 보여주는 그림, Factory Method패턴이 적용된 부분, Factory Method패턴을 상속을 이용해 적용한 다이어그램, ElevatorManager는 getScheduler메소드를 추상메소드로 정의, ElevatorManager클래스의 코드, requestElevator메소드는 getScheduler메소드를 추상메소드로 정의, 템플릿 메소드에 해당, Factory Method Pattern의 콜라보레이션 다이어그램, Factory Method Pattern을 엘리베이터 예제에 적용, Singleton패턴, 요소를 하나만 가지고 있는 집합, 간단한 클래스 다이어그램, singleton클래스 생성자, Singleton클래스 소스 코드, Main클래스 소스 코드, obj1과 obj2가 동일한 객체인지 확인, Printer클래스, 외부에서 생성자를 호출할 수 없도록 하기, Printer클래스의 생성자를 private로 선언, getPrinter메소드, getPrinter메소드와 printer변수 static타입으로 선언, 정적메소드로 선언, 5명의 사용자가 printer를 이용하는 상황으로 코드 작성, 다중 쓰레드에서 Printer클래스를 이용할 경우, 다중 쓰레드 애플리케이션에 발생하는 문제 해결방법, 정적 변수에 인스턴스를 만들어 초기화하는 방법, 인스턴스를 만드는 메소드에 동기화하는 방법, counter변수 추가, print메소드의 counter변수를 변경하는 부분 동기화 필요, Singleton패턴의 순차다이어그램, Singleton패턴과 정적 클래스의 관계, print메소드 동기화, UserThread 5개 생성 후 스레드 실행, 정적 클래스를 사용할 수 없는 경우, Printer 인터페이스를 구현하는 RealPrinter, UsePrinter소스 코드 확인, Printer 인터페이스 확인, 테스트용 가짜 프린터인 FakePrinter확인, doSomething메소드로 인터페이스의 단위테스트를 하는 상황 가정, 정적 클래스의 문제를 싱글턴 패턴으로 해결, 정적 setter메소드 사용, DoSomethingTest, 가짜 Printer객체 주입, Singleton패턴 정리
10.49분 디자인 패턴들 part4
Singleton, Prototype, Builder, Abstract Factory

Singleton패턴, 팩토리메소드 패턴 설계부분 보기, SchedylerFactory클래스, RESPONSE_TIME, THROUGHPUT, DYNAMIC, Client class확인, 중복되어 생성, Singleton패턴을 적용한 설계부분, Singleton패턴을 적용한 SchedylerFactory클래스, Singleton패턴으로 구현한 ThroughputScheduler, ResponseTimeScheduler, Abstract Factory Pattern에서 Singleton패턴을 적용하는 과정, 제품군별 객체 생성, Motor클래스 확인, 템플릿 메소드 패턴, Client3 소스 확인, 제조 업체별 Factory객체, 제조 업체별 Factory클래스를 Singleton패턴으로 설계, 소스 코드 확인, Client4 클래스 코드, Prototype패턴, 클래스 이름을 지정하지 않고 인스턴스를 생성할 때, 종류가 너무 많아 클래스로 정리되지 않는 경우, 클래스로부터 인스턴스 생성이 어려운 경우, framework와 생성할 인스턴스를 분리하고자 할 경우, Prototype패턴을 사용한 예제, product 인터페이스, UnderlinePen클래스와 MessageBox클래스, product 인터페이스 소스 코드 확인, use메소드, createClone메소드, Manager클래스, proto, 하위클래스 살펴보기, decochar, MessageBox클래스 소스 코드 확인, clone메소드로 복사 가능한 것, 자신 또는 하위 클래스에서만 호출, UnderlinePen클래스의 소스 코드 확인, Prototype패턴의 역할을 나타내는 클래스 다이어그램, 종류가 너무 많아 클래스로 정리되지 않는 경우, 클래스로부터 인스턴스 생성이 어려운 경우, framework와 생성할 인스턴스를 분리하고자 할 경우, Clone알아보기, Clone이 내부적으로 하는 일, Cloneable인터페이스, Builder패턴의 개념, Biilder패턴의 예제, 클래스의 구성 확인, Builder클래스, Builder클래스의 하위 클래스, Builder클래스의 소스 코드, Director클래스의 소스 코드, construct메소드, TextBuilder클래스 소스 코드, HTMLBuilder클래스 소스 코드, Main클래스 소스 코드, 동일한 메소드, Builder패턴의 역할, ConcreteBuilder의 역할, Director의 역할, Client의 역할, 순차다이어그램, Director소스 코드 확인, Builder클래스를 수정하는 것
11.56분 디자인 패턴들 part5
Bridge, Strategy, Composite

Bridge패턴의 역할, 기능의 클래스 계층, 기능을 추가하기 위해 만들어진 계층, 구현의 클래스 계층, 클래스 계층 등장, Bridge패턴의 예제, 4개의 클래스, Display와 CountDisplay는 기능의 클래스 계층, DisplayImpl과 StringDisplayImpl는 구현의 클래스 계층, Display클래스의 소스, 인수로 전달된 인스턴스, open, print, close메소드, 메소드를 실행하기 위해 impl필드의 구현 메소드 사용, CountDisplay클래스 소스, multiDisplay추가, DisplayImpl클래스 소스, StringDisplayImpl클래스 소스, Main클래스 소스, 변수 d1, d2, d3, d3는 multiDisplay도 호출, Abstraction역할, RefinedAbstraction역할, Implementor역할, ConcreteImplementor역할, 기능을 추가 할 경우, 상속과 위임, 예제에서 위임 사용, Strategy패턴, Strategy패턴을 사용한 게임 예제, Hand클래스 소스, Hand클래스의 인스턴스 3개 작성, 가위바위보의 승패 비교, fight메소드, 퍼센트 연산자 사용, Strategy인터페이스, study메소드, WinningStrategy클래스, random이용, ProbStrategy클래스, history필드, getSum, study메소드, Player클래스, win, lose, even메소드, Main클래스, player1과 player2, for문 사용, Robot의 예제, Robot클래스 소스, RobotA와 RobotB 각각 attack과 move구현, 새로운 내용으로 변경을 위해 기존 코드 수정, 기능이 중복되는 상황, 새로운 Robot을 추가, Robot설계의 문제 해결, 구체적인 이동방식과 공격방식을 담은 클래스, Robot클래스에 setMovingStrategy와 setAttackStrategy메소드 정의, 계선된 설계를 코드로 변경, MovingStrategy인터페이스 선언, AttackStrategy인터페이스 선언, Client클래스 소스, Strategy Pattern의 각 역할, Strategy인터페이스, ConcreteStrategy역할, Context역할, Composite패턴, Entry클래스, Entry클래스의 소스, 하위클래스인 File과 Directory, getName메소드 하위클래스에서 구현, getSize메소드 하위클래스에서 구현, add 구현, printList메소드, toString메소드, File클래스 소스, Directory클래스 소스, getSize메소드 보기, add메소드 보기, printList메소드 보기, FileTreatmentException클래스
12.56분 디자인 패턴들 part6
Composite, Decorator

Composite패턴의 Main클래스 소스, 디렉토리 계층 확인, usr디렉토리에 새로운 디렉토리 생성, add메소드 구현 방법, Entry클래스에서 구현하고 에러를 넘겨주는 방법, Entry클래스에서 구현하고 아무것도 실행하지 않는 방법, Entry클래스에서 선언하지만 구현하지 않는 방법, Directory클래스에만 add를 넣는 방법, Composite패턴의 구조, Computer모델링 하는 예제, Keyboard, Body, Monitor클래스 정의, 컴퓨터클래스 부품을 표현한 클래스 다이어그램, 합성관계 표시, Keyboard, Body, Monitor클래스의 코드, Computer클래스의 코드, addBody, addKeyboard, addMonitor메소드, Client클래스의 코드, 설계의 문제점, Speaker객체를 지원할 수 있도록 Computer클래스를 확장하는 방법, Speaker클래스 코드, Speaker클래스를 지원하는 Computer클래스 코드, Computer클래스의 코드를 변경해야만 하는 설계, ocp를 준수할 수 있도록 개선한 Computer클래스의 클래스 다이어그램, ComputerDevice클래스 정의, Computer클래스도 ComputerDevice의 하위클래스로 정의, ComputerDevice추상클래스 코드, 변경된 Computer클래스 확인, addComponent메소드, 개선된 Computer클래스를 이용하는 Client클래스 코드, Speaker클래스를 ComputerDevice의 하위클래스로 구현, Client에 Speaker추가된 것 확인, Composite Pattern의 각 역할, Decorator패턴, 문자열 주변에 장식을 표시하는 예제, Display는 문자열 표시용 추상클래스, Display클래스의 코드, show메소드, StringDisplay클래스 코드, Border클래스 코드, SideBorder클래스, getColumns메소드-문자수 계산, getRows메소드, getRowText메소드, FullBorder클래스 코드, makeLine메소드, Main클래스 코드, 인스턴스 b1, b2, b3의 관계 확인, 네비게이션 예제, RoadDisplay클래스 소스, draw메소드 구현, 소스 코드의 문제점, 도로 표시 기능을 추가로 구현하는 경우, RoadDisplayWithTraffic클래스 정의, RoadDisplay에서 상속받은 draw메소드 오버라이드, RoadDisplayWithTraffic클래스 코드, 여러가지 추가기능을 조합해야 하는 경우, LaneDecorator와 TrafficDecorator를 이용한 설계, Display클래스, DisplayDecorator클래스, LaneDecorator클래스, TrafficDecorator클래스, Client클래스 소스 코드 확인, 동일한 Display클래스를 통해 도로 정보 표시, 교차로를 표시하는 기능을 추가하려면 CrossingDecorator클래스 추가, 내용은 다른 Decorator클래스와 유사, 추가기능을 동적으로 생성하는 예제, Decorator Pattern의 각 역할
13.53분 디자인 패턴들 part7
Visitor, Chain of Responsibility

Visitor패턴, 데이터구조와 처리 분리, Visitor패턴의 예제를 위한 클래스다이어그램, Visitor클래스, Element, ListVisitor, Entry의 하위 클래스 File과 Directory, Visitor클래스 자세히 보기, visit라는 동일한 이름의 메소드를 2개 선언, Visitor클래스의 소스 코드, Element인터페이스, Entry클래스, accept를 실제로 구현하는 Entry의 하위클래스, add메소드는 Entry클래스에서 예외처리, iterator메소드 Entry클래스에서 예외처리, File클래스, accept메소드, Directory클래스, iterator메소드, ListVisitor클래스, ListVisitor클래스의 소스 코드, visit file 메소드, visit directory 메소드, File클래스 소스 코드, Main클래스 소스 코드, ListVisitor의 인스턴스를 사용, File클래스와 Directory클래스, ListVisitor의 관계, Entry는 Element구현, 상호 호출에 관한 내용, 한 Directory에 2개의 File이 있을 때의 처리, Directory인스턴스나 File인스턴스는 accept메소드 호출, Visitor패턴의 각 역할, Visitor의 역할, ConcreteVisitor의 역할, Element의 역할, ConcreteElement들의 역할, ObjectStructure의 역할, Visitor패턴의 메소드 호출, 더블 디스패치(double dispatch), OCP, 주의할 점, 새로운 ConcreteVisitor의 역할 추구, ConcreteElement의 역할 추가는 복잡, 데이터 구조의 요소에 대한 처리를 따로 분리, Visitor패턴에 대한 정리, Chain of Responsibility패턴, Chain of Responsibility패턴을 사용한 예제, Trouble클래스의 소스 코드, Support클래스, Support클래스의 소스 코드, resolve메소드, NoSupport클래스, LimitSupport클래스, OddSupport클래스, SpecialSupport클래스, Main클래스, setNext메소드 사용, Chain of Responsibility패턴의 각 역할, Handler의 역할, ConcreteHandler의 역할, Client의 역할, Chain of Responsibility패턴을 사용하지 않을 경우, Chain of Responsibility패턴을 사용할 때 고려할 점, Chain of Responsibility 정리
14.56분 디자인 패턴들 part8
Facade, Mediator

Facade패턴, 상호 관련된 클래스 제어, 사용자의 웹페이지를 작성하는 예제, Database클래스, Database클래스의 소스 코드, HtmlWriter클래스의 소스 코드, title메소드 제일 먼저 호출, PageMaker클래스 소스 코드, Main클래스 소스 코드, Facade패턴으로 생각한 역할, 시스템을 구성하는 역할, Facade의 역할, 인터페이스의 수가 적은 것, 확장시켜서 Facade패턴 적용, 추상팩토리 패턴과 관련, Facade패턴 정리, Mediator패턴, Mediator패턴의 예제 클래스 다이어그램, 사용자 Login인 경우, 게스트 Login인 경우, OK나 Cancle버튼은 각각의 다른 클래스로 정의, 다수의 오브젝트 사이를 조정해야 할 경우 Mediator패턴 사용, 예제의 클래스 살펴보기, LoginFrame의 구성, Mediator인터페이스, createColleagues메소드, colleagueChanged메소드, Colleague인터페이스, setMediator메소드, setColleagueEnabled메소드, ColleagueButton클래스, mediator필드, setColleagueEnabled메소드, ColleagueTextField클래스, textValueChanged메소드, ColleagueCheckbox클래스, LoginFrame클래스, createColleagues메소드, colleagueChanged메소드, userpassChanged메소드, LoginFrame의 생성자 부분, 리스너의 설정 수행, colleagueChanged메소드 내용 보기, Main클래스, Mediator패턴을 보고 각 역할 알아보기, ConcreteMediator의 역할, Colleague인터페이스의 역할, ConcreteColleague의 역할, Mediator패턴의 예제, 미디어플레이어의 주요기능, 각 영역을 별도의 클래스로 구현-의존관계 형성, 재사용이 어려운 단점, 함께 사용되는 클래스가 증가할수록 개별 클래스의 수정이 어려워지는 단점, 문제점 해결을 위해 Mediator패턴 사용, VideoListUI의 소스 일부분 확인, VideoMediator의 소스 일부분 확인, MediaController와 VideoMediator의 의존 부분, Mediator패턴의 단점, 추상 Mediator클래스의 재사용, select메소드와 volumeChanged메소드의 구현, Mediator패턴 정리
15.55분 디자인 패턴들 part9
Observer 패턴

Observer패턴, 예제를 위한 클래스 다이어그램 확인, Observer인터페이스, update메소드, NumberGenerator클래스, addObserver메소드, notifyObservers메소드, RandomNumberGenerator클래스, DigitObserver클래스, GraphObserver클래스, Main클래스를 보며 Observer사용 확인, execute를 할 경우, 여러가지 방식으로 성적을 출력하는 예제, ScoreRecord클래스와 DataSheetView클래스 필요, ScoreRecord클래스의 소스 코드, DataSheetView클래스 소스 코드, Client클래스 소스 코드, addScore메소드 호출, 주의점, addScore메소드를 호출할 때 dateSheetView의 update메소드 호출, 성적을 다른 형태로 출력하고 싶을 경우의 변경 작업, 최소, 최대값만 출력, ScoreRecord부터 소스 변경, MinMaxView클래스 추가, displayMinMax메소드는 Collections클래스 이용, ocp에 위배가 되는 작업, 동시에 또는 순차적으로 성적을 출력하는 경우, 적용한 ScoreRecord클래스 소스, dataSheetViews필드, setMinMaxView메소드, Client클래스, 출력 변경을 새로운 클래스에 통보할 때마다 반복적으로 발생, 공통기능을 상위클래스 및 인스턴스로 일반화 시키고 활용해 ScoreRecord구현, 개선한 ScoreRecord클래스 다이어그램, Subject클래스 정의, ScoreRecord클래스의 소스 구성, 추상클래스 Subject, attach메소드와 detach메소드, ScoreRecord클래스, DataSheetView클래스와 MinMaxView클래스는 기존 코드와 동일, Client클래스 소스 코드, 성적변경에 관심이 있는 대상객체들의 관리는 Subject클래스에서 구현, 목록출력과 최소/최대값 출력, 합계와 평균 출력, StatisticsView클래스, update메소드, displayStatistics메소드, Client클래스의 소스 코드, Observer패턴만볼 수 있도록 구성한 클래스 다이어그램, Observer의 역할, Subject의 역할, ConcreteSubject의 역할, ConcreteObserver의 역할, Subject클래스의 notifyObservers메소드 호출, 다음 예제, StatusChecker클래스의 소스 코드, 변경된 클래스 다이어그램 확인, 상태가 변경될 때 임의의 객체에게 변경사실 통보, Observer패턴 적용, notifyStatus메소드가 등록된 Observer객체의 omAbnormalStatus메소드 호출, StatusSubject클래스, notifyStatus메소드, StatusChecker클래스, StatusObserver인터페이스, Observer를 등록하는 부분, Observer패턴을 적용할 때의 장점, Observer객체에게 상태를 전달하는 방법
16.60분 디자인 패턴들 part10
Observer, Memento, state

Observer패턴, Subject객체 구분, OnClickListener인터페이스가 Observer인터페이스, onClick했을 때 login할 수 있도록 구현, onCreate메소드, onClick메소드에서 id값 사용, Observer패턴을 구현할 때 고려해야 할 사항, 주제 객체의 통지 기능 실행 주체, Client에서 여러 StatusChecker를 두고 조건을 만족하는지 확인, Subject객체에서 직접 통지기능을 실행하는 것이 구현에 유리, 옵저버 인터페이스의 분리, EventObserver인터페이스, ConcreteObserver클래스는 모든 메소드 구현, 통지 시점에서의 주제 객체 상태, SomeSubject를 상속받고 있는 AnySubject클래스, 옵저버 객체가 올바르지 않은 값을 사용하는 문제 발생, 템플릿 메소드 패턴을 적용한 예, 상위클래스가 제어의 흐름 결정, 옵저버 객체의 실행 제약 조건, notifyToObserver메소드, 옵저버 인터페이스를 정의할 때는 옵저버 메소드의 실행 제한에 대한 기준 필요, Observer패턴의 정리, Memento패턴, 캡슐화의 파괴에 빠지지 않고 저장과 복원 실행, undo, redo, history, snapshot 실행, Memento패턴의 예제 클래스 다이어그램, 게임규칙 살펴보기, 프로그램에서 Memento를 어떻게 사용하는지 확인, Memento클래스 보기, money필드와 fruits필드 보기, Memento클래스의 소스 코드, addFruit메소드, Gamer클래스 소스 코드, 중심이되는 bet메소드, createMemento메소드, restoreMemento메소드, Main클래스 소스 코드, Memento패턴 적용, createMemento를 통해 현재상태 저장, 시퀀스 다이어그램으로 나타내서 학인, Memento패턴의 역할, Originator의 역할, Memento의 역할, wide interface: 넓은 인터페이스, narrow interface: 좁은 인터페이스, Caretaker의 역할, Memento역할이 갖는 좁은 인터페이스만 사용, 자바의 엑세스 제어 기능 사용, Caretaker역할의 Main클래스, Main클래스가 할 수 있는 일, Memento의 개수와 유효기간, Caretaker의 역할과 Originator의 역할을 분리하는 이유, Memento패턴의 정리, State패턴, 상태를 클래스로 표현, State패턴을 사용한 예제, 예제를 유사코딩으로 작성, State패턴을 사용해 유사코딩으로 작성, 두 코드의 차이점, 예제의 클래스 다이어그램, State인터페이스, 상태 의존 메소드의 집합, DayState클래스, DayState클래스의 소스, doClock메소드, NightState클래스의 소스, Context인터페이스, 추상메소드들 선언, SafeFrame클래스 소스, 필드와 메소드 살펴보기, SafeFrame생성자 보기, Panel생성 후 버튼 저장, actionPerformed메소드, 리스너 설정 부분 확인, 버튼이 클릭되었을 때 호출되는 메소드, state패턴을 사용하지 않고 프로그래밍을 했을 경우, changeState메소드
17.1시간 1분 디자인 패턴들 part11
state 패턴

State패턴의 예제, doUse메소드의 다른점, setClock을 통해 State가 바뀌는 과정 확인, Main클래스 소스 코드, State패턴의 클래스 다이어그램을 보며 각 클래스의 역할 확인, State의 역할, ConcreteState의 역할, Context의 역할, Divide and conquer, 상태가 많은 시스템에서 State패턴의 장점 발휘, State패턴은 시스템 상태를 클래스로 표현, SafeFrame클래스의 setClock메소드와 State인터페이스의 doClock메소드의 관계, 상태의 의존한 처리 이해, 상태 전환의 관리, SafeFrame클래스가 changeState메소드 구현, 상태 전환의 장점과 단점, 상태 전환은 SafeFrame클래스에 맡기기, Context역할이 모든 ConcreteState의 역할을 알아야 하는 단점, State패턴을 사용하므로 얻는 장점, state필드의 값이 시스템의 상태를 결정, 새로운 상태 추가, 특정 메소드 추가, 클래스의 수정이 많지만 에러를 줄여주는 역할, 인스턴스활용 부분 소스 코드, this가 addActionListener와 doUse에 전달될 때의 차이, State패턴의 다음 예제, 선풍기를 표현한 상태 다이어그램, 상태의 한 종류 Pseudo state, 상태 머신 다이어그램의 시작과 종료, 상태진입, 특정이벤트 발생 후 조건을 만족할 경우, 진입 이후 수행해야 하는 액션, 선풍기가 OFF상태일 경우, 상태 머신 다이어그램의 해석, 선풍기가 ON이나 WORKING상태일 경우, Active라는 복합상태 이용, 복합상태 안의 ON상태, 형광등 예제, 상태 머신 다이어그램으로 표현, 상태 머신 다이어그램으로 실제 코드 만들기, 변수 설정, Light클래스 구현, Client클래스, 새로운 요구사항이 있을 때의 코드 변경, 상수 추가, 두번째 Light클래스, 각 메소드에 SLEEPING상태 추가, 변하는 부분을 찾아서 캡슐화, 형광등의 상태 머신 다이어그램, 구조가 Strategy패턴과 유사, 코딩하기, State인터페이스, ON클래스, OFF클래스, 상태진입도 각 상태에서 처리, Light클래스를 수정한 코드, state의 메소드 이용, 개선할 점, Singleton패턴을 사용해 ON과 OFF클래스 변경, State Pattern의 콜라보레이션 다이어그램, State인터페이스의 역할, 각각의 State확인, request메소드, State패턴을 적용한 Light클래스, state변수의 변경, State패턴의 새로운 예제, 자판기에 들어갈 소프트웨어의 내용, VendingMachine클래스로 구현, insertCoin메소드, select메소드, SOLDOUT추가, 각 메소드의 코드, 상태 패턴을 적용한 자판기 프로그램의 클래스 다이어그램, 상태패턴이 적용된 VendingMachine의 소스 코드, insertCoin과 select메소드, NoCoinState클래스, increaseCoin메소드, select메소드, SelectableState클래스, 상태패턴 적용 전과 비교, Context에서 직접 상태 변경하는 코드, 상태객체에서 Context의 상태를 변경할 경우, State패턴의 정리
18.55분 디자인 패턴들 part12
Flyweight, Proxy

Flyweight패턴, 무게의 개념은 메모리의 사용량, new Something문장, 이미 만들어져 있는 인스턴스 공유, Flyweight패턴을 사용한 예제 클래스 다이어그램, BigChar클래스, BigCharFactory클래스, BigString클래스, BigChar클래스의 소스 코드, fontdata, 복잡한 생성자, BigCharFactory클래스의 소스 코드, 공유의 방법 실현, pool필드는 인스턴스 관리, put메소드, get메소드, singleton패턴을 사용해서 구현, getInstance메소드, getBigChar메소드, pool이용, new를 사용해서 BigChar의 인스턴스 생성, synchronized, BigString클래스의 소스 코드, for문을 돌며 factory.getBigChar메소드 호출, new연산자를 이용하면 인스턴스 공유 불가능, bigchars의 배열 보기, Main클래스의 소스 코드, BigString인스턴스를 만들고 표시하는 것 구현, Flyweight패턴의 각 역할, Flyweight의 역할, FlyweightFactory의 역할, Client의 역할, Flyweight패턴은 인스턴스를 공유, 주의점, BigString에서 색 정보를 제공할 경우, Intrinsic, extrinsic, 인스턴스와 garbage collection, 인스턴스에 대한 참조 제거, 메모리 이외의 리소스, 인스턴스를 new할 경우, Flyweight패턴 정리, Proxy패턴, Proxy패턴을 사용한 예제, setPrinterName, getPrinterName메소드, print메소드를 호출해 Printer클래스의 인스턴스 생성, Printable인스턴스 정의, Printer클래스의 소스 코드, heavyJob메소드, Printable인터페이스, PrinterProxy클래스 소스 코드, realize메소드, 대리인의 인스턴스 이름 설정, 위임 과정, 생성되지않는 Printer의 인스턴스, synchronized메소드로 하지 않은 경우, Main클래스의 소스 코드, Printer클래스의 생성자, PrinterProxy클래스를 수정하기위한 방법, real필드 변경, Main에 PrinterProxy생성부분 변경, Proxy패턴의 각 역할, Subject의 역할, Proxy의 역할, RealSubject의 역할, Client의 역할, 분리해서 개별적으로 수정 가능, 위임, 투과적, Proxy패턴의 종류, Virtual Proxy(가상 프록시), Remote Proxy(원격 프록시), Access Proxy, Proxy패턴의 예제, 예제를 Proxy패턴으로 구현한 ProxyImage클래스, draw메소드, ListUI클래스, Proxy패턴의 정리
19.1시간 52분 디자인 패턴들 part13
Command, Interpreter

Command패턴, 명령 표현, Command패턴을 사용한 그림그리기 예제, 클래스 다이어그램 확인, 점을 그리는 명령-DrawCommand클래스의 인스턴스로 생성, 3가지 패키지로 구성, Command인터페이스의 소스 코드, execute메소드 호출, MacroCommand클래스의 소스 코드, commands필드, append메소드, undo메소드, clear메소드, DrawCommand클래스의 소스 코드, execute메소드, Drawable인터페이스, DrawCanvas클래스의 소스 코드, paint메소드, draw메소드, Main클래스의 소스 코드, history필드, canvas필드, clearButton필드, 생성자에서 전체화면 구성, 이벤트리스너 설정, 버튼의 레이아웃, actionPerformed메소드, mouseMoved와 mouseDragged메소드, 윈도우 리스너 인터페이스를 구현하기 위한 메소드, 버튼 예제, 예제 클래스 다이어그램을 기반으로 소스 코드 작성, Button클래스, 버튼을 눌렀을 때 다른 기능을 실행하는 경우, 버튼을 누르는 동작에 따라 다른 기능 실행, Button클래스에 setMode메소드 추가, Client클래스 확인, 새로운 기능의 추가나 변경을 하더라도 Button클래스를 그대로 사용하기 위한 방법, pressed메소드 수정, 여러가지 기능을 수행하는 버튼클래스의 설계 예제, 예제를 구현한 소스 코드 확인, Button클래스, LampOnCommand클래스, Alarm클래스, Client클래스, 동일한 pressed메소드 호출, Command패턴 적용, Button클래스의 pressed메소드, 버튼을 한번 눌렀을 때 램프를 켜고 두번 눌렀을 때 램프를 끄는 기능의 구현, Lamp클래스에 turnOFF메소드 추가, LampOffCommand클래스 추가, Client클래스, setCommand를 통해 lampOffCommand설정, LampOffCommand클래스 새롭게 정의, 파일open과 파일close가 있다고 가정, Command Pattern을 사용해 메뉴아이템 재사용, Command패턴에서 각각의 역할, ConcreteCommand의 역할, Receiver의 역할, 첫번째 예제의 Command패턴 적용부분 확인, Main클래스 소스 코드, Main클래스와 DrawCanvas클래스가 execute메소드 호출, 시퀀스 다이어그램 확인, 그림그리기에 색을 설정하는 기능 추가하기, ColorCommand클래스 생성, Drawable인터페이스 수정, DrawCanvas에 적용, setColor메소드 추가, Main클래스에 3개의 버튼 추가 생성, 버튼 버튼박스에 추가, redButton이 눌렸을 때의 Command, blueButton과 greenButton동일 작업, undo기능 추가, Main클래스에 undo버튼 추가, Command패턴의 정리, Interpreter패턴, 변화가 생겼을 때 어느 레벨의 프로그램을 수정할 것인지 확인, 미니 언어 설명, 미니 언어로 기술된 미니 프로그램의 예, 미니 언어의 문법, 미니 언어를 구분해석하는 예제, 예제 프로그램의 클래스 다이어그램, Node클래스의 소스 코드, ProgramNode클래스, Token-구문해석의 처리 단위, CommandListNode클래스, CommandNode클래스, RepeatCommandNode클래스, parse메소드, PrimitiveCommandNode클래스, Context클래스, nextToken메소드 호출, Main클래스, parse를 끝내고 node출력, Interpreter패턴의 각 역할, TerminalExpression의 역할, NonTerminalExpression의 역할, Context의 역할, Client의 역할, 미니 언어의 다른 종류, Interpreter를 만들 때의 오류, 프로그램을 수정해서 실행, InterpreterFacade클래스, parse메소드, ExecutorFactory인터페이스, Context클래스에서 ExecutorFactory구현, Node클래스에서 Executor구현, ProgramNode클래스, CommandNode클래스, RepeatCommandNode클래스, CommandListNode클래스, PrimitiveCommandNode클래스, TurtleCanvas클래스, TurtleExecutor클래스, initialize호출, Main클래스, actionPerformed메소드, parseAndExecute메소드, Interpreter패턴 정리, Iterator패턴, Iterator와 Visitor패턴을 같이 사용할 경우, Composite패턴, Factory Method, Adapter패턴, Template Method, Factory Method의 연관 패턴, Singleton패턴, Prototype의 연관 패턴, Builder의 연관 패턴, Abstract Factory, Bridge, Strategy패턴, Chain of Responsibility, Mediator
20.1시간 27분 UML 다이어그램
다이어그램 종류, 유스케이스, 컴포넌트, 복합구조, 활동, 상태, 시퀀스, 통신, 타이밍, 상호작용 개요, 배치

UML알아보기, UML의 다이어그램의 종류와 특성, 여러가지 다이어그램을 클래스 다이어그램으로 구성, UML2.0을 구성하는 다이어그램, 구조 다이어그램, Class다이어그램, Object다이어그램, Deployment다이어그램, Package다이어그램, Component다이어그램, Composite structure다이어그램, 행위 다이어그램, Use case다이어그램, State machine다이어그램, Activity다이어그램, Interaction다이어그램, Sequence와 Communication다이어그램, Interaction overview다이어그램, Timing다이어그램, 요구사항 정의 단계에서 사용되는 다이어그램, 분석 단계에서 사용되는 다이어그램, 설계 단계에서 사용되는 다이어그램, 구현과 테스트 단계에서 사용되는 다이어그램, Package다이어그램은 요구사항 정의, 분석, 설계 단계에서 사용, 유스케이스 다이어그램의 예제, 시스템과 상호작용하는 대상을 액터로 정의, 유스케이스로 포함되지 않은 것은 요구사항에서 제외, Timer액터의 역할, 확장된 유스케이스 다이어그램 확인, 액터의 일반화, Use case의 일반화, Use case의 포함, Use case의 확장, 액터간의 연관관계, 클래스 다이어그램, 도서대출 시스템을 구성하고 있는 클래스, 능동(actiive)클래스, boundary, control, entity, 속성과 연산이 명시된 클래스 다이어그램, 설계단계의 클래스 다이어그램 활용방법, 파트클래스의 표현, 객체 다이어그램, 객체의 표현방법 확인, 4개의 객체는 교통수단 클래스로 instantiation의존관계, 패키지 다이어그램, packageElement, 클래스를 패키지로 조직화한 예제, 컴포넌트 다이어그램, 소프트웨어 아키텍쳐를 표현할 때 사용, 인터페이스, 인터페이스를 구성하는 연산에의해 정의, 복합구조 다이어그램, 파트, 포트, 연결자의 개념을 이용, 포트-파트간의 통신을 위한 연결지점, 연결자, 활동 다이어그램, 활동노드, 객체노드, 제어노드, 판단노드, 병합노드, 포크노드, 조인노드, 제어흐름, 객체흐름, 예외처리가 추가된 활동 다이어그램, orderCancelRequest, 활동 다이어그램을 파티션과 구획면을 이용하여 나타낸 그림, 파티션, Invoice, 상태 다이어그램, 휴대폰의 종료버튼을 눌렀을 경우의 예제, 상태, 시작상태, 종료상태, 전이-객체의 상태가 다른 상태로 변경, 이벤트/액션, 복잡한 상태 다이어그램의 예제, 상태 내부 확인, 복합 상태(Operating), 상태 내부의 do/액션, 상태를 벗어날 때마다 수행되는 Exit/액션, 복합 상태 내부, 직교복합 상태, Motor의 상태와 ArrivalSensor의 상태, 히스토리 상태, 시퀀스 다이어그램, 생명선, 메시지, 메시지의 전달 순서, 동기적 메시지, 비동기적 메시지, 복잡한 시퀀스 다이어그램 예제, 상호작용 이름, 발견된 메시지, 복합적 부분, 통신 다이어그램, 메시지 전달 순서는 메시지 앞에 순번을 명시, 타이밍 다이어그램, 생명선 가로방향으로 표시, 상호작용 개요 다이어그램, 활동 다이어그램의 일종, 배치 다이어그램, 노드, 통신 경로, 수행 환경

강의목록 다운로드 1:1 강의 질문&답변

💬

알지오 학습·수강 도우미

운영진이 확인한 안내를 자세히 보고, 필요하면 바로 상담하세요.

상담 상태 확인 중