1-13강. 애플리케이션 설계-객체지향 설계

과목1. 소프트웨어 설계, 13강. 애플리케이션 설계-객체지향 설계

 

[ 목차 ]

1. 객체지향의 개념

2. 객체지향의 등장배경

3. 구조적 개발(전통적)과 객체지향 개발의 장단점

4. 객체, 클레스, 메시지 개념

5. 캡슐화

6. 정보은폐, 정보은닉

7. 상속

8. 다형성

9. 객체지향 프로그램 개념

10. 객체지향의 구성

11. 객체지향의 기법

12. 다형성과 상속성의 차이

13. 다형성의 오버로딩과 오버라이딩 차이점

14. 객체 지향 설계의 원칙

15. 디자인 패턴의 개념

16. 디자인 패턴의 구성

17. GoF의 디자인 패턴 분류

18. 암기

19. MVC 패턴의 개념(모델, 뷰, 컨트롤러)

20. MVC 패턴의 구성

21. 

 

1. 객체지향의 개념

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

2) 구현대상을 하나의 객체로 보고 객체와 객체들 간의 관계로 모델링하는 방법

 

2. 객체지향의 등장배경

1) 개발측면에서 소프트웨어 위기 해결을 위한 대안과 생산성 저하에 따른 재사용성, 확장성의 필요에 의해 등장

2) 사용측면에서 컴퓨팅 환경에 대한 보다 많은 기능, 단순성, 사용편의성 요구가 증대

소프트웨어 위기 : 시스템의 대규모화에 따라 소프트웨어의 신뢰성 저하, 개발비 증대, 계획 지연 따위의 현상이
                             현저하여 개발 계획으 수행을 매우 어렵게 만드는 상황

3. 구조적 개발(전통적)과 객체지향 개발의 장단점

1) 구조적 개발 장점 : 구조가 단순하여 이해, 수정이 쉽고 정확함

2) 구조적 개발 단점 : 소프트웨어 재사용과 유지보수가 어려움

3) 객체지향 개발 장점 : 현실을 프로그램에 반영하여 소프트웨어 재사용과 유지보수가 쉽고 소프트웨어 위기 해결 방안

 

4. 객체, 클레스, 메시지 개념

1) 객체

  1] 클래스의 인스턴스이며 객체들 간의 상호작용은 메시지를 통해 이루어짐

  2] 데이터 : 객체가 가지고 있는 상태(= 상태, 속성, 변수, 자료구조)

  3] 연산자 : 객체의 데이터를 처리하는 행위(=행위, 메소드, 동작)

2) 클래스

  1] 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추상화(모델링)을 의미

  2] 공통된 속성과 연산을 갖는 객체의 집합

  3] 인스턴스 : 클래스에 속한 각각의 객체

3) 메시지

  1] 객체들 간에 상호작용을 하는데 사용되는 수단

  2] 객체에서 객체로 메시지가 전달되면 메소드를 시작

4) 메소드

  1] 객체지향 시스템에서 전통적 시스템의 함수 또는 프로시저에 해당하는 연산기능

  2] 객체지향 개념에서 객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산

 

5. 캡슐화

1) 속성과 메소드를 하나로 묶어서 객체로 구성

2) 정보를 은폐하여 외부에서 변경이 힘들고, 프로그램 변경에 대한 오류의 파급효과가 적어져 재사용이 용이

 

6. 정보은폐, 정보은닉

1) 객체는 다른 객체로부터 자신의 자료를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것

2) 고려되지 않은 영향 최소화 가능

 

7. 상속

1) 상위 클래스의 메소드와 속성을 하위 클래스가 물려받는 것

2) 다중 상속은 한 클래스가 여러 상위 클래스로부터 상속 받는 것

 

8. 다형성

1) 한 메시지가 객체에 따라 다른 방법으로 응답할 수 있는 것

2) 많은 상이한 클래스들이 동일한 메소드명을 이용하는 능력

 

9. 객체지향 프로그램 개념

1) 컴퓨터 프로그래밍의 패러다임 중 하나

