객체지향 소프트웨어 설계

• 객체지향(OO) = 데이터와 그 데이터를 다루는 동작을 객체라는 단위로 묶어 설계하는 패러다임
  • 로봇 SW의 "센서를 바꿔 끼워도 상위 코드는 그대로"를 가능하게 하는 이론적 기반
• 시험 핵심 출제 포인트
  • 객체지향 4대 특징(캡슐화·상속·다형성·추상화)
  • 클래스 다이어그램의 관계(집합 vs 합성)
  • SOLID 5원칙
  • 디자인 패턴 매칭

객체, 클래스, 메시지

• 클래스(Class): 객체의 설계도 — 속성(데이터)과 메서드(동작)의 정의 (예: LidarSensor 클래스)
• 객체(Object)/인스턴스: 클래스로부터 생성된 실체 (예: 전방 라이다, 후방 라이다 — 같은 클래스의 두 인스턴스)
• 메시지(Message): 객체 간의 요청 — 메서드 호출로 협력한다

객체지향 4대 특징 (시험 최다 빈출)

• 캡슐화(Encapsulation): 데이터와 동작을 하나로 묶고 내부를 감춘다(정보 은닉) — 외부는 공개 인터페이스만 사용. 변경의 여파를 객체 안에 가둔다 (→ 모듈화 프로그래밍)
• 상속(Inheritance): 기존 클래스(부모)의 속성·동작을 물려받아 확장 — Sensor → LidarSensor, Camera. 공통 코드의 재사용
• 다형성(Polymorphism): 같은 메시지에 객체마다 다른 동작 — sensor.read()를 호출하면 라이다는 거리 배열을, 카메라는 영상을 반환. 상위 코드는 어떤 센서인지 몰라도 된다
• 추상화(Abstraction): 본질만 남기고 세부를 생략한 개념 모델 — "센서란 read()할 수 있는 것"이라는 추상 클래스/인터페이스 정의

로봇 예로 묶어 암기: 추상화로 Sensor 인터페이스를 정의하고, 기종별 드라이버가 상속으로 구현하며, 내부 통신 세부는 캡슐화로 감추고, 상위 코드는 다형성으로 어떤 센서든 같은 방식으로 쓴다 — 센서 교체가 상위에 영향 없는 이유.

클래스 다이어그램의 관계 (구분 단골)

객체지향 설계 5원칙 — SOLID (시험 단골)

• S — 단일 책임 원칙(SRP): 한 클래스는 한 가지 책임만 — 변경 이유가 하나
• O — 개방-폐쇄 원칙(OCP): 확장에는 열려 있고 수정에는 닫혀 있게 — 새 센서 추가 시 기존 코드 수정 없이 새 클래스만 추가
• L — 리스코프 치환 원칙(LSP): 자식 클래스는 부모 자리에 그대로 대체 가능해야 — Sensor 자리에 어떤 하위 센서를 넣어도 동작
• I — 인터페이스 분리 원칙(ISP): 큰 인터페이스 하나보다 작은 인터페이스 여러 개 — 쓰지 않는 메서드에 의존하지 않게
• D — 의존성 역전 원칙(DIP): 상위 모듈이 하위 구현이 아니라 추상(인터페이스)에 의존 — 경로계획기는 "LiDAR 드라이버"가 아니라 "거리 센서 인터페이스"에 의존

디자인 패턴 (GoF)

자주 나오는 설계 문제의 검증된 해법 카탈로그. 3분류와 로봇 단골 패턴:

• 생성(Creational): 객체 생성 방식 — 싱글턴(인스턴스 하나 보장: 설정 관리자), 팩토리 메서드(생성을 서브클래스에 위임: 설정 파일에 따라 센서 드라이버 생성)
• 구조(Structural): 객체 조합 — 어댑터(인터페이스 변환: 제조사 SDK를 표준 인터페이스로), 퍼사드(복잡한 서브시스템에 단순 창구)
• 행위(Behavioral): 협력·책임 분배 — 옵서버(상태 변화를 구독자에게 통지: 발행–구독의 원형 → 로봇 소프트웨어 아키텍처 분류), 전략(알고리즘을 교체 가능하게: 경로계획 알고리즘 선택), 상태(상태별 행동 객체화: FSM 구현 → 작업 시나리오별 소프트웨어 구현기술)

