JANGUN


객체지향 프로그래밍



목차

개요
Chapter 1. 객체 지향 개요
Chapter 2. 클래스
Chapter 3. 객체
Chapter 4. 캡슐화
Chapter 5. 정보은닉
Chapter 6. 메시지
Chapter 7. 복합객체
Chapter 8. 상속
Chapter 9. 추상클래스
Chapter 10. 인터페이스
Chapter 11. 다형성
Chapter 12. 컴포넌트


개요


객체지향 설계
- 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 객체들을 설계한다.
- 자율적으로 역할과 책임을 수행하며 메시지로 의사소통 하는 객체들을 설계한다.
- 소프트웨어 객체의 자율성(autonomous), 의인화(anthropomorphism) : 현실의 무생물도 자율적인 행동을 한다.
- 현실 세계와 객체지향 세계 사이의 관계를 좀 더 정확하게 설명할 수 있는 단어는 은유(metaphor)이다
- 현실을 모방하는 것이 아니라 이상한 나라를 창조해야 한다 : 추상화(단순화), 개념화, 일반화
- 책임-주도 설계 : 협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식으로 설계한다.

객체
- 식별자 : 객체는 식별 가능해야 한다.
- 상태 : 객체의 상태를 변경하는 것은 자발적인 객체 자신의 자발적인 행동뿐이다.
- 상태캡슐화 : 객체지향의 세계에서 모든 객체는 자신의 상태를 스스로 관리하는 자율적인 존재이다.
- 행동 (메서드) : 수신된 메시지를 처리하는 방법. 객체가 취하는 행동은 객체 자신의 상태를 변경시킨다.
- 객체의 상태를 결정하는 것은 행동이지만, 행동의 결과를 결정하는 것인 상태다. 즉 상태에 따라 행동의 결과가 달라진다.
- 객체는 행동하기 위해 존재한다. 상태를 저장하기 위해 존재하는 것이 아니다.
- 링크 : 객체와 객체 사이의 의미 있는 연결, 링크를 통해서 메시지를 보내고 받음.
- 메시지 : 객체들 간의 유일한 의사소통 수단.
- 객체가 어떤 행동을 하도록 만드는 것은 객체가 외부로부터 수신한 메시지다.
- 객체는 수신된 메시지에 따라 적절히 행동하면서 협력에 참여하고 그 결과로 자신의 상태를 변경한다.
- 객체의 행동을 유발하는 것은 외부로부터 전달된 메시지지만, 객체의 상태를 변경할 지 여부는 객체 스스로 결정한다.

객체지향 프로그래밍(OOP)의 구조와 현실 세계는비슷한 부분도 있지만, 기본적으로 구조가 크게 다른 것으로 오히려 ‘닮았지만 다른 것’이다.
객체지향프로그래밍의 3대 요소 : 클래스, 폴리모피즘, 상속

1. 클래스는 종류, 인스턴스는 구체적인 것
객체 지향에서는 클래스를 정의함으로써 프로그램을 작성한다.
프로그램이 실행될 때 정의한 클래스로부터 인스턴스가 만들어져 이들이 상호 작용을 하면서 소프트웨어로서의 기능을 실현한다.

2. 폴리모피즘(다형성)은 메시지 보내는 방법이 공통이다.
비슷한 클래스에 대하여 메시지를 보내는 방법을 공통으로 하는 구조라고 말할 수 있다.
상대가 구체적으로 어떤 클래스의 인스턴스인지를 의식하지 않고 메시지를 보내는 구조라고도 할 수 있다.

3. 상속은 공통점과 상이점을 체계적으로 분류해서 정리한다.
상속은 사물 종류의 공통점과 상이점을 체계적으로 정리한 구조이다.