2) 프로그램을 명령어의 목록이라는 시각에서 벗어나 여러 개의 독립된 단위, 즉 객체들의 모임으로 파악하고자 하는 것

3) 각각의 객체는 메시지를 주고받고 데이터를 처리할 수 있음

4) 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용

5) 프로그래밍을 배우기 쉽게 하고 소프트웨어 개발, 보수를 간편하게하여 직관적인 분석을 가능하게 함

 

10. 객체지향의 구성

1) 클래스

  1] 같은 종류(또는 문제 해결을 위한)의 집단에 속하는 속성과 행위를 정의

  2] 객체지향 프로그램의 기본적인 사용자 정의 데이터형

2) 객체

  1] 클래스의 인스턴스

  2] 자신 고유의 데이터를 가지며 클래스에서 정의한 행위를 수행

3) 속성

  1] 객체의 데이터

4) 메소드

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

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

5) 메시지

  1] 객체 간의 통신

사용자 정의 데이터형 : 프로그래밍 언어에서 제공하는 데이터형을 조합하여 새로운 이종의 데이터형을 생성

11. 객체지향의 기법

1) 캡슐화

  1] 속성과 메소드를 하나로 묶어 객체로 구성

  2] Readability 향상 : 유지보수 용이

  3] 재사용성이 높은 s/w 개발 가능

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

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

Readability

1) 코드 가독성. 메소드 단위의 코드를 알게 되면 맥락을 읽을 수 있음
2) 내부 변경이 프로그램에 미치는 영향 최소화(유지보수 용이)
3) 메시지를 통한 접근(객체 간 인터페이스 이용)을 통해 종속성 최소화(결합도 낮음)

객체지향 인터페이스

1) 일반적 의미 : 연결하는 장치
2) 객체지향 인터페이스 : 기능을 사용하는 통로

2) 추상화

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

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

  3] 현실 세계를 자현스럽게 표현

  4] 복잡한 것은 단순화, 간결화하고 공통데이터와 기능을 도출해 분석의 초점이 명확해짐 

  5] 몇 가지 공통 속성을 가지지만 서로 다른 속성도 가지는 객체를 집단화 하는 과정

3) 다형성

  1] 동일한 이름의 여러 오퍼레이션(메소들)을 다른 사양으로 정의

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

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

 4) 정보은닉

  1]  캡슐화된 항목을 다른 객체로부터 숨김

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

5) 상속성

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

  2] 부모와 자식 클래스 간의 관계가 수퍼크래스와 서브클래스로 유지

  3] 미리 만들어둔 클래스를 다시 이용하는 방법

  4] 물려받은 클래스는 서브클래스, 원래의 클래스는 수퍼클래스

  3] 부모 클래스는 추상적, 자식 클래스는 구체적 성질을 지님

 

12. 다형성과 상속성의 차이

바인딩

1) 프로그래밍에서 각종 값들이 확정되어 더 이상 변경할 수 없는 구속 상태가 되는 것
2) 변수, 배열, 라벨, 절차 등의 명칭 즉, 식별자가 그 대상인 메모리 주소, 데이터형, 실제값으로 배정되는 것
3) 정적 바인딩 : 원시 프로그램의 컴파일 또는 링크 시에 확정되는 바인딩
4) 동적 바인딩 : 프로그램의 실행되는 과정에서 바인딩. 오버라이딩 할 때 자동

13. 다형성의 오버로딩과 오버라이딩 차이점

1) 오버라이딩 조건

  1] 자식 클래스에서 오버라이딩하는 메소드는 상위 클래스의 메소드와 이름, 매개변수, 리턴 타입이 같아야 함

 

14. 객체 지향 설계의 원칙

1) 단일 책임의 원칙 SRP

  1] 객체는 하나의 책임만 맡아야 함(낮은 결합도, 높은 응집도 추구)

  2] 책임 : 해야 하는 것, 할 수 있는 것으로, 객체지향 프로그래밍의 기본이자 유지보수에 아주 중요한 역할

  3] 초기 설계와 다른 디자인으로 급선회 하더라도 SRP가 잘 되어 있다면 비교적 유연하게 이동 가능

   4] 하나의 클래스가 너무 많은 기능을 지녔다면 어떤 기능 변경 시 모든 기능을 점검해야 하는 수고로움 추가

  5] 책임분리를 통해 어떠한 책임이 변경되더라도 다른 책임에게 영향이 가지 않도록

