티스토리 뷰

공부

[책]객체지향의 사실과 오해 정리

크덩크덩 2021. 1. 8. 14:59

 

객체지향이란?

 

객체지향프로그램 설계는 어플리케이션이 객체들이 어플리케이션 구동이라는 목표를 위해 각자의 역할을 책임을지고 협력하는 프로그램이다. 전체 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법

객체는 각자가 충분히 자율적이야하고 다른 객체가 봤을 때 무엇을(what)하는지 알 수 있지만 내부가 어떻게(how)처리하는 지는 알 수 없어야한다. → 알아서 자율적으로 책임지고 처리해야한다. 다른 객체가 참여하면 객체지향적인 프로그래밍과는 거리가 멀어진다.

객체 간에는 공동의 메세지만 주고 받는다. 따라서 객체지향 설계는 이 객체들을 얼마나 적절한 책임을 선택하고 지정하는지가 핵심이다. 따라서 평소에 객체지행적으로 사고의 중심을 전환해야지 훌륭한 객체지향 설계를 할 수 있다.(프로그램을 객체간의 협력적인 관계로 생각하는 사고의 전환)

 

객체지향적인 사고를 하는 이유?

복잡한 관계를 정리하고 사고하기 위해서 이다. 인간의 인지력은 한계가 있기 때문에 프로그래밍의 복잡함을 극복하기 위한 방법이다. 따라서 객체 구분은 인간의 개념에서 물리적이나 개념적으로 구별할 수 있는 경게를 지닌 어떤 것이다.(자동차- 물리적, 시간-개념적 등)

타입도 객체다.

타입도 결국 숫자 문자지만 메모리에는 010101등으로 저장된다. 이를 해석(저장,연산 등) 하는것은 객체가 해버린다. 개발자들은 어떤 방식으로 저장되는지 몰라도 그냥 대표적인 연산 명령어 등으로 쓰면된다 이런의미에서 객체다

객체의 상태

프로퍼티. 행동에 대한 결과이다. 만약 과거의 행동을 모두 백트레킹해서 결과를 도출한다면? 매우 복잡할 것이다.(=과부하) 따라서 과부하를 줄이기 위해 과정과 결과를 간편하게 기술하기 위해 상태라는 개념을 고안한 것이다. 변수가 있는 이유로도 설명할 수 있을 것 같다.

객체의 행동

메소드. 상태를 변경시키는 객체의 행동. 현재 상태에 의존적이고 결과적으로 상태를 변화시킨다. 행동을 할 때 메세지를 통해 다른 객체의 상태도 변경시킬 수 있다.(예시. 음료수를 마시는 사람의 구현에서 음료수의 양 변화) 이 때 사람 객체에서는 메세지만 전달하면된다(협력). 음료수의 양변화 등은 전적으로 음료수 객체에서 처리한다. 사람은 음료수 객체의 양에 대해서는 전혀 알지 못하고 알 필요가 없다.(=캡슐화). 객체가 각자 지능적으로 다른 것에 의존하지 않고 처리할 수 있어야한다.(스스로 결정!) 결국 이 과정은 객체의 자율성이 높아진다고 볼 수 있다.

자율성이 높아진다면? 재사용성이 매우 높아진다.

캡슐화

만약 어떤 객체가 캡슐를 뚫고 내부적인 것들을 건드릴 경우 객체들의 분류 체계가 급격하게 위험해지고 모호해진다. 이건 유연하지 못한 설계이다

지금까지는 인간세상을 바라보는 신의 입장에서처럼 전체적인 코드 구성를 내려다봐서 객체에 대한 생각을 별로 하지 못했는데 한 단계 내려가서 객체의 입장에서 다른 객체를 바라본다면 이런 개념들이 중요해진다.

설계시

변수같은 상태를 중심적으로 생각하지말고 행동을 먼저 중점적으로 생각해라 행동이 상태를 변경시킨다. 전체 어플리케이션이 어떤 행동을 원하는지를 중심적으로 생각하면 어떤 객체들이 적합한지 어떤 협력관계를 구성할 지 결정할 수 있다. 내부적인 데이터는 다 달라도 된다. 하지만 행동을 기준으로 설계해야한다. 같은 객체는 행동(메세지)이 같다. 내부적으로 어떤 처리를 하는지는 서로달라도 행동이 같으면 같은 객체라고할 수 있다 .

추상화

추상화는 소프트웨어의 복잡성을 극복해준다. 필요없는 부분을 줄이고 단순화 하는 수단이다.

객체간의 협력

객체의 책임관계를 잘 구성해야 훌륭한 설계가 가능하다. 만약 어떤 행동을 할 때 각 객체의 책임이 이리저리 부유하는 상황이라면 변경에 매우 취약하고 다양한 협력에 참여할 수 없는 비자율적인 객체가 생성된다. 협력을 설계하는 것은 요청과 응답의 흐름을 결정하는 것.

다형성

동일한 메세지에 대해 각 객체들이 다른 방법으로 반응하는 것. 객체가 각자 처리하는 방법은 달라도 메세지가 동일하면 다른 객체와 협력하는 것이 문제가 없다. 객체가 어떤 객체와 메세지를 주고 받던지 내부적인 것을 건드리지 않는다면 결합도가 낮아진다.(자율성 증가)

- 예시를 여기서 참고하면 좋을 듯 https://opentutorials.org/module/516/6127

인터페이스

인터페이스는 경계선에서 서로 연결해주는 상호간의 방법이나 장치를 뜻한다. 좋은 예시는 자동차의 핸들, 기어 등 내부적인 기능을 몰라도 핸들,기어만 알면 내부의 복잡한 모두 알지 못해도 자동차 운전이 가능하다. 내부의 복잡함을 감추고 최소한의 정보만 제공할 수 있다. 메세지 기반으로 설계하면 된다.

구현

구현은 객체 내부의 인터페이스와 작동방식 내부와 외부를 확실하게 분리해서 고려해야한다. 소프트웨어는 항상 변경되기 때문에다. 수 많은 객체가 물고 물리며 돌아가는 객체 프로그램에서 재사용, 유지, 보수를 할 때 어떤 객체가 영향을 받는지 일일이 찾는 것은 불가능하다. 객체의 모든 것이 외부에 공개되어 있다면 아무리 작은 부분만 수정하더라도 파급효과가 줄줄이 객체 공동체의 구석구성에서 나올 것이다.

 

 

코딩을 할 떄 하나를 수정하면 줄줄이 따라가가서 연쇄적으로 수정했던 경험이 많았다. 결국 스파게티 코드로 변질...ㅋㅋ

학부시절 객체지향 개념적인 부분만 달달 외우듯이  공부했는데  구석구석을 정리하는 것은 의미 없는 것 같다.

 

객체지향은 사고의 전환이 가장 중요한 것 같다.

책일 읽은 후에 사고의 전환은 많이 된 것 같아서 앞으로 꼭 신경쓸 수 있을 것 같다.

잠깐 알고리즘을 풀 때도 간단한 프로그램을 작성할 때도 항상 생각할 것(객체지향도 정답은 없다. 연습!)

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/05   »
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
글 보관함