객체지향의 탄생-객체지향 글쓰기

 

1. 객체지향 글쓰기

프로그램 개발자가 가장 싫어하는 일중 하나는 문서 작성이다. 나도 문서 작성을 밤새 야근 하는 것처럼 싫어한다.

 

개발자들이 문서 작성을 싫어하는 결정적인 이유는 개발자 문서 작성이 '단순반복 노가다성'이기 때문일 것이다. 화면 캡춰나 기능에 대한 가이드 라인 설명 문구는 지극히 단순 작업으로 개발자를 지치게 하는 요소 중의 하나이다.

 

그리고 개발자와 글쓰기라는 단어 자체가 북극과 남극처럼 멀리 떨어진 이미지로 느껴진다. 개발자 중 글쓰기를 좋아하는 사람은 많지 않다. 이유는 아마도 프로그램 개발은 이공계 영역이고 글쓰기는 인문계 영역이라는 극단의 차이가 이 둘은 별개의 사고영역이라 생각하면서 내가 잘하기 힘들고, 내가 싫어하는 영역이라고 처음부터 단정짓는 것이 아닐까 싶다.

 

그러나 개발자인 나는 글쓰기를 좋아한다. 내가 글쓰기를 좋아하는 이유는 '복잡하게 얽힌 내 생각을 깔끔하게 정리' 하는 글쓰기 효과가 재미있기 때문도 있지만 글쓰기를 할 때 프로그래밍을 하듯 쓰기 때문에 프로그래밍으로 단련된 내 능력과 프로그래밍을 통해 얻는 재미가 글쓰기에서도 그대로 살아있기 때문이다.

 

프로그래밍과 관련하여 여러 가지 프로그래밍 방식이 있지만 내가 주로 하는 것은 '객체지향' 프로그래밍이다.

 

나는 글쓰기를 프로그래밍 하는 마음으로 쓰긴 하는데 한번 제대로 적용하고 싶어졌다. 엉뚱하지만 창의적인 시도이다.

 

+ 객체지향 프로그래밍이란 무엇인가

 

먼저 객체란 무엇인가? 객체의 사전적인 정의는

 

'객체 지향 프로그래밍이나 설계에서, 데이터(실체)와 그 데이터에 관련되는 동작(절차, 방법, 기능)을 모두 포함한 개념.   예를 들어 기차역에서의 승차권 발매를 생각할 때, 실체인 '손님'과 동작인 '승차권 주문'은 하나의 객체이다. 실체인 '역무원'과 동작인 '승차권 발매'도 하나의 객체이다.'

 

그리고 객체지향 프로그래밍의 사전적인 정의는

 

'독립적인 각각의 객체로 프로그램이나 시스템을 구성하는 일.'

 

그렇다면, 내가 생각하는 객체지향 프로그래밍은

 

'독립적인 각각의 객체를 이용, 각 기능간의 의존성은 줄이고 내부 기능을 강화하는 식으로 프로그램이나 시스템을 구성하여, 개발을 깔끔하게 진행하고 편하게 유지보수 하고 기능을 쉽게 확장할 수 있는 품질 좋은 S/W를 지향하는 개발 기법이다'

 

 

+ 객체지향의 어떤 요소가 품질 좋은 S/W 개발을 가능하게 하는가

 

- 어떤 종류의 프로그래밍 개발 방식에도 적용되는 대원리 2가지

1. 낮은 결합도, 높은 응집도(Low Coupling, High Cohession) 각 기능간의 의존성은 줄이고 내부 기능을 강화하는 소프트웨어 공학의 전통 이론   2. OAOO(Once And Only Once) 하나의 코드가 다른 부분에 존재해서는 안 된다는 뜻이다. 만약 똑 같은 코드가 여러 군데 존재하면 그들 중의 어떤 것은 시간이 흘러갈수록 구식이 될 것이다.

 

- 객체지향의 기본 요소

1. 유일성과 책임 객체는 하나의 기능/책임만을 수행해야 하며 그 기능/책임은 모든 객체중에 오직 자기만 수행해야 한다. -> 코드의 중복 없는 깔끔한 개발 및 관리 가능   2. 캡슐화와 정보은닉 캡슐화는 관련있는 여러 정보들을 어떤 틀안에 담는 것이다. 정보은닉은 외부에 필요 없는 정보들을 노출시키지 않고 숨기는 것이다. -> 객체간의 의존성을 줄여주고(결합도) 내부 기능성을 강화한다. (응집성)   3. 상속과 폴리모피즘 객체간 모계 구조의 계층도를 만들어서 자식이 부모 객체의 기능을 재사용할 있고, 해당 계층도의 부모 객체를 대표로 선언하고 자식을 부모 객체처럼 각 기능간에 주고 받으면서 재사용성과 유연성을 향상시킬 수 있다.

 

