Software Engineering 79

[헤드퍼스트 디자인 패턴] 6. 커맨드 패턴

에릭 프리먼 님의 "헤드퍼스트 디자인 패턴" 책을 정리한 포스팅 입니다 1. 커맨드 패턴요청자와 수행자를 분리하는 패턴요청을 하나의 객체로 캡슐화하여, 서로 다른 요청을 매개변수로 처리 요소구성요소역할 설명Receiver실제 작업을 수행하는 객체Command작업을 캡슐화한 인터페이스 또는 클래스Invoker커맨드 객체를 받아 실행을 요청하는 객체 장점요청을 객체로 기능 확장 (저장, 취소, 재실행 등)요청 내역을 유연하게 구성 가능 (큐잉, 로깅, 트랜잭션 처리 등) 2. 예제: 리모컨리모컨 (Receiver)예제) RemoteControl더보기public class RemoteControl { Command[] onCommands, offCommands; Command undoCommand;..

[헤드퍼스트 디자인 패턴] 5. 싱글턴 패턴

에릭 프리먼 님의 "헤드퍼스트 디자인 패턴" 책을 정리한 포스팅 입니다 1. 싱글턴 패턴애플리케이션 전체에서 하나의 인스턴사만 존재하도록 보장하는 디자인 패턴항목설명단 하나의 객체만 필요한 경우불필요한 객체 생성을 방지하여 자원 절약결과의 일관성 유지여러 인스턴스가 존재하면 데이터 충돌 및 상태 불일치 위험 발생전역 접근 가능어디서든 동일한 인스턴스에 접근 가능 → 사용 편리지연 초기화 가능필요할 때만 객체 생성 → 메모리 등 리소스 효율성 증가 예시) 구현더보기public class Singleton { private static Singleton uniqueInstance; private Singleton() {} public static Singleton getInstance() {..

[헤드퍼스트 디자인 패턴] 4. 팩토리 메서드 패턴

에릭 프리먼 님의 "헤드퍼스트 디자인 패턴" 책을 정리한 포스팅 입니다 1. 기존 문제: new 키워드new 키워드를 통해 직접 객체 생성 시 → 특정 구현체에 강하게 의존하게 됨⚠️ OCP, DIP 위반 → 코드 변경에 취약, 테스트 어려움 2. 팩토리 메서드 패턴객체를 생성을 서브클래스에서 위임하는 패턴클라이언트 코드와 구현체 생성 코드를 분리시킴 추상 클래스화서브클래스에 피자 생성을 위임함어떤 종류의 피자를 만들지에 대한것은 어떤 서브클래스를 생성했느냐에 따라 결정됨클라이언트는 어떤 구현이 생성되는지 몰라도 됨 예제) PizzaStore더보기추상클래스public abstract class PizzaStore { public Pizza orderPizza(String type) { ..

[헤드퍼스트 디자인 패턴] 3. 데코레이터 패턴

에릭 프리먼 님의 "헤드퍼스트 디자인 패턴" 책을 정리한 포스팅 입니다 1. OCP (Open/Closed Principle) 새로운 행동을 추가하여 확장기존 코드를 수정 필요 없음 2. 데코레이터 패턴클래스에 기능을 추가할 때, 상속이 아닌 객체를 감싸는 방식으로 확장하는 구조항목설명상속의 문제점- 슈퍼클래스에 모든 기능을 넣으면 → 일부 서브클래스에는 불필요하거나 부적절한 기능까지 상속됨- 기능 변경 시 상속 구조 전체에 영향 발생→ 해결 방법- 기능을 데코레이터 객체로 분리- 원래 객체를 감싸고, 필요한 기능만 동적으로 위임하여 확장형식- 데코레이터 클래스는 원래 객체와 동일한 인터페이스 또는 슈퍼클래스를 구현- 따라서 감싼 객체처럼 사용 가능이점- 기능을 동적으로 추가 가능- 여러 데코레이터 중첩..

[헤드퍼스트 디자인 패턴] 2. 옵저버 패턴

에릭 프리먼 님의 "헤드퍼스트 디자인 패턴" 책을 정리한 포스팅 입니다 1. 옵저버 패턴한 객체의 상태 변화가 있을 때, 그 객체에 의존하는 다른 객체들에게 자동으로 알림을 보내고, 이를 갱신할 수 있게 해주는 패턴일대다 형식으로 객체간 관계 정의 구성 요소역할(Role)설명Subject- state: 상태를 보유하고 관리함- notify: 상태 변경 시 옵저버들에게 알림- 옵저버 등록/제거 기능 제공Observer- Subject의 상태에 의존함- Subject의 상태 변경 시 알림을 받고 처리 (update 메서드 등 구현) 느슨한 결합서로 강하게 연결되어 있지 않지만, 상호작용 할 수 있는 관계구분설명추상화- Subject는 Observer 인터페이스에만 의존- 구체 구현을 몰라도 동작 가능유연성-..

[헤드퍼스트 디자인 패턴] 0. 디자인 패턴이란

에릭 프리먼 님의 "헤드퍼스트 디자인 패턴" 책을 정리한 포스팅 입니다 1. 디자인 패턴객체지향 설계에서 자주 발생하는 문제에 대한 해결책코드의 재사용성, 관리 용이성, 유연성을 높일 수 있음 장점장점설명서로 이해할 수 있는 용어 제공개발자 간 공통된 개념과 용어로 의사소통이 쉬워짐표준화된 해결방법 제공반복되는 문제에 대해 검증된 해결책을 제공함유연성 및 유지보수 용이성변경에 강하고, 코드의 수정 및 확장이 용이함구조 개선코드 구조를 명확히 하여 가독성과 재사용성을 높임 2. 객체지향 기초객체와 클래스를 중심으로 소프트웨어를 설계하고 구현하는 방법론 주요 개념개념정의추상화중요한 정보만 드러내고 불필요한 세부 사항은 숨김- 인터페이스 중심 설계: 구현 세부사항을 숨기고 시스템 유연성과 확장성 확보캡슐화데이..

[헤드퍼스트 디자인 패턴] 1. 전략 패턴

에릭 프리먼 님의 "헤드퍼스트 디자인 패턴" 책을 정리한 포스팅 입니다 1. 오리 시뮬레이션 게임Duck 클래스를 슈퍼클래스로 생성각 오리 종류를 서브클래스로 두어 Duck 클래스를 상속함 (MallardDuck, RedheadDuck, RubberDuck) 심각한 문제 발생슈퍼클래스에 추상메서드 추가 시, 모든 서브클래스에서 구현이 강제됨몇몇 서브클래스에만 적용되어야 할 메서드일 경우, 논리적으로 오류가 발생함 예: fly()더보기// 상위 클래스abstract class Duck { public abstract void fly(); // 👈 모든 Duck에게 fly() 강제 public abstract void quack();}// MallardDuck는 날 수 있음class Malla..

[Pro Git] 3-1. Git 브랜치: 브랜치란 무엇인가

Scott Chacon & Ben Straub 님의 "Pro Git" 책을 정리한 포스팅 입니다. 1. 브랜치란 무엇인가 브랜치 코드의 독립적인 라인 원본 코드를 변경하지 않고 복사본에서 작업할 수 있게 해줍니다. 개별적으로 개발을 진행한 후, 이를 원본 코드와 병합하여 최종 제품을 완성합니다. Blob 객체 Git에서 파일의 내용을 저장하는 객체입니다. 파일의 이름이나 경로 정보는 포함하지 않습니다. 일종의 파일에 대한 스냅샷 파일을 Staging Area에 추가할 때, 파일의 내용을 Blob 객체로 변환하고 저장합니다. 커밋 객체 특정 시점의 프로젝트 상태를 나타내는 객체입니다. Staging Area에 있는 데이터의 스냅샷에 대한 포인터 Staging Area에 있는 파일들의 상태를 스냅샷으로 ..

[Pro Git] 2-6. Git의 기초: 태그

Scott Chacon & Ben Straub 님의 "Pro Git" 책을 정리한 포스팅 입니다. 1. 태그 특정 커밋을 가리키는 고정된 참조입니다. 항상 동일한 커밋을 가리킵니다. 보통 릴리즈할 때 사용합니다. 조회 git tag (-l) git tag -l "pattern" git show git show "tag name" 태그의 상세 정보를 볼 수 있습니다. 태그 정보, 커밋 정보 제공 태깅 Annotated tag 태그를 만든 저자 이름, 이메일, 생성 날짜, 메시지를 포함합니다. $ git tag -a v1.4 -m "my version 1.4" 생성 -a 옵션을 추가하여 생성합니다. 옵션 -m : 메시지를 추가합니다. Lightweight tag 단순히 커밋을 가리키는 포인터로 추가적인 ..