| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
Tags
- 트랜스포머
- SQL
- LangGraph
- 소프트웨어 개발
- 에이전트
- 기초
- 캐글
- RDBMS
- 머신러닝
- UMAP
- Transformer
- 알고리즘
- 자연어처리
- 랭그래프
- python 기초
- 데이터 시각화
- CLIP
- 생성형 인공지능
- 정보처리기사
- RNN
- TTS
- dementional reduction
- python기초
- 데이터엔지니어
- Python
- CNN
- 힙정렬
- 딥러닝
- 객체지향
- ASR
Archives
- Today
- Total
수달이네 기술 블로그
1. 소프트웨어 설계(객체지향, 디자인 패턴) 본문
객체 지향
실세계 객체를 속성 + 메서드의 형태로 표현
구성요소: 클래스(class), 객체(object), 메서드(method), 메시지(message), 인스턴스(instance), 속성(property)
객체지향 기법
- 캡슐화(Encapsulation): 연관된 데이터, 함수를 묶어 감추고, 인터페이스만 드러냄(결합도 ↓, 재사용성 ↑)
- 상속성(inheritance): 상위 클래스의 속성,메서드를 하위클래스가 물려받음
- 다형성(Polymorphism): 하나의 메세지에 각 객체가 고유한 방법으로 응답(오버로딩, 오버라이딩)
- 오버로딩: 매개변수의 유형, 개수를 다르게 하여 다양한 메서드를 생성
- 오버라이딩: 상위 클래스에서 정의한 메서드를 하위클래스에서 무시하고 재정의
- 추상화(Abstraction): 공통 성질을 추출해 추상 클래스를 정의(과정, 자료, 제어추상화)
- 정보 은닉(Information Hiding): 캡슐화로 코드 내부의 정보를 숨김. 필요한 정보만 보냄
- 관계성(Relationship): 두 개 이상의 엔터티에서 참조관계를 나타냄(연관화, 집단화, 분류화, 일반화, 특수화)
객체지향 설계 원칙(SOLID)

