객체 지향 설계 개념 정리

객체 지향 구성 요소

• 객체(Object): 객체는 속성(상태, 데이터)과 동작(행위, 메서드)을 가진 실체입니다. 예를 들어, '자동차'라는 객체가 있다면 이는 '색상', '모델', '제조연도' 등의 속성과 '주행', '정지', '가속' 등의 동작을 가질 수 있습니다.
• 클래스(Class): 클래스는 객체를 생성하기 위한 청사진이나 템플릿입니다. 이는 객체의 초기 상태(속성)와 동작(메서드)를 정의합니다.
• 메서드(Method): 메서드는 클래스에 정의된 함수로, 객체의 동작을 나타냅니다. 메서드는 객체의 속성을 조작하거나 다른 객체와 상호 작용하는 데 사용됩니다.
• 메시지(Message): 메시지는 객체 간의 통신을 가능하게 하는 메커니즘입니다. 객체는 다른 객체의 메서드를 호출하거나 메시지를 보내는 방식으로 상호작용합니다.
• 속성(Attribute) or 상태(State): 객체의 특성을 나타내는 변수나 데이터를 의미합니다. 예를 들어, '학생' 객체의 속성에는 '이름', '나이', '학년' 등이 포함될 수 있습니다.
• 인스턴스(Instance): 인스턴스는 클래스를 실제로 사용하기 위한 '실체'라고 할 수 있습니다. 클래스는 객체의 일반적인 형태를 정의하는 템플릿 또는 청사진인 반면, 인스턴스는 클래스에서 정의한 구조를 가진 실제 객체를 의미합니다.

 

객체 지향 기법

• 상속성(Inheritance): 상속은 하나의 클래스(부모 클래스)의 속성과 메서드를 다른 클래스(자식 클래스)가 받아들이는 과정입니다. 이를 통해 코드의 재사용성이 높아집니다.
• 캡슐화(Encapsulation): 이 원칙은 객체의 상태와 동작을 하나의 단위로 결합합니다. 즉, 객체의 데이터는 외부에서 직접 접근할 수 없으며, 이는 객체 내의 특정 메서드를 통해서만 가능합니다.
• 다형성(Polymorphism): 다형성은 하나의 인터페이스나 클래스를 여러 형태로 사용할 수 있는 능력을 의미합니다. 이 원칙은 메서드 오버로딩(overloading)과 오버라이딩(overriding)으로 실현됩니다.
• 추상화(Abstraction): 추상화는 복잡한 시스템을 더 간단하고 이해하기 쉬운 부분으로 분리하는 프로세스입니다. 추상 클래스나 인터페이스를 사용하여 이 원칙을 구현할 수 있습니다.
• 정보 은닉(Information Hiding): 정보 은닉은 객체의 내부 데이터와 상세 구현을 숨기는 원칙입니다. 이 원칙을 따르면, 각 객체의 내부 상태는 해당 객체의 메서드를 통해서만 변경될 수 있습니다. 이것은 객체의 상태가 예기치 않게 변경되는 것을 방지하며, 객체의 행동을 보다 안정적으로 만듭니다.

 

객체 지향 설계 원칙(SOLID)

• 단일 책임 원칙 (Single Responsibility Principle, SRP): 클래스는 하나의 책임만 가져야 합니다. 이는 '하나의 클래스는 하나의 작업만 수행해야 한다'는 개념을 나타냅니다. 클래스가 두 가지 이상의 책임을 가질 경우, 이는 다른 클래스와의 강한 결합을 초래하며, 유지 보수성이 떨어질 수 있습니다.
• 개방-폐쇄 원칙 (Open-Closed Principle, OCP): 소프트웨어 구성요소(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 합니다. 즉, 기존의 코드를 변경하지 않고도 새 기능을 추가할 수 있어야 합니다.
• 리스코프 치환 원칙 (Liskov Substitution Principle, LSP): 하위형은 그것의 기본형으로 대체 가능해야 합니다. 즉, 상속 관계에 있어서 자식 클래스는 부모 클래스를 완벽하게 대체할 수 있어야 합니다.
• 인터페이스 분리 원칙 (Interface Segregation Principle, ISP): 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다는 원칙입니다. 이는 인터페이스가 클라이언트에게 필요하지 않은 메서드를 포함하지 않아야 함을 의미합니다.
• 의존성 역전 원칙 (Dependency Inversion Principle, DIP): 상위 모듈은 하위 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 이 원칙은 구체적인 클래스보다는 인터페이스나 추상 클래스에 의존하는 것이 좋다는 접근 방식을 나타냅니다.

 

객체 지향 방법론

• OOSE (Object-Oriented Software Engineering): OOSE는 Ivar Jacobson이 개발한 객체 지향 소프트웨어 개발 방법론입니다. OOSE는 비즈니스 프로세스 모델링에 중점을 두며, use case라는 개념을 도입하여 시스템의 요구 사항을 명확하게 식별하고 이해하는 데 도움을 줍니다. OOSE는 이런 use case를 기반으로 시스템의 객체 모델을 개발합니다.
• OMT (Object Modeling Technique): OMT는 James Rumbaugh가 개발한 객체 지향 분석 및 설계 방법론입니다. OMT는 객체 모델링, 동적 모델링, 함수 모델링의 세 가지 주요 모델을 사용하여 시스템을 설명합니다. 이 방법론은 현재 UML(Unified Modeling Language)의 기초를 형성하는 데 큰 역할을 했습니다. 이 방법은 객체 모델링 → 동적 모델링 → 기능 모델링 순서대로 진행됩니다. 그 중 객체 모델링은 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 다이어그램으로 표시하는 모델링입니다. 또, 기능 모델링은 자료 흐름도(DFD)를 주로 이용합니다.
• OOD (Object-Oriented Design): OOD는 소프트웨어 설계 프로세스의 한 부분으로, 시스템을 객체로 보고 이들 객체가 서로 상호 작용하는 방식으로 시스템을 구성하는 것을 기반으로 합니다. 이 방법론의 주요 목표는 유연하고 확장성이 좋은 시스템을 만드는 것입니다.
• Coad와 Yourdon 방법론: Peter Coad와 Edward Yourdon이 개발한 이 방법론은 객체 지향 분석과 설계를 위한 방법론입니다. 이 방법론은 객체, 속성, 서비스, 그리고 관계를 통해 시스템을 모델링합니다. E-R 다이어그램을 사용하여 객체의 행위를 데이터 모델링하는데 초점을 둔 방법입니다. 또한 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 등의 과정으로 구성됩니다.
• Wirfs-Brock 방법론: Wirfs-Brock 방법론은 Rebecca Wirfs-Brock이 개발하였으며, 책임 주도 설계(Responsibility-Driven Design, RDD)라고도 알려져 있습니다. 이 방법론은 객체의 책임과 행동을 중심으로 설계를 진행합니다.