"개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴_최범균"
"Effective Modern C++-Scott Douglas Meyers"
위 두 서적을 공부하며 정리하는 게시물 입니다.
**게시물 내용 중 기술적인 부분에 추가 설명이 필요할 경우 부록 참조
-> 붉은 글씨로 강조된 부분은 전부 부록에 설명 추가하겠습니다.
1. 비슷한 기능을 가진 처리 코드를 추가할 때
- 문제점
-> 대부분 복붙을 많이한다.
=> 점점 코드가 길어지고, 개별 수정사항을 찾을 때 시간이 많이 소요된다.
=> 전체 수정사항을 반영할 때 누락되는 부분이 생긴다.
- 해결법
-> 공통적인 기능을 묶는다.
=> interface를 추가하고 implement를 사용하여 각 클래스에서 공통 interface를 사용하도록 한다.
2. (예제는 추가하자)
공통의 인터페이스를 두고 사용한다고 할 때 인터페이스 내에서 기능을 분리하는 것이 좋다.
예를들면 메뉴를 추가하는 기능과 화면을 전환하는 기능이 있을 때 가독성을 위해 이벤트 처리를 분리하는 것이 바람직 하다.
3. 절자 지향
절차 지향을 사용하며 다수의 프로시져가 동일한 데이터를 공유하며 사용한다.
자연스럽게 데이터 중심이 되고 이는 다음과 같은 문제점을 발생시킨다.
1) 데이터 타입이나 의미를 변경해야 할 때, 함께 수정해야 하는 프로시저가 증가한다.
2) 같은 데이터를 프로시저들이 서로 다른 의미로 사용하는 경우가 발생한다.
서로 다른 함수에서 같은 데이터를 사용한다면, 함수 마다 사용하는 매개 변수 타입을 모두 변경해줘야 한다.
4. 객체 지향
각 객체는 각각의 데이터와 프로시저를 갖는다.
객체는 자신만의 기능을 제공하며, 각 객체들은 서로 연결되어 다른 객체가 제공하는 기능을 사용할 수 있다.
객체는 다른 객체에 기능을 제공하기 위해 프로시저를 사용하는데, 이때 프로시저는 자신이 속한 객체의 데이터에만 접근할 수 있다.
객체 지향의 가장 기본은 객체이다.
객체는 데이터와 그 데이터를 조작하는 프로시저 (오퍼레이션, 메서드, 함수)로 구성된다.
객체가 제공하는 기능을 오퍼레이션이라고 부른다.
즉, 객체는 오퍼레이션으로 정의된다.
오퍼레이션을 사용하려면 사용법을 알아야한다. -> 사용자는 이 부분만 알면된다.
1) 기능 식별 이름
2) 파라미터 및 파라미터 타입
3) 기능 실행 및 결과 값
객체가 제공하는 모든 오퍼레이션 집합을 인터페이스라고 부른다.
서로 다른 인터페이스를 구분할 때 사용되는 명칭이 type이다.
인터페이스는 객체를 사용하기 위한 일종의 명세나 규칙이라고 생각하면 된다.
실제 객체의 구현을 정의한ㄴ 것은 클래스이다.
클래스에는 오퍼레이션을 구현하는데 필요한 데이터 및 오퍼레이션의 구현이 포함된다.
클래스를 이용하여 메모리에 객체를 생성하고, 이때 메모리에 생성된 객체를 인스턴스라고 한다.
인스턴스는 00 타입 (00 인터페이스)에 정의된 기능 (오퍼레이션)을 제공한다.
오퍼레이션의 실행을 요청하는 것을 메시지라고 한다.
더 위에서 설명한 interface는 자바의 기능
-> C++에서는 추상 클래스를 이용하여 비슷한 결과를 만들 수 있음
5. 객체의 책임과 크기
객체는 객체가 제공하는 기능으로 정의된다고 했는데, 이는 다시 말하면 객체마다 자신만의 책임이 있다는 의미를 갖는다.
ex)
ㄱ.암호화 처리 객체
(제공받은 데이터를 암호화해서 다른 파일에 보내는 책임)
ㄴ.파일 읽기 객체
(파일에서 데이터를 읽어와 제공하는 책임)
ㄷ.파일 쓰기 객체
(파일에 데이터를 쓰는 책임)
ㄱ->ㄴ: read() 실행 요청
ㄱ->ㄷ: write() 실행 요청
ㄴ->ㄱ: byte 배열 리턴
-> 괄호 안이 각 객체의 책임이다.
한 객체가 갖는 책임을 정의한 것이 바로 타입/인터페이스이다.
서로 다른 책임을 구분하고 할당하기 위해선 프로그램을 만들기 위한 기능 목록을 정리해야 한다.
각 기능들을 어떻게 분배하느냐에 따라서 객체의 구성이 달라진다.
모든 상황에 들어맞는 객체-책임 구성 규칙이 존재하지는 않지만, 객체가 얼마나 많은 기능을 제공할 것인가에 대한 확실한 규칙은 있다.
* 객체가 갖는 책임의 크기는 작을수록 좋다!
한 객체가 많은 기능(책임)을 포함하면, 절차지향 방식과 같은 구조를 갖게 된다.
각기 다른 기능이 데이터를 공유하여 사용하는 것을 문제로 보는 듯 하다.
-> 앞에서 말한 절차 지향 방식의 문제점 때문에! (경직성 문제 <-> 반대는 유연성)
이와 같이 객체의 크기와 관련된 원칙이 있는 데 그 원칙을 단일 책임 원칙(Single Responsibility Principle: SRP)이라고 한다.
-> 한 객체는 하나의 책임만 가져야 한다.
(그림 첨부하자)
단일 책임 원칙을 따르다 보면 자연스럽게 기능의 세부 내용이 변경될 때, 변경해야 할 부분이 한 곳으로 집중된다.
ex)
파일을 읽는 방법을 변경해야 할 때 파일 읽기 책임을 가진 객체의 코드만 수정된다.
암호와 알고리즘을 변경해야 할 경우 'byte 암호화' 객체의 코드만 변경된다.
** 객체의 책임 = 객체의 역할!
'기타(임시)' 카테고리의 다른 글
객체지향 부록 #2 생성자와 소멸자, this, 접근제어 지시자 (0) | 2020.07.31 |
---|---|
객체지향_부록 #1: extends, implements, interface, 순수 가상함수, 추상 클래스, 클래스 객체, 포인터, 다형성, 상속과 생성자 (0) | 2020.07.30 |
저장 (0) | 2020.07.08 |
현대자동차 (0) | 2020.05.22 |
프로젝트에 관하여 (0) | 2020.05.21 |