[정보처리기사][실기] 개인적인 정리 (객체지향)

---

객체지향

  * 설계 원칙

    - 단일책임 원칙 (SRP, Single Responsibility Principle)

      → 객체는 단 하나의 책임만을 가져야함

      → 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다

      → 같은 이유로 변화하는 것끼리 묶고, 다른 이유로 변화하는 것끼리는 분리

 

    - 개방 폐쇄 원칙(OCP, Open-Closed Principle)

      → 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계

      → 소프트웨어 개체는 확장에는 열려있고 수정 시에는 닫혀있어야함

 

    - 리스코프 치환의 원칙 (LSP, Liskov Substitution Principle)

      → 일반화 관계에 대한 것으로 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야함

      → 하위 클래스 및 타입들은 상위 타입들이 사용되는 곳에 대체될 수 있어야하는 설계 원칙

      → 자식 클래스가 부모 클래스 기능을 재정의 하지 않으면 대체 가능함

 

    - 인터페이스 분리의 원칙 (ISP, Interface Segregation Principle)

      → 인터페이스를 클라이언트에 특화되도록 분리하라는 설계 원칙

      → 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스가 나음

 

    - 의존성 역전의 원칙 (DIP, Dependency Inversion Principle)

      → 의존 관계를 맺을 때

           변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어렵거나 거의 변화가 없는 것에 의존하라는 것

      → 추상화된 것에 의존하게 만들고 구체 클래스에 의존하도록 만들지 않도록 함

 

  * 객체지향 분석 방법론

      → 사용자의 요구사항을 분석하여 요구되는 사항과 관련된 모든 객체, 클래스와 연관된 속성, 연산, 관계 등을 정의하여 모델링하는 작업

 

    - Rumbaugh(럼바우) 방법론 (OMT, Object Modeling Technique)

      → 객체, 동적, 기능 모델로 나누어 수행하는 방법

모든 스프트웨어 구성요소를 그래픽 표기법을 활용하여 모델링하는 기법

 

      → 객체 모델링(Object Modeling)

정보 모델링이라고하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 그래픽 다이어그램을 표시하는 모델링

실세계 문제 영역으로부터 객체와 클래스를 추출해 그들 간의 관계를 연간화, 집단화, 일반화 중심을 규명하며, 클래스의 속성과 연산을 함께 표현함으로써 시스템의 정적 구조 생성

 

      → 동적 모델링 (Dynamic Modeling)

상태 다이어그램을 사용하여 시스템의 행위를 기술하는 모델링

 

      → 기능 모델링 (Function Modeling)

자료흐름도를 이용, 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현, 어떤 데이터를 입력하면 어떤 결과를 구할 것인지 표현

 

    - Booch(부치) 방법

요구사항 분석을 하는 과정에서 절차지향 프로그램을 개발하려면 '동사'를 식별하고, 객체지향 프로그램으로 개발하려면 '명사'를 선택하라고 했습니다

미시적(micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 포함하여 사용합니다

클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의

클래스와 객체 의미를 식별, 클래스와 객체들의 관계를 식별, 클래스 객체를 구현

각 작업에 대한 다이어그램, 클래스 계층 정의, 클래스들의 클러스터링 작업을 수행

Use Case를 강조하여 사용하는 분석 방법

 

 

    - Coad와 Yourdon(코드-요든) 방법

      → 객체지향 분석 방법론 중 E-R다이어그램을 사용하여 객체의 행위를 모델링

      → 객체식별, 구조식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성

      →  E-R 다이어그램은 코드-요든 분석법의 기본 스타일 이다

 

    - Wiris-Brock(워프스-브룩) 방법

      → 분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법이다

---

객체 지향 구성

  * 객체지향의 구성요소

    - 메소드(Method)

      → 객체의 행위(함수, 메소드)

      → 클래스로부터 생성된 객체를 사용하는 방법임

 

    - 속성(Attribute)

      → 객체의 데이터

 

    - 객체 (Object)

      → 클래스의 인스턴스(실제로 메모리상에 할당된 것)

      → 자신 고유의 데이터(Attribute)를 가지며 클래스에서 정의한 행위(Behavior)를 수행함

 

    - 클래스(Class)

      → 같은 종류의 객체들의 집합에 공통 속성(Attribute)과 행위(Behavior)를 정의함

      → 객체지향 프로그램의 기본적인 사용자 정의 데이터형 (User Define Data Type)임

 

    - 메시지(Message)

      → 객체(Object) 간의 통신을 말함

 

  * 객체지향의 특징

    - 캡슐화 (Encapsulation)

      → 속성(데이터)과 메소드(연산)을 하나로 묶어서 객체로 구성

      → Readability 향상 : 유지보수 용이

      → 재사용성이 높은 S/W 개발이 가능

      → 정보은닉으로 내부자료의 일관성이 유지

      → 객체 간 인터페이스를 이용 종속성을 최소화

 

    - 추상화 (Abstraction)

      → 공통 성질을 추출하여 수퍼클래스로 구성

      → 객체 중심의 안정된 모델을 구축

      → 현실세계를 자연스럽게 표현

      → 분석의 초점이 명확해짐

 

    - 다형성(Polymorphism)

      → 동일한 이름의 여러 오퍼레이션(메소드)을 다른 사양으로 정의 가능

      → 오버로딩 : 매개변수의 수 또는 타입을 달리하여 구분

      → 오버라이딩 : 부모클래스의 메소드를 재정의

 

    - 정보은닉(Information Hiding)

      → 캡슐화된 항목을 다른 객체(Object)로부터 숨김

      → 메시지 전달에 의해 다른 클래스 내의 메소드가 호출됨

 

    - 상속성(Inheritance)

      → 부모 클래스의 속성과 메소드를 상속받아 사용함

      → 부모 자식 클래스 간의 관계가 슈퍼클래스와 서브클래스로 유지됨

      → 부모클래스는 추상적이며, 자식 클래스는 구체적인 성질을 가짐

---

    - 오버로딩

      → 하나의 클래스 내에서 같은 이름으로 여러개의 메소드를 정의

      → 특정 클래스내에 동일한 메소드 명

 

    - 오버라이딩

      → 상속 관계에서 상위 클래스의 메소드를 하위클래스에서 재정의

      → 상속관계 내 동일 메소드 명

---