-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
92 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,92 @@ | ||
## Chapter 1 : 협력하는 객체들의 공동체 | ||
- 객체지향의 목표 : `역할 / 책임 / 협력` | ||
- `객체지향` 패러다임의 핵심은 `자율적인 객체`들의 `협력` | ||
- 메시지를 주고받는 객체들의 `동적인` 관계 = 어떤 객체들이 `어떤 메시지`를 주고받으며 `협력`하는가 | ||
|
||
<br/> | ||
|
||
- [협력](#협력) | ||
- [책임](#책임) | ||
- [역할](#역할) | ||
- [객체](#객체) | ||
- [메시지와 메서드](#메시지와-메서드) | ||
- [생각해볼 점](#-생각해볼-점) | ||
|
||
<br/> | ||
|
||
### 협력 | ||
특정한 책임을 수행하는 역할들이 각각 받은 `요청에 성실히 응답`하는 것 | ||
- 클래스 : 객체들의 협력관계를 코드로 옯기는 도구 | ||
- 메서드 : 객체가 수신된 메시지(요청)를 처리하는 방법 | ||
- 메시지에 대응되는 메서드 실행 | ||
|
||
<br/> | ||
|
||
### 책임 | ||
맡은 역할에 대해 `수행해야 할 의무` | ||
- 객체지향 설계의 품질을 결정하는 가장 중요한 요소 | ||
- 얼마나 적절한 책임을 선택하느냐! | ||
- 책임이 불분명한 객체 -> application의 미래 불분명 | ||
|
||
<br/> | ||
|
||
### 역할 | ||
관련성 높은 `책임의 집합` = 협력 안에서의 객체의 책임이나 임무 | ||
|
||
- 유연하고 재사용 가능한 협력관계를 구축하는데 중요한 설계요소 | ||
- 역할이라는 단어는 의미적으로 책임이란 개념 내포 | ||
- `특정한 역할은 특정한 책임`을 암시 | ||
- 역할은 `대체가능성` 의미 | ||
- 대체 가능한 역할과 책임 => 다형성과 깊이 연관 | ||
|
||
<br/> | ||
|
||
### 객체 | ||
협력에 참여하는 주체, 스스로 결정하는 자율적인 존재 | ||
- `상태, 행위` 필요 | ||
- 협력에 참여하기 위해 특정한 행동을 해야한다면 이에 따른 상태도 함께 지녀야 함 | ||
|
||
<br/> | ||
|
||
**객체의 자율성** | ||
- 객체의 자율성은 객체의 `내부`와 `외부`를 명확하게 구분하는 것으로부터 나옴 | ||
- 객체의 `사적인 부분`을 `스스로 관리` = 외부에서 간섭 못하게 차단 + `접근 허락된 수단` 통해서만 소통가능 | ||
- `무엇 수행`하는지는 알지만, `어떻게 수행`되는지는 모름(캡슐화) | ||
- 무엇을 수행하는지 알 수 있음 = 객체의 행동을 아는 것 | ||
- 어떻게 수행하는지 알 수 없음 = 객체의 상태 변화를 모르는 것 | ||
|
||
<br/> | ||
|
||
### 메시지와 메서드 | ||
**메시지** | ||
요청과 응답을 위한 객체들의 의사소통 수단 (외부의 요청이 무엇인지 표현) | ||
= 객체가 무엇을(what) 수행하는지에 관해 공개된 부분을 말함 | ||
|
||
<br/> | ||
|
||
**메서드** | ||
객체가 수신된 메시지를 처리하는 방법 (요청을 처리하기 위한 구체적인 방법) | ||
= 객체가 어떻게(how) 수행하는지에 관해 숨겨진 부분을 말함 | ||
|
||
=> 메시지와 메서드를 분리함으로써 협력에 참여하는 객체들 간의 자율성을 증진시킬 수 있음 | ||
|
||
<br/> | ||
|
||
### 마무리 | ||
`객체지향`이란 `역할과 책임`이 있는 `객체`들이 연쇄적인 요청과 응답을 통해 `협력하는 공동체`를 창조하는 것 | ||
|
||
<br/><br/> | ||
|
||
### 💡 생각해볼 점 | ||
- 왜 캡슐화를 해야 객체지향적인 코드인지 생각해보는데에 도움이 되었다 | ||
- 왜 객체지향을 써야할까 | ||
- 좋은코드를 짜야하는데 객체지향은 좋은코드를 짜기 위한 방법이니까 | ||
- 그러면 `좋은코드`란 무엇일까 | ||
- 내가 생각하는 좋은 코드 : 변경하기 쉽고(쉽게 기능을 추가하거나 수정할 수 있고), 이해하기 쉬운 코드 = `유지보수가 쉬운 코드` | ||
- 유지보수가 쉬우려면 변경이 적게 전파되어야 한다 | ||
- 그러한 좋은 코드로 가기 위해서는 복잡해서는 안되고, 추상화하고 구조화 해야 가까워질듯 하다 | ||
|
||
=> 그러한 면에서 객체지향은 각 객체가 캡슐화 되어있으면서 추상화하자가 목표이기에, | ||
변경의 전파가 적게끔 할 수 있으니 좋은 코드를 작성하는데에 도움이 된다 그러니 써야한다가 나의 결론 | ||
|
||
<br/> |