강의의 주제가 의존성을 낮추기 위한 데이터와 프로세스를 통합시키는 내용을 다루었으며 객체와 데이터를 구분하며 객체 지향의 기본 철학은 데이터가 아닌 객체를 설계하는 내용을 다루었다.

 

객체 지향 기본 철학:

자기 스스로 원칙에 따라 판단하고 자기 자신의 일을 하며  자기 자신을 통제할 수 있는 객체를 설계하는 것이 객체 지향의 기본 철학이다.

 

 

객체와 데이터의 개념이 나왔는데... 동일한 인스턴스이지만, 수동적인지 자율적인지에 따라 전자는 데이터, 후자는 객체로 명명한다.

 

“객체 vs 데이터”를 구분하는 기준을  ‘자율성(능동성) 여부”로 보는 관점은 주로 DDD(Domain-Driven Design), 객체지향 설계 철학 쪽에서 나오는 용어인듯 하다.

1. 자율성 관점에서의 “객체”와 “데이터”

  • 객체(Object): 스스로의 불변성과 규칙을 유지하고, 외부에서 함부로 변경하지 못하게 “능동적으로” 자기 역할을 수행하는 인스턴스. 즉, 다른 코드에 종속되지 않고 자기 자신이 “자율적”으로 동작한다. (Smart Object 똑똑한 객체라고 불리며 자기 자신의 상태를 직접 관리하고 스스로 판단하고 결정하는 자율적인 존재이다.)
  • 데이터(Data): 단순히 값만 담겨 있고, 다른 객체나 서비스의 로직에 의해 “끌려 다니는” 존재. 자기 스스로 규칙을 보장하지 못하고 외부 로직에 의존한다. 즉 데이터를 외부에 제공하고 외부에서 판단하고 결정하는 수동적인 존재이다.( Dumb Data Object  바보 데이터 객체 라고도 불리며 객체가 아닌 데이터이다. )

2. 예시

데이터 스타일 (수동적)

 
public class OrderData
{
    public int Quantity { get; set; }
    public decimal UnitPrice { get; set; }
}
  • 값만 가지고 있고,
  • “총 가격” 같은 계산은 외부 서비스에서 해줘야 한다.
  • 즉, 외부 로직에 의존하는 수동적 존재 = 데이터

객체 스타일 (능동적)

 
public class Order
{
    public int Quantity { get; private set; }
    public decimal UnitPrice { get; private set; }

    public decimal GetTotalPrice()
    {
        return Quantity * UnitPrice;
    }
}
  • 스스로 “총 가격”을 계산할 수 있다.
  • 외부가 값을 직접 바꾸지 못하게 캡슐화되어 있다.
  • 자기 규칙을 자기 안에서 책임진다 → 독립적이고 자율적 → 객체

강의에서 외부에서 제어하지 않고 자기 자신이 제어하고자 데이터(상태)와 프로세스(행위)를 통합시켰다.

 이를 통해 응집도 향상(데이터와 그 데이터를 다루는 로직 또는 행위가 함께 있으니 관리가 용이)/ 자율성 향상(객체가 자기 자신을 스스로 책임 짐에 따라 외부에 의존 하지 않음) / 캡슐화 (내부 데이터가 외부에서 무분별하게 변경되는 걸 막고, 안전하게 제어) 효과를 가져오게 됐다.

3. 정리

  • 데이터: 외부 로직에 의존 → 수동적, 단순 상태 전달용 (DTO, Record 같은 것)
  • 객체: 자기 규칙을 내부에서 보장 → 능동적, 자율적, 독립적

 

1. 계측기 모니터링 프로젝트(개인 프로젝트)에서

  • InstrumentViewModel: UI 쪽 로직 (버튼 클릭 → Start 호출)
  • IDMService: 인터페이스 (계측기 서비스에 대한 인터페이스)
  • DMSERVICE: DI로 주입된 실제 구현체 (Keysight, Hioki 계측기 비즈니스 로직으로 실제로는 DMSelectorService(전략 패턴)를 통해 장비 서비스를 장비 선택에 따라 키사이트 또는 히오키 dm서비스로 교체)

InstrumentViewModel은 DI 컨테이너를 통해 IDMService를 받음 → 그리고 ViewModel에서 dmService.Start()를 호출함.

2. 능동적/수동적 구분

  • InstrumentViewModel 입장
    • Start 버튼을 누를 때마다 dmService.Start()를 호출함.
    • 즉, ViewModel은 서비스한테 “일 해라”라고 명령을 내림.
    • 이때 ViewModel은 "수동적으로" 서비스에 의존하는 쪽임.
  • DMSERVICE 입장
    • 자신이 가진 로직(Start)을 스스로 실행해서 장비 통신을 시작하고, 내부 규칙(소켓 연결, 파싱, 측정 loop 등)을 책임짐.
    • 즉, 외부에 끌려가는 데이터 덩어리가 아니라 자율적으로 역할을 수행하는 객체임.

3. 결론

  • DMSERVICE는 능동적(=객체)이다.
    • 이유: ViewModel이 시그널(명령)을 보내면, 실행 로직은 전적으로 DMSERVICE 안에서 처리되고, DMSERVICE 스스로 책임을 짐.
  • 반대로, InstrumentViewModel 쪽은 수동적(=데이터/조정자) 성격이 강하다.
    • 이유: DMSERVICE에 의존해서 동작하고, 그 자체로는 장비를 다룰 능력이 없음.

정리하자면,

  • DMSERVICE = 능동적 객체 (스스로 규칙과 행위를 가진다)
  • InstrumentViewModel = 외부를 조정하고 연결하는 조율자지만, 계측기 동작 자체는 서비스에 의존하므로 상대적으로 수동적이다.

 

 

+ Recent posts

티스토리툴바