객체지향은 현실 세계를 그래도 소프트웨어로 표현하는 기술이 아니다.
- 객체지향은 그 이전의 프로그래밍 기술을 기초로 결점을 보완하기 위해서 고안된 것이다.
- 객체지향은 품질 좋은 프로그램을 높은 생산성으로 만들기 위한 실천적인 기술이다. (생산성, 유지 보수성과 재사용성 증대, 품질 향상)
- 불필요한 부분을 생략하고 정돈하는 프로그래밍 기술이다.
- 클래스는 연관성이 강한 서브루틴(함수)과 전역변수를 하나로 모아서 밀도 높은 소프트웨어 구성품을 만드는 구조로, 여기 저기 흩어져 있는 서브루틴과 변수를 모아서 정돈할 수 있다.
- 폴리모피즘과 상속은 공통 서브루틴으로는 잘 대처할 수 없는 중본된 코드를 하나로 하는 구조로, 소스 코드의 불필요한 부분을 철저하게 줄일 수 있다.

클래스는 ‘(변수) 모으기, (변수와 함수)감추기, (하나의 클래스로부터 인스턴스) 많이 만들기’의 구조
- 인스턴스 변수를 ‘길게 보관할 수 있는 지역변수’ 또는 ‘클래스 내부에서만의 전역변수'라고 기억하자.

폴리모피즘은 간단히 ‘공통 메인루틴'을 만들기 위한 구조라 할 수 있다.
- 공통 서브루틴은 호출당하는 쪽의 논리를 하나로 모으게 되지만, 폴리모피즘은 반대로 호출하는 쪽의 논리를 하나로 모은다.

상속은 ‘변수와 메소드를 정리한 공통 클래스를 만들어 이 정의를 통째로 빌려 쓰는 것이 가능한 구조'라 말할 수 있다.
- 코드의 중복을 배제하는 구조라고 기억하자.
- 상속을 선언한 서브 클래스는 수퍼 클래스의 인스턴스 변수와 메소드의 정의 정보를 그래도 빌려 쓸 수 있는 것과 함게 메소드의 호출 방법도 수퍼 클래스에 맞출 필요가 있다.


객체지향 프로그래밍(OOP)의 진화
- 패키지 : 클래스를 다시 한 번 ‘모으는‘ 구조, 클래스나 패키지를 보관하는 계층 구조를 만든다.
- 예외 : 특별한 오류를 일으킬 가능성이 있는 것을 메소드에서 선언하고, 예외로 처리한다.
- 쓰레기 처리 (garbage collection) : 인스턴스를 제거하는 처리를 시스템이 자동으로 실행하는 구조

프레임 워크
- 어플리케이션의 기본적인 부분을 소스 코드로 제공하는 틀
- 시스템 개발 전체에 대한 진행 방법으로 제공하는 틀

콤포넌트는 클래스보다 밀도가 크고, 소스 형태가 아닌 바이너리 형태로 제공되며, 기능적으로 독립성이 높고, 내부를 몰라도 사용이 가능하다.

설계 패턴은 기능 확장과 재상용을 하기 쉬운 소프트웨어를 만들기 위해 선인들이 궁리해서 만든 노하우 집이다.
- GoF (4인조 갱, Gang of Four) : 23종류의 설계 패턴으로 ‘설계의 정석집’이라 할 수 있음.
- 설계 패턴은 소프트웨어 개발 기술에 있어서 아이디어 자체를 재사용한다고 하는 새로운 장을 열고 있다.


UML(Unified Modeling Language)은 형태가 없는 소프트웨어를 보는 도구
- 소프트웨어의 기능과 구조를 나타내는 그림 그리는 법
- 소프트웨어 개발에 있어서 도식 표현의 집대성
- 전체를 이해하고 기억하는 것을 지원한다.
- 시퀀스 다이어그램과 컴뮤니케이션 다이어그램으로 동적인 정보를 표현한다.
- 시퀀스 다이어그램 : 인스턴스 간의 메소드의 호출을 시계열로 표현한다.
- 커뮤니케이션 다이어그램 : 인스턴스 간의 상호 작용(관계)를 중심으로 표현
- 현실 세계와 컴퓨터 시스템에서 관리해야 할 정보의 구조와 역할 분담을 한 개인과 조직이 서로 협조해서 전체의 일을 달성하는 모습을 표현하기 위해서도 사용됨
- 집합론으로 정리한 결과를 클래스 다이어그램으로 표현
- 역할 분담은 시퀀스 다이어그램과 컴뮤니케이션 다이어그램으로 표현한다.
- 유스케이스 다이어그램으로 컴퓨터에 맡겨지는 일을 표현한다.
- 일의 흐름을 액티비티 다이어그램으로 표현한다.
- 상태의 변화를 스테이트 머신 다이어그램으로 표현한다.