- 위의 두가지 요소를 발전시킨 3가지 요소

1. ORR (One Responsibility Rule) 객체는 한가지 종류의 책임만을 다음과 같이 수행해야만 한다. a. 그 책임에 해당하는 일을 빠짐없이 모두 해야 한다. b. 그 일을 다른 객체보다 더 잘 할 수 있어야 한다. c. 그 일을 자신만이 유일하게 한다.   2. OCP (Open Closed Principle) 한번 만들어진 객체는 기능을 확장할 수는 있지만 수정해서는 안 된다. 수정을 하게 되면 관련된 다른 객체까지도 영향을 받는다. 확장을 하는 방법은 상속이나 폴리모피즘을 통해 이루어진다.   3. LoD (Law of Demeter) 객체의 메소드(동작)은 다음 객체들의 메소드만 호출해야 한다. 는 정의로 낮은 결합도와 관계 있는데 글쓰기와 관계가 거의 없으므로 나머지 설명은 생략한다.   * 참고 : 객체지향 방법론 설명 출처는 '디자인 패턴과 리팩토링' 책에서 발췌

 

+ 이제 객체지향 요소를 글쓰기에 대입하여 보자.

 

1. 객체지향 구성 요소의 글쓰기 적용

 

객체는 하나의 단락   필드(속성, 데이터)는 글의 주제 및 주제와 관련된 재료   메소드(동작, 함수)는 하나의 문단   객체 간의 연결은 '그러나, 그래서, 그런데' 등의 접속사

 

2. 객체지향 방법론의 글쓰기 적용

 

- 어떤 종류의 프로그래밍 개발 방식에도 적용되는 대원리 2가지

 

1. 낮은 결합도, 높은 응집도(Low Coupling, High Cohession) 글의 각 단락간에 잦은 수식어, 접속사, 내용 중복 등으로 지저분하게 연결되면 안되며, 각 단락은 고유의 주제와 목표를 담고 있어야 한다.   2. OAOO(Once And Only Once) 하나의 주제를 담은 단락이 다른 부분에 존재해서는 안 된다는 뜻이다. 왜냐면 만약 비슷한 내용이 여러 군데 존재하면 독자들이 식상해 하고 지저분하게 보일것이며 각 단락의 존재 여부가 희미하게 된다.

 

- 객체지향의 기본 요소

1. 유일성과 책임 글의 단락은 하나의 주제/목표만을 수행해야 하며 그 주제/목표는 모든 단락중에 오직 자기만 담고 있어야 한다. -> 깔끔한 글 작성 가능   2. 캡슐화와 정보은닉 ..내가 생각할 때 글쓰기에 적용은 쉽지 않음..   3. 상속과 폴리모피즘 ..내가 생각할 때 글쓰기에 적용은 쉽지 않음..

 

- 위의 두가지 요소를 발전시킨 3가지 요소

ORR (One Responsibility Rule) 글의 단락은 한가지 종류의 주제/목표만을 다음과 같이 수행해야만 한다. 1. 그 주제에 해당하는 내용과 주장을 빠짐없이 모두 해야 한다. 2. 그 주제의 논증을 다른 단락보다 더 잘 할 수 있어야 한다. 3. 그 주제/목표를 자신만이 유일하게 한다.   OCP (Open Closed Principle) ..내가 생각할 때 글쓰기에 적용은 쉽지 않음..   LoD (Law of Demeter) ..내가 생각할 때 글쓰기에 적용은 쉽지 않음..

 

- 그렇다면 결론은

 

1. ORR (One Responsibility Rule)

글의 단락은 한가지 종류의 주제/목표만을 다음과 같이 수행해야만 한다.

a. 그 주제에 해당하는 내용과 주장을 빠짐없이 모두 기술해야 한다.

b. 그 주제의 논증을 다른 단락/문단 보다 더 잘 할 수 있어야 한다.

c. 그 주제/목표를 자신만이 유일하게 한다.

 

이것 하나로 정리하여 글쓰기에 적용할 수 있다.

 