- 단일 책임의 원칙(SRP; Single Responsibility Principle): 하나의 클래스는 하나의 책임만
- 개방 폐쇄 원칙(OCP; Open Close Principle): 구성요소(컴포넌트, 클래스, 모듈, 함수)가 확장엔 열려있고, 변경엔 닫혀있어야함.
- 리스코프 치환의 원칙(LSP; Liskov Substitution Principle): 하위 클래스는 상위클래스로 교체할 수 있어야함.
- 인터페이스 분리의 원칙(ISP; Interface Segregation Principle): 사용하지 않는 인터페이스는 구현하지 말아야함.
- 의존성 역전의 원칙(DIP; Dependency Inversion Principle): 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메세지를 주고받아 관계를 느슨하게 함
- 즉, 클래스가 자주 바뀌면 이것에 의존할 경우 상속 클래스가 다 변해야함 → 추상클래스나 인터페이스를 상속받자
객체지향 분석: 요구사항에 관련된 모든 클래스, 속성, 연산, 관계를 나누어 분석함
- 데이터와 행위는 하나로 나눠 추상화
- 생산성, 변경 용이
객체지향 방법론
| 종류 | 제작자 | 설명 |
| OOSE(Object Oriented SW Eng.) | 야콥슨 | 유스케이스를 모든 모델의 근간으로 활용 |
| OMT(Object Modeling Tech.) | 럼바우 | 그래픽 표기법으로 모델링 • 객체 → 동적 → 기능 모델링 |
| OOD(Object Oriented Design) | 부치 | 설계 문서화, 다이어그램 중심 개발 |
| 코드-요든 방법론 | E-R다이어그램, 객체 행위 모델링 | |
| 위프 브록 방법론 | 분석, 설계간 구분이 없음, 평가 → 설계 연속적 수행 |
디자인 패턴
소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
- 효율성, 유지보수성, 운용성 증가, 프로그램 최적화
구성요소: 패턴 이름, 문제, 솔루션, 사례, 결과, 샘플코드
유형: 생성, 구조, 행위패턴
- 생성:객체 인스턴스 생성에 관여. 클래스 정의와 객체 생성 방식을 구조화, 캡슐화
- Builder(인스턴스 조립)
- Prototype(원형 생성→복사 수정)
- Factory Method(상위 클래스 인터페이스 정의 → 하위클래스 인스턴스 생성)
- Abstract Factory(구체적 클래스에 의존하지 않고, 연관, 의존 객체의 조합 생성)
- Singleton(전역 변수를 사용하지 않고, 객체를 하나만 생성, 한 클래스에 한 객체만)
- 구조: 더 큰 구조 형성 목적
- Bridge: 기능의 클래스 계층과 구현의 클래스 계층 연결 + 구현부에서 추상 계층 분리
- Docorator: 기존 클래스에 필요한 기능을 추가
- Facade: 복잡한 시스템에 단순한 인터페이스 제공
- Flyweight: 다수의 객체로 생성될 경우 모두가 갖는 본질적 요소를 클래스화해 절약, 경량화
- Proxy: 실제 객체에 대한 대리 객체를 만들어 특정 객체로의 접근을 제어
- Composite: 객체들의 관계를 트리 구조로 구성해 부분-전체 계층을 표현
- Adapter: 기존 클래스를 재사용하도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만듦
- 행위: 클래스나 객체가 상호작용 하는 방법과 역할 분담을 다룸
- Mediator: 객체 수가 많을때 통신이 복잡해지므로, 중재자를 두어 통신의 빈도수를 줄이는 패턴
- Interpreter: 언어의 다양한 해석, 구체적으로 구문을 나눈 후 그 구문의 해석을 맡는 클래스를 작서해 여러 형태의 구문을 해석하도록 만드는 패턴
- Iterator: 구현방법 노출 없이, 집합체 내의 iterator를 통해 접근하는 패턴
- Template Method: 특정 작업을 처리하는 일부분을 서브클래스로 캡슐화해 일을 수행
- Observer: 객체의 상태가 변화하면 다른 객체들에 신호가 가 자동으로 내용이 갱선
- State: 상태를 캡슐화해 클래스화하여 그걸 참조하도록함
- Visitor: 각 클래스의 구조로부터 처리기능을 분리해 별도의 클래스를 만들고 해당 클래스의 메소드가 각 클래스를 돌아 작업을 수행
- Command: 기능을 캡슐화해 여러 기능을 실행도록 재사용성이 높은 클래스를 설계
- Strategy: 알고리즘 군을 정의 같은 알고리즘을 하나의 클래스로 캡슐화해 필요할때 사용
- Memento: 클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용하는 디자인 패턴(Undo기능)
- Chain of Responsibility: 정적으로 기능에 대한 처리의 연결이 하드코딩 되면 기능 처리 연결의 변경이 불가능하지만, 동적으로 연결하여 다르게 처리되도록 연결
- 장점: 코드 변경 최소화, 품질향상, 유연한 대처, 범용적, 원활한 의사소통, 시간단축, 구조파악, 생산성
- 단점: 객체지향 설계, 구현 위주, 초기 투자 비용 부담.
'공부 > 정보처리기사' 카테고리의 다른 글
| 2. 소프트웨어 개발(자료구조) (0) | 2026.05.05 |
|---|---|
| 1. 소프트웨어 설계(인터페이스) (1) | 2026.05.04 |
| 1. 소프트웨어 설계(설계, 소프트웨어 아키텍처) (0) | 2026.04.30 |
| 1. 소프트웨어 설계(에자일, UI, 모델링)(정보처리기사 1일차) (0) | 2026.04.30 |
| 1. 소프트웨어 설계(요구사항, UML)(정보처리기사 1일차) (1) | 2026.04.30 |