모델링
- 현실세계와 소프트웨어의 차이를 메워준다.
- 모델은 복잡한 현상을 이해하기 위해서 단순화시킨 이론과 가설
- 모델링은 모델을 만드는 것.
- UML을 사용해서 소프트웨어의 기능과 내부 구조를 2차원의 그림으로 표현하는 것

객체 지향 설계
- 소프트웨어를 의인화해서 역할을 분담시킨다.

설계 목표
- 중복을 배제한다.
- 구성품의 독립성을 높인다 (유지 보수성과 재사용성)
- 응집도(cohesion, 점착, 단결, 결합)는 강하게 하고, 결합도(연결, 결합, coupling)는 약하게 한다.
- 의존 관계를 순환시키지 않는다.

유연한 개발 프로세스 (Agile Software Development Process)



Chapter 1. 객체지향 개요

객체지향 모델링
- 모델링 개념 : 모델링이란 모델을 만드는 작업으로서 현실 세계를 단순화시켜 표현하는 기법을 말한다.
- 모델링 목표
1. 해당 실세계 도메인을 잘 반영할 수 있는 모델을 선택해야 한다.
2. 여러 다양한 각도에서 표현할 수 있는 모델들을 만들어야 한다.
3. 개발할 시스템에 적합한 모델을 선택해야 한다.
- 모델링 기대효과
1. 개발할 시스템을 가시화시킬 수 있다.
2. 개발할 시스템에 대해 명세화시킬 수 있다.
3. 개발할 시스템 구축에 대한 기초를 마련할 수 있다.


객체지향 언어
① 클래스
② 객체
③ 상속
④ 추상클래스
⑤ 인터페이스
⑥ 컴포넌트



Chapter 2. 클래스

클래스의 개념
: 클래스는 객체들에 대한 명세 장치 또는 도구이다.

- 클래스의 큭성
- 고유한 이름을 갖는다.
- 속성(Property or Attribute)을 지닌다
: 상태변수, 멤버변수, 멤버 데이터
- 잘 정의된 행위를 지닌다.
: 메소드, 멤버 함수

클래스와 객체
- 클래스는 틀이고, 객체는 실사례이다.
- 클래스는 상태를 갖지 않지만, 객체는 상태를 갖는다.
- 클래스와 객체는 동일한 속성 및 메소드 수를 갖는다.


클래스 추출 기법
(1) 요구사항으로부터 명사나 명사구 추출
(2) 클래스로 적당하지 않은 명사 삭제
- 중복 클래스 : ‘고객’과 ‘구매자’
- 관계없는 클래스 : ‘시스템 구축 비용’
- 불확실한 클래스 : ‘보완’ (광범위하고 불확실함)
(3) 클래스의 속성이나 메소드는 클래스가 될 수 없음
(4) 요구사항의 정의되어 있지 않지만 필요한 클래스 추가
- 인터넷 쇼핑몰의 주문 처리에서 ‘장바구니’



Chapter 3. 객체

객체의 개념
- 물리적 사물 또는 논리적 개념이다.
- 데이터와 해당 데이터를 처리(조작)하는 오퍼레이션들을 포함하는 모듈이다.
- 캡슐화와 정보은닉 도구(장치)이다.

객체의 특성
- 유일한 식별자를 가져야 한다.
- 상태 (데이터/속성) 를 가져야 한다.
- 잘 정의된 함수(데이터/속성)를 가져야 한다.

객체의 생명주기
- 생성 : 선언, 인스턴스화, 초기화
- 사용 :
- 소멸



Chapter 4. 캡슐화의 개념

캡슐화의 정의
- 관련된 데이터와 관련된 함수들을 클래스라는 하나의 캡슐 속으로 그룹화 또는 묶는 장치이다.
- 추상화를 표현하는 장치이다. (추상화가 잘 되면 될수록 프로그램의 모듈화를 향상시킴)

