4일차 : 3-2 객체지향 설계

Dev_HG·2020년 6월 30일
0

객체지향

1. 객체지향(Object Oriented) 개념

실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 개념

2.객체지향 구성요소

  1. 클래스(Class) : 같은 종류의 집단에 속하는 속성과 행위를 정의, 속성은 변수의 형태로, 행위는 메서드 형태로 선언, 객체지향 프로그램의 기본적인 사용자 정의 데이터형
  2. 객체(Object) : 객체의 행위는 클래스에 정의된 행위에 대한 정의를 공유함으로써 메모리를 경제적으로 사용, 객체마다 각각의 식별성을 가짐
  3. 메서드(Method) : 클래스로부터 생성된 객체를 사용하는 방법, 전통적 시스템의 함수(Function) 또는 프로시저(Procedure)에 해당하는 기능
  4. 인스턴스(Instance) : 객체지향 기법에서 클래스에 속한 각각의 객체, 실제로 메모리상에 할당
  5. 속성(Property) : 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의, 성질, 분류, 식별, 수량, 현재 상태 등에 대한 표현 값

3. 객체지향 기법

  1. 캡슐화 : 서로 관련성이 많은 데이터와 이와 관련된 함수들을 한 묶음으로 처리하는 기법, 결합도가 낮아지고 재사용이 용이, 변경 발생 시 오류의 파급효과가 적음, 인터페이스가 단순화 됨
  2. 상속성 : 상위 클래스의 속성과 메소드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법
  3. 다형성 : 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답 할 수 있는 능력, ex : 오버로딩, 오버라이딩
  4. 추상화 : 공통 성질을 추출하여 추상 클래스를 설정하는 기법(기능 추상화, 자료 추상화, 제어 추상화)
  5. 정보은닉 : 코드 내부 데이터와 메소드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술

4. 객체지향 설계 원칙(SOLID)

  1. 단일 책임의 원칙(Single Responsibility Principle) : 하나의 클래스는 하나의 목적을 위해서 생성되며 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다는 원칙, 객체지향 프로그래밍의 5원칙 중 나머지 4원칙의 기초 원칙
  2. 개방 폐쇄 원칙(Open Close Principle) : 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 하는 원칙
  3. 리스코프 치환의 원칙(Liskov Substitution) : 자식 클래스(서브 타입)는 언제나 자신의 부모 클래스(기반 타입)를 대체한다는 원칙
  4. 인터페이스 분리의 원칙(Interface Segregation Principle) : 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙
  5. 의존성 역전의 원칙(Dependency Inversion Principle) : 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

5. 객체지향 방법론 종류

1.OOSE(Object Oriented Software Engineering)
=> 설명 : 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용
=> 특징 : 분석, 설계, 구현 단계로 구성, 기능적 요구사항 중심의 시스템

  1. OMT(Object Modeling Technology)
    => 설명 : 객체지향 분석, 시스템 설계, 오브젝트 설계 및 구현의 4단계로 구성

  2. 객체 모델링 : 시스템의 정적 구조 표현

  3. 동적 모델링 : 객체의 제어 흐름/상호 반응 표현

  4. 기능 모델링 : 데이터 값의 변화과정 표현
    => 특징 : 복잡한 대형 프로젝트에 유용, 기업 업무의 모델링 편리 및 사용자와 의사소통 편리

  5. Booch
    => 설명 : OOD(Object Oriented Design)로 설계 부분만 존재, 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론
    => 특징 : 분석과 설계 분리 불가능, 분석하는 데 이용된 객체 모델의 설계시 적용

2. 디자인 패턴

1. 디자인 패턴(Design Patern) 개념

  1. 어떤 분야에서 반복적으로 나타나는 문제점들에 대해 전문가들의 경험을 정리하여 해결 방안을 제시한 패턴
  2. 디자인 패턴을 참고하여 개발할 경우 개발의 효율성과 유지 보수성, 운용성 등의 품질이 높아지며,, 프로그램의 최적화에 도움이 된다.

2. 디자인 패턴 구성요소

4가지 요소
1. 패턴이름 : 설계 의도 표현할 수있도록 문제와 해법을 설명
2. 문제 : 해결하고자 하는 문제와 배경, 패턴 사용 시점을 서술
3. 해법 : 패턴을 구성하는 요소, 요소 간의 관계, 책임, 상호관계를 서술
4. 결과 : 패턴을 적용해서 어든 결과와 장단점을 서술

3. 디자인패턴 유형

[목적]
1. 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴
2. 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
3. 행위 : 클래스나 객체들이 상호작용하는 방법과 역할 분담을 다루는 패턴
[범위]
1. 클래스 : 클래스 간 관련성 즉, 상속 관계를 다루는 패턴, 컴파일 타임에 정적으로 결정
2. 객체 : 객체 간 관련성을 다루는 패턴 런타임에 동적으로 결정
cf : 컴파일 타임(Compile time) : 소스 코드를 작성하고 컴파일이 라는 과정을 통해 기계어 코드로 변환되어, 실행 가능한 프로그램이 되는 과정이다(정적 메모리 할당 수행)
cf : 런타임(Run Time) : 파일과정을 마친 프로그램은 사용자에 의해 실행되어 지며, 이러한 응용프로그램이 동작되는 과정이다(동적 메모리 할당)

[목적, 범위에 따른 디자인 패턴 분류]

4. 디자인 패턴 종류

[생성 패턴]
1. Factory Method : 서브 클래스나 인스턴스를 결정하도록 하고 책임을 위임하는 패턴
2. Singleton : 유일한 하나의 인스턴스를 보장하도록 하는 패턴

[구조 패턴]
1. Facade : 하나의 인터페이스를 통해 느슨한 결합을 제공하는 패턴
2. Proxy : 대리인이 대신 그 일을 처리하는 패턴

[행위 패턴]
1. Template : 알고리즘 골격의 구조를 정의한 패턴
2. Command : 요청 자체를 캡슐화하여 파라미터로 넘기는 패턴
3. Observer : 상태가 변할 때 의존자들에게 알리고, 자동 업데이트하는 패턴

profile
꾸준함

0개의 댓글