2. 그런데 추가 할만한 객체지향 프로그래밍 요소가 하나 더 있다.

 

"구현이 아닌 인터페이스에 맞춰서 프로그래밍 하라"

 

라는 객체지향 개발 조언이 있다.

 

인터페이스가 객체지향 개발 관점에서 여러 의미가 있지만 글쓰기에 적용할만한, 내가 생각하는 인터페이스는 기능의 내부 구현 로직을 어떻게 머리 써서 짜볼 것인가를 고민하는게 아니라, 전체적인 관점에서 어떤 기능들이 있어야 되고 그 기능들은 어떻게 그룹 지어지고 연결되는지를 고민하는 것이라고 이해했다.

 

한마디로 나무가 아니고 숲을 봐라이다. 이 조언을 글쓰기에 적용하면

 

"내용이 아닌 주제에 맞춰서 글을 써라"

 

라고 정리할 수 있다. 내가 지금 쓰고자 하는 글을 통해 전달하고자 하는 주제/목표, 각 단락, 문단별로 전달하고자 하는 주제 및 얻고자 하는 목표에 우선 신경을 써야 된다는 조언이다.

 

+ 객체지향 고급 기술을 글쓰기에 적용해 보자.

 

1. TDD(Test Driven Development) 테스트 주도 개발

-> 글쓰기로 바꾸면 '주제 주도 글쓰기'

 

보통 프로그램을 짤 때 내 마음대로 코드를 만들고 그 다음에 대충 테스트 하는 방식이 일반적인데, TDD는 테스트 코드를 먼저 만들고 이 테스트 코드를 통과하는 실제 코드를 나중에 만드는 개념으로 이 개발 방식을 추구하면,

 

'구현이 아닌 인터페이스를 지향하는 개발'이 가능한 효과가 있다.

 

이 방식을 글쓰기에 도입하면 그냥 생각나는대로 글쓰는게 아니라 각 단락, 문단별 '주제'를우 선 생각하고 내용을 쓴 다음 그 내용이 내가 원하는 '주제'와 일치하는지 확인하는 새로운 개념이 될 것이다.

 

2. 리팩토링(Refactoring)

리팩토링이란, 기능은 그대로인 상태에서 내부 소스만 유지보수와 확장성 높은 질높은 코드로 개선하는 작업인데 이 기술을 글쓰기에 대입하면 한마디로,

 

'고쳐쓰기' 가 될 것이다.

 

글을 잘쓰는 방법으로 지속적인 '고쳐쓰기'를 얘기하고 있다. 객체도 중복, 뚱뚱, 홀쭉한 놈들이 있듯이 글에도 중복되고, 지나치게 수식어 갔다 쓰거나, 지나치게 빈약한 단락이 있다. 저런 단락을 다듬기 위해 리팩토링 식으로 '고쳐쓰기'를 한다면 더욱 매끄러운 글쓰기가 될 것이다.

 

3. 디자인 패턴(Design Pattern)

내가 생각하는 디자인 패턴은 정형화된 객체지향적 문제 해결 기법이라 이해하면 될 것 같다. 글쓰기에도 독자들의 호응을 불러일으키는 정형화된 패턴이 있다.

 

 

글쓰기는 인문계이고 프로그래밍은 이공계지만 둘 다 문제 해결을 하고, 무에서 유를 창조하고, 논리 적이어야 하고, 각 세부 구성요소들이 서로 비슷함을 많이 느낀다. 주제는 중복되지 않고 하나의 구성요소에만 담겨야 하며, 내용보다 주제에 집중하는 객체지향 글쓰기,

 

객체지향 글쓰기는 다시 말해 '주제지향 글쓰기' 와 같다.

 

 

 

덧 ) 이 객체지향의 탄생 원고는 제가 책으로 내려다가 일단 잘 안되었는데요. 이유는 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다.등 입니다. 그래도 원고를 일단 블로그에 몽땅 풀어보고 언젠가 제대로 교정해서 다시 도전할 생각입니다. 이점을 감안해서 읽고 객체지향을 이해하는데 도움이 되셨으면 좋겠습니다. 의견도 주셨으면 좋겠습니다. 원고 조금만 교정하면 괜찮을것 같은 출판사 관계자분의 피드백도 환영합니다. 특별한 일 없으면 매주 월수 발행 예정입니다.

덧) 이 블로그의 과거 포스팅에 이 포스팅과 중복되는 건이 있습니다.