캡슐화의 특성
- 추상화의 단위가 된다. (추상화란 복잡한 문제를 다루기 위해서 불필요한 부분들을 숨기고 중요한 부분만을 표현하는 것)
- 관련된 데이터와 함수들을 하나의 캡슐 단위로 묶어주기 때문에 복잡한 내용들은 캡슐 내부 속으로 모두 숨어버리게 되고 외부에는 캡슐 단위의 의미 있는 단위로만 보여주기 때문에 추상화 단위가 된다.
- 재사용의 단위가 된다.
- 정보 은닉을 실현하는 장치이다.

캡슐화와 정보은닉
- 캡슐화는 관련된 요소들을 묶어줌으로써 캡슐 내부와 외부를 구별 짓는 장치이다.
- 정보은닉은 캡슐 내의 요소들에 대한 세부 구현 사항들을 외부에 숨기는 장치이다.



Chapter 5. 정보 은닉

정보은닉의 정의
- 데이터와 함수를 객체 내부에 숨기는 장치이다.
- 블랙박스이다. 캡슐화가 되어 있는 상태에서 객체 내부에 숨길 데이터와 함수들을 숨기는 것이 정보 은닉이다. 외부에 노출시킬 필요가 없는 데이터와 함수들만 은폐시켜야 한다.
- 외부 객체들과 정보를 주고 받을 수 있는 공개인터페이스(public 함수)를 하나 이상 정의해야 한다. 정보 은닉은 공개 인터페이스를 제공해야 한다.
- 공개 인터페이스는 해당 객체가 다른 객체들에게 자신이 어떠한 서비스를 제공할 수 있는 지를 선언하는 것이다.

정보은닉의 이점
- 추상화를 향상시켜준다.
- 내부 데이터나 알고리즘의 변경이 용이하다
- 모듈의 독립성을 높여준다
- 확장성을 높여준다.




Chapter 6. 메세지

메시지의 정의
- 객체지향 프로그램은 객체들의 집합체이다. 즉, 서로 상호작용하는 객체들로 구성된 시스템이라고 할 수 있다.
- 따라서 단일 객체 그 자체만으로는 의미가 없으며, 하나 이상의 객체들이 모여서 그들 간에 서로 상호작용 해야 객체지향 소프트웨어로서 의가 있게 된다.
- 프로그램 작동의 주체는 클래스가 아닌 객체들이며, 이러한 객체들이 모여서 서로 정보를 주고 받으면서 프로그램이 작동되기 때문이다.
- 메시지는 객체가 다른 객체를 접근하기 위한 장치이다.
- 메시지는 한 객체가 다른 객체에게 서비스를 요청하기 위한 장치이다.
- 메시지를 받을 수신객체, 오퍼레이션명, 매개변수로 구성된다.

메시지의 특성
- 메시지 수신의 대상은 객체이다.
- 메시지는 수신 객체가 갖는 공용 함수들에 해당한다.




Chapter 7. 복합객체

복합객체의 정의
- 복합(composition)화란 한 객체가 다른 객체를 포함하는 것을 말한다. 집단화(aggregation)이라고도 한다.
- 복합객체는 부분객체들이 존재해야만 객체로서 의미가 있다.
- 복합객체에 포함된 부분객체들은 복합객체에 종속적이다.

복합객체의 특징
- 객체가 선언되는 시점에 발생할 수 있다.
- 클래스의 객체 생성함수 내에서 발생할 수 있다.
- 실제 해당 객체를 사용하기 직전에 발생한다.




Chapter 8. 상속

상속의정의
- 데이터나 함수의 재사용을 위한 장치이다. 상속은 동일한 데이터나 함수의 중복 정의를 피하고 공통된 데이터나 함수를 한 곳에 정의하여 재사용하는 개념이다.
- ‘Is – A’ 관계이다.
- 다중 상속은 수퍼 클래스가 둘 이상 존재하는 것이다.

상속의 특성
- 데이터와 함수의 중복성을 제거한다.
- 데이터나 함수의 추가가 용이하다
- 새로운 클래스의 추가가 용이하다




Chapter 9. 추상클래스