객체지향 설계의 절차 (요약)

• 유스케이스에서 명사 → 클래스 후보, 동사 → 메서드 후보 추출
• 책임을 분배(CRC)
• 관계 → 클래스 다이어그램, 협력 → 순서 다이어그램 (→ 로봇 소프트웨어 아키텍처 모델링)
• 원칙은 결국 하나 — 높은 응집, 낮은 결합

로봇 센서 계층의 객체지향 설계

classDiagram
    class Sensor {
        <>
        +read()
        +getStatus()
    }
    class LidarDriver {
        -통신 세부(캡슐화)
        +read() 거리 배열
    }
    class CameraDriver {
        +read() 영상
    }
    class Planner {
        +plan()
    }
    Sensor <|.. LidarDriver : 실체화
    Sensor <|.. CameraDriver : 실체화
    Planner --> Sensor : DIP - 추상에 의존

SOLID 한눈에

flowchart LR
    S["SRP
책임 하나"] --- O["OCP
확장 개방·수정 폐쇄"] --- L["LSP
자식은 부모 대체 가능"] --- I["ISP
인터페이스 잘게"] --- D["DIP
추상에 의존"]

1. 객체지향의 특징 중, 같은 read() 호출에 대해 라이다 객체는 거리 배열을, 카메라 객체는 영상을 반환하는 것처럼 동일한 메시지에 객체마다 다르게 동작하는 성질은?

① 캡슐화 ② 상속 ③ 다형성 ④ 추상화

2. UML 클래스 다이어그램에서 "로봇이 소멸하면 그 관절 객체들도 함께 소멸"하는 전체–부분 관계의 표현으로 옳은 것은?

① 빈 마름모의 집합(Aggregation) ② 채운 마름모의 합성(Composition) ③ 점선 화살표의 의존(Dependency) ④ 빈 삼각형의 일반화(Generalization)

3. "새로운 센서 기종을 추가할 때 기존 코드를 수정하지 않고 새 드라이버 클래스만 추가하면 되도록 설계한다"는 SOLID 원칙은?

① 단일 책임 원칙(SRP) ② 개방-폐쇄 원칙(OCP) ③ 인터페이스 분리 원칙(ISP) ④ 리스코프 치환 원칙(LSP)

4. 디자인 패턴과 용도의 연결로 옳지 않은 것은?

① 싱글턴 — 시스템 전체에서 설정 관리자 인스턴스를 하나로 보장 ② 어댑터 — 제조사 SDK의 인터페이스를 표준 인터페이스로 변환 ③ 옵서버 — 상태 변화를 구독자들에게 자동 통지 ④ 전략 — 클래스의 인스턴스 생성을 금지

5. 경로계획기가 특정 LiDAR 드라이버 클래스가 아니라 "거리 센서 인터페이스"에 의존하도록 설계했다. 적용된 원칙으로 가장 적절한 것은?

① 의존성 역전 원칙(DIP) ② 단일 책임 원칙(SRP) ③ 리스코프 치환 원칙(LSP) ④ 캡슐화

• 로봇 소프트웨어 아키텍처 모델링 — UML 다이어그램 체계
• 로봇 소프트웨어 설계 도구 — 설계를 그리는 도구
• 모듈화 프로그래밍 — 응집·결합, 정보 은닉의 토대
• 로봇 소프트웨어 아키텍처 분류 — 옵서버 패턴과 발행–구독 스타일
• 작업 시나리오별 소프트웨어 구현기술 — 상태 패턴과 FSM
• _MOC 로봇소프트웨어구조설계