수달이네 기술 블로그

1. 소프트웨어 설계(객체지향, 디자인 패턴) 본문

공부/정보처리기사

1. 소프트웨어 설계(객체지향, 디자인 패턴)

슬픈 수달이 2026. 5. 1. 18:46

객체 지향

실세계 객체를 속성 + 메서드의 형태로 표현

구성요소: 클래스(class), 객체(object), 메서드(method), 메시지(message), 인스턴스(instance), 속성(property)

객체지향 기법

  • 캡슐화(Encapsulation): 연관된 데이터, 함수를 묶어 감추고, 인터페이스만 드러냄(결합도 ↓, 재사용성 ↑)
  • 상속성(inheritance): 상위 클래스의 속성,메서드를 하위클래스가 물려받음
  • 다형성(Polymorphism): 하나의 메세지에 각 객체가 고유한 방법으로 응답(오버로딩, 오버라이딩)
    • 오버로딩: 매개변수의 유형, 개수를 다르게 하여 다양한 메서드를 생성
    • 오버라이딩: 상위 클래스에서 정의한 메서드를 하위클래스에서 무시하고 재정의
  • 추상화(Abstraction): 공통 성질을 추출해 추상 클래스를 정의(과정, 자료, 제어추상화)
  • 정보 은닉(Information Hiding): 캡슐화로 코드 내부의 정보를 숨김. 필요한 정보만 보냄
  • 관계성(Relationship): 두 개 이상의 엔터티에서 참조관계를 나타냄(연관화, 집단화, 분류화, 일반화, 특수화)

객체지향 설계 원칙(SOLID)

  1. 단일 책임의 원칙(SRP; Single Responsibility Principle): 하나의 클래스는 하나의 책임만
  2. 개방 폐쇄 원칙(OCP; Open Close Principle): 구성요소(컴포넌트, 클래스, 모듈, 함수)가 확장엔 열려있고, 변경엔 닫혀있어야함.
  3. 리스코프 치환의 원칙(LSP; Liskov Substitution Principle): 하위 클래스는 상위클래스로 교체할 수 있어야함.
  4. 인터페이스 분리의 원칙(ISP; Interface Segregation Principle): 사용하지 않는 인터페이스는 구현하지 말아야함.
  5. 의존성 역전의 원칙(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: 정적으로 기능에 대한 처리의 연결이 하드코딩 되면 기능 처리 연결의 변경이 불가능하지만, 동적으로 연결하여 다르게 처리되도록 연결
  • 장점: 코드 변경 최소화, 품질향상, 유연한 대처, 범용적, 원활한 의사소통, 시간단축, 구조파악, 생산성
  • 단점: 객체지향 설계, 구현 위주, 초기 투자 비용 부담.