최근 회사에서 파이썬 스터디를 진행하면서 OOP 관련된 이야기가 나왔고, 생소한 개념에 압도당했다.
사실 OOP만 검색하면 다른 좋은 책과 강의가 많다. 그래서 더 어려웠다.
”이렇게 사용하면 돼, 이게 상속이고 이게 다형성이야” 컴퓨터공학 내에서 가장 주관적이라고 표현한다.
그렇기때문에 해석에 따라 다른 해석이 존재한다. 여기서 이야기하는 것도 정답은 아니라고 생각한다.
이 책은 회사 동료가 추천한 책이고, 파이썬을 처음 시작할때 입문한 책이라고 한다. 직접 읽어보니 파이썬과 문법이 거의 비슷해서 이해하는데 크게 거슬리지 않았다.
서론
침대에서 일어나고 양치를 하고 커피를 마시고 옷을 입고 출근을 한다. 세상은 순차적이고 우리의 아침이 이런 순서로 짜여 있다면 행동 하나하나를 코드화 할 수 있다.
세상은 객체지향적이기도 하다.
배우자와 고양이, 그리고 고양이와 차고의 자전거. 이 모든 우리의 생활이 연관되어 있을 수도 있다. 각자의 방식을 가지고 동작하며, 동시에 예측가능한 방식으로 서로 연관되어 있다.
‘배우자가 고양이를 밟다’라는 순차적인 행동묶음에 대한 코드를 만들 필요가 없다. 객체지향의 세계에서 우리에게 필요한 건, ‘한 발을 내딛는 배우자’ 와 ‘밟히기 싫어하는 고양이’ 객체이다.
객체지향의 디자인은 세상을 이미 정해진 절차들의 묶음으로 생각하지 않고, 객체가 서로 주고 받는 메시지들의 연쇄로 파악할 것을 요구한다.
객체지향 디자인의 실패는 코딩 능력의 부족이 아니라, 관점의 실패라고 본다.
디자인이 해결할 수 있는 문제들
아무것도 변하지 않는다면 코드를 최초 한 번만 작성하면 될 것이다. 구조를 신경쓰지 않아도 된다. 하지만 불행이도 무언가는 분명히 변한다. 그 어떠한 애플리케이션도 변화로부터 자유롭지 않다.
좋은 디자인은 애플리케이션의 수정과 확장에 용이하게 만들어준다.
왜 수정은 어려운가
객체지향의 애플리케이션은 상호작용(메세지를 전달하는 행위를)하는 객체로 구성되어 있고, 각 객체의 상호작용이 동작을 만들어낸다.
상호작용을 하는 두 객체 사이에는 의존성이 만들어지고, 이런 의존성이 애플리케이션을 수정하기 어렵게 만든다.
결국 객체지향 디자인은 의존성을 관리하는 것이고, 객체가 변화를 받아들일 수 있도록 만드는 과정이다.
실용적인 디자인
모든 애플리케이션은 코드의 묶음이다. 코드를 배치하는 행위 자체가 디자인이다.
같은 코드를 가지더라도 두 명의 개발자는 다른 결과를 낸다. 각자가 생각하는 견해에 따라 코드가 다르게 배치되기 때문이다.
우리는 오늘 완성해야 하는 기능을 구현하는 코드를 짜고, 동시에 내일 수정하기 용이한 코드를 만들어야 한다.
자칫 미래를 예측하는 것처럼 보인다. 예측할 수 없는 특수한 요구사항을 생각하는 것은 좋지 않은 디자인을 만들어 낼 확률이 높다.
디자인은 나중에 디자인할 수 있는 여지를 남겨놓기 위한 것이고, 그 최종 목표는 변화의 비용을 최소화하는 것이다.
디자인 원칙과 패턴
여러 디자인 원칙들이 있다. 이러한 원칙은 어디서 온걸까? 정말 가치 있는, 입증할 수 있는 경험적 근거가 있는가?
이 모든 원칙들은 누군가 코드를 작성하면서 내렸던 선택에서 시작되었다.
초기에 프로그래머도 우리와 같이 앞서 디자인되지 않은 애플리케이션에서 어려움을 겪었다. 그러한 이유로 ‘어떻게 하면 좋은 코드를 만들 수 있을지’에 대한 견해를 발전시켰다. 코드의 좋음을 수량화 시키려는 시도가 있었다.
디자인 패턴은 객체지향 소프트웨어 디자인에서 명확한 문제를 처리하는 간단하고도 우아한 기술이라고 말한다.
잘 알려진 이러한 패턴은 오랜 시간 증명된 완벽한 오픈소스 해결책이다.
요약
변화를 손쉽게 받아들일 수 있도록 코드를 배치하는 일, 그것이 디자인이다.
디자인은 원칙과 패턴을 가지고 있다. 원칙을 올바르게 적용하고 적절한 패턴을 사용했다고 해도 수정하기 쉬운 애플리케이션을 만들었다고 확신할 수는 없다.
결국 올바른 순간에 필요한 만큼 적용할 줄 알아야한다. 디자인의 성공과 실패는 결국 디자이너(개발자)에게 달려있다.
댓글