2) 개발 폐쇄 원칙 COP

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

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

  3] 추가할 코드는 OPEN, 기존의 코드는 CLOSE

3) 리스코프 치환의 법칙 LSP

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

4) 인터페이스 분리의 법칙 ISP

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

  2] 자신이 이용하지 않는 기능의 영향은 받지 않는 것이 좋음

5) 의존성 뒤집기의 원칙 DIP

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

  2] 구체 클래스(구체적)가 아닌 추상 클래스(추상적)에 의존해야 함

  3] 구체 클래스는 추상 클래스보다 변하기 쉽기 때문에 변화에 직접 영향을 받지않는 추상 클래스에 의존

 

15. 디자인 패턴의 개념

1) 반복적으로 나타나는 문제들을 해결해 온 전문가들의 경험을 모아서 정리한 일관된 솔루션

2) 설계의 재사용을 통해 생산성 향상을 위한 기법

3) 프로그래머들이 유용하다고 생각되는 객체들간의 일반적인 상호작용 방법들을 모은 목록

4) 아키텍처 패턴(소프트웨어의 공학의 다양한 문제 해결)은 소프트웨어 디자인 패턴과 유사하지만 더 큰 범주에 속함

5) 자주 사용하는 설계 형태를 정형화해서 이를 유혈별로 템플릿을 만들어 둔 것

6) 효율성과 재사용성을 높일 수 있음

7) 노하우를 분류, 정리, 이름을 붙여 초보자가 쉽게 재사용 할 수 있도록 지침도 포함하여 저장

8) GoF : 에릭 가마, 리처드 헬름, 랄프 존슨, 존 브리스데스가 제안했으며, 객체지향 개념에 따른 설계의 지침서

9) MVC

 

16. 디자인 패턴의 구성

1) 패턴이름 : 패턴의 기능, 해법을 떠올릴 수 있는 설계의도를 표현하여 한 두 단어로 설계문자와 해법을 서술

2) 문제 : 해결해야 할 문제와 그 배경을 설명하며 언제, 어떤 문제에 패턴을 사용하는지 서술

3) 해법 : 설계의 구성 요소와 요소들 간의 관계, 책임, 협력관계 등 어떤 방법과 클래스 구성으로 해결했는지 서술

4) 결과 : 디자인 패턴을 적용해서 얻는 결과와 장단점을 서술

 

17. GoF의 디자인 패턴 분류

1) 패턴이 수행하는 목적에 따른 분류

  1] 생성 패턴 : 객체 생성, 클래스

  2] 구조 패턴 : 객체 결합

  3] 행위 패턴 : 객체 간 커뮤니케이션

2. 패턴이 다루는 영역에 따른 분류

 

18. 암기

 

19. MVC 패턴의 개념(모델, 뷰, 컨트롤러)

1) 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴

2) 사용자 인터페이스로부터 비즈니스 로직을 분류하여 애플리케이션의 시각적 요소나 그 이면에 실행되는 비즈니스 로

    직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 생성

3) 모델은 애플리케이션의 정보를 나타내며 뷰는 텍스느, 체크박스 항목과 같은 사용자 인터페이스 요소, 컨트롤러는 데

    이터와 비즈니스로직 사이의 상호동작을 관리

 

20. MVC 패턴의 구성

1) 컨트롤러

  1] 모델에 명령을 보내어 모델의 상태를 변경 가능

  2] 관련된 뷰에 명력을 보내어 모델의 표시 방법을 변경 가능

  3] 모델의 변화에 따른 적용 가능한 명력을 추가, 제거, 수정

2) 모델

  1] 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보

  2] 해당 통보를 통해 최신의 결과를 보여줄 수 있음

  3] 어던 MVC 구현에서는 통보 대신 뷰, 컨트롤러가 직접 모델의 상태를 읽어옴

3) 뷰

  1] 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어옴