추상클래스의 정의
- 추상클래스는 서로 다른 유형의 클래스들의 공통된 행위를 추출하여 정의한 가상의 클래스이다.
- 원래 클래스로 존재한 것이 아니라 여러 클래스들의 공통 행위들이 있어서 중복을 배제하기 위해 일반화시킨 클래스이기 때문에 실제 객체를 생성할 수 없다.
- 따라서 상속 구조에서 객체를 생성할 수 있는 수퍼 클래스와 구별하기 위해 추상 클래스를 별도로 구분하여 정의하고 있다.
- 추상클래스의 목적은 서로 다른 클래스들이 공통적으로 구현된 함수들에 대해 공통된 행위를 추출하기 위함이며, 추상 클래스로부터 서브 클래싱된 모든 클래스들에 대해 단일의 공통 인터페이스를 생성하기 위함이다.
- 즉, 서브 클래스마다 서로 다르게 구현된 함수들에 대한 템플릿 만을 제공하기 위함이다.
예) 아래 그림에서 ‘Order’ 클래스에서 ‘Payment’클래스에 결제를 요청하고자 할 경우, Order 클래스는 Payment 클래스의 하부 클래스들에게 직접 pay( )함수를 요청할 필요없이, Payment 클래스의 processPayment(Payment p)함수만 호출하고, 매개 변수로 결제할 결제 객체만 넘겨주면, 해당 객체에 따라 동적으로 바인딩되어 결제 함수가 이루어진다.
- 추상 클래스는 적어도 하나 이상의 함수를 가져야 한다.

추상클래스의 특성
- 재사용성을 높일 수 있다.
- 서브 클래스 객체들을 추상 클래스 객체들로 대치시킬 수 있다. 즉, Payment 타입의 객체 p가 선언되었지만 p에는 Product 객체가 아닌 Product의 하위 클래스인 Cash나 CreditCard 등의 객체들이 대치된다. 이것이 바로 ‘Is – A’ 관계로 인해 이루어지는 대치성이다.
- 만일 이 대치성이 없다면 하위 클래스 별로 processPayment( ) 이라는 함수가 각각 존재해야 한다. 그러나 대치성으로 인해 추상 클래스인 수퍼 클래스 한곳에 한번만 정의해도 하위 클래스의 객체 누구나 다 가능하게 된 것이다.
- 이는 코드의 재사용성 뿐만 아니라 프로그램 복잡도의 간결화를 가져다 준다.
- 서로 다른 종류의 객체들을 수집할 수 있다. 즉, processPayment(Payment p) 에서 p에는 서로 다른 하위 클래스 객체들이 들어갈 수 있다.
- 유지 보수성을 향상시킬 수 있다.
- 확장성을 높일 수 있다.




Chapter 10. 인터페이스

인터페이스의 정의
- 인터페이스의 사전적 정의는 사물 간 또는 사물과 인간 사이의 의사 소통이 가능하도록 일시적 혹은 영구적 접근을 목적으로 만들어진 물리적, 가상적 매체를 의미
- 인터페이스는 특정 기능을 수행하기 위해 선언된 함수들의 집합
- 인터페이스는 소프트웨어 서비스에 대한 명세이다

인터페이스의 특성
- 함수의 선언만 표현한다. 모두 public 함수들이어야 한다
- 객체를 생성할 수 없다.
- 클래스와 상속 관계를 맺을 수 없다.
- 변수를 포함할 수 없다. (상수만 정의 가능하다.)
- 명세와 구현을 분리할 수 있다. 인터페이스는 소프트웨어공학에서 말하는 관심분리(Separate of Concern)의 원칙을 반영한 장치이다. 즉, 인터페이스는 명세를 표현하는 장치이고, 이를 구현하는 것은 클래스 혹은 컴포넌트가 된다.



※ 인터페이스와 추상클래스
인터페이스
- 스펙이 동일한 다양한 클래스를 정의하기 위한 도구
- ‘interface’ 키워드를 사용하여 인터페이스 정의
- 함수의 시그니쳐만 존재하며 함수 구현부가 없는 함수로만 구성
- 인터페이스의 모든 함수는 구현 클래스에서 반드시 구현되어야 함
- 인터페이스의 구현 클래스는 ‘implements’ 키워드를 사용함

추상클래스
- 자식 클래서에서 반드시 구현되어야 하는 스펙을 정의하기 위한 도구
- ‘abstract’ 키워드를 사용하여 추상클래서를 정의
- 함수의 시그니처만 존재하며 함수 구현부가 없는 추상함수가 1개
- 이상 존재함 (해당 추상함수는 ‘abstract’ 키워드를 사용함)
- 추상클래스의 모든 추상함수는 자신 클래스에서 반드시 구현되어야 함
- 추상클래스는 상속을 이용하므로 ‘extends’ 키워드를 사용함



Chapter 11. 다형성

다형성의 개념
- 다형성(polymorphism)이란 ‘여러 개의 형태를 가진다’는 의미의 그리스어에서 유래된 말로서 특정한 심벌이나 연산자에 대해 상황이 다르면 그 의미도 다르게 부여할 수 있는 특성을 말한다.
- 다형성은 특정 심벌이나 연산자에 대해 상황 별로 의미를 달리 부여하는 장치이다.
- 객체지향에서는 이러한 다형성을 오버로딩(overloading, 중첩)과 오버라이딩(overriding, 재정의) 두 가지 형태를 모두 포함하고 있다.
- 오버로딩은 다시 연산자 오버로딩과 함수 오버로딩으로 분류하고 있다.
- 다형성을 동적 바인딩이라고 한다.

다형성의 특성
- 코드의 재사용성을 높여준다
- 일관된 인터페이스를 제공한다. 자바의 효율적인 다형성을 활용하기 위해서는 상속 구조를 통해 수퍼 클래스가 추상 클래스나 인터페이스 형태를 취하는 것이 바람직하다.
- 이렇게 함으로써 하위 서브 클래스들이 수퍼 클래스에 종속되는 것을 피할 수 있다.
- 그리고 수퍼 클래스에는 간단히 함수 선언 정도만 다루고, 하위 서브 클래스들은 상세한 함수 구현을 해야 한다. 이를 다른 말로 ‘인터페이스에 프로그램한다’라고 한다.
- 이렇게 되면 이 클래스를 접근하는 다른 객체들은 하나의 통로(인터페이스 메소드나 추상 메소드)로 다양한 유형의 객체들을 접근할 수 있다.
- 즉, 외부 객체는 해당 메소드를 구현하는 객체들이 누군지 일일이 신경쓰지 않고도 하나의 메소드로 여러 유형의 객체들을 동적으로 사용할 수 있다.
- 모듈화를 높여준다.



정적바인딩
- 컴파일 시에 호출될 함수가 결정(바인딩)
- 실행 시에는 컴파일 시점에 결정된 함수를 호출

동적바인딩
- 컴파일 시에는 호출될 함수가 결정되지 않음
- 실행 시에 호출될 함수가 결정 (바인딩)
- 추상함수를 구현한 구현 클래스의 함수를 동적으로 호출



Chapter 12. 컴포넌트

컴포넌트의 정의
- 컴포넌트는 독립적이면서 물리적으로 교체 가능한 부품이다.
- 컴포넌트는 잘 정의된 아키텍처 상에서 어떠한 기능을 수행하는 시스템의 독립적이면서 교체 가능한 부품이다. 컴포넌트는 인터페이스들의 집합에 대한 물리적인 구현을 제공한다.
- 컴포넌트는 동적으로 바인드될 수 있는 하나 이상의 모듈들을 하나의 단위로 관리하는 패키지로서, 실행 시간에 인터페이스를 통해 접근 가능하다.
- 컴포넌트는 계약상으로 명시된 인터페이스들과 명확한 문맥 의존성을 가진 컴포지션의 단위로서 독립적으로 보급될 수 있다. 여기서 계약상으로 명시된 인터페이스라는 것은 표준화된 인터페이스 규정을 따른다는 것이다.
- 컴포넌트는 자발적인(autonomous) 비즈니스 객체 또는 비즈니스 로직을 소프트웨어로 구현할 것이다. 여기서 말하는 자발적이라는 의미는 독립적이라는 푠현으로 대체 가능하다. 즉, 한 컴포넌트는 독립적인 업무 단위로 개발해야 이후 교체를 하거나 재사용하기가 편리하기 때문이다.

컴포넌트의 특성
- 100% 구현되어 있어야 한다.
- 스펙이 있어야 한다
- 표준을 따라야 한다
- 패키징되어야 한다
- 독립적으로 배포 가능해야 한다.