객체 지향 기법에 대한, 그럴 것이라고 알려진 혹은 지레짐작하는 오해들
- 그 자체로 좋은 성능을 내는 소프트웨어를 만들 수 있는 기술이 아니다.
좋은 성능을 내는 소프트웨어 만들고자 하면, 알고리즘과 자료구조 이론을 공부하라. - 더 나은 알고리즘(적은 메모리와 CPU 사용)을 위한 기초도 아니다.
좋은 알고리즘을 작성하는 능력은 논리적 사고와 수학적 문제해결 능력에서 비롯된다. - 좀 더 짧은 코드를 작성할 수 있는 기술 조차 아니다.
더 짧은 코드를 작성하는 것은 남들이 작성한 좋은 코드를 많이 읽어 보고,다양한 유형의 코드를 직접 작성하며 수련해야 한다. - 버그를 줄여주는 혹은 버그 발생 확률을 줄여지는 않는가?
인간은 완벽하지 않다. 다만, 신중한 태도와 지루한 반복 테스트 혹은 다양한 테스트 케이스 작성을 미루지 않는 정신 지구력을 통해 버그를 줄일 수 있다. - 복잡한 문제를 쉽게 풀 수 있는 마법은 더욱 더 아니다.
복잡한 문제를 코드로 잘 풀어내는 능력은 천재적인 능력에서 비롯되는 것보다 많은 코드를 읽어 보고, 다양한 문제를 더 많이 풀어보고, 새로운 해법을 끊임없이 고민하는 노력을 통해 얻어진다. - 더 깊은 수준의 지식을 자랑할 수 있는 난이도 높은 기술도 아니다.
객체지향 기술은 더 이상 소수의 전문가가 숨기고 있는 보물이나, 감추어진 비밀이 아니다. 누구나 인터넷과 서적을 통해 익힐 수 있다. 수많은 가이드와 예제가 나와 있다. - 머리가 좋아지는 사고력 훈련 코드 혹은 두뇌 비타민?
말도 안된다.객체지향을 사용하지 않는 프로그램과 더 복잡한 프로그램도 많고, 어떤 객체지향 전문가도 객체지향이 최상의 프로그래밍 기법이라고 말하지 않는다.
객체 지향의 진실
- 객체지향은 코드를 보다, 단순하고, 이해하기 쉽고, 추가/변경/조합하기 쉽도록 만들기 위한 것이다.
(그런데, 정작 객체지향을 배운 사람이 더 복잡하게 설계하는 일도 많다. 그래서 오해가 늘었다.) - 높은 성능(CPU와 메모리를 적게 사용하는 것)의 소프트웨어는 객체지향 설계의 관심사가 아니다.
성능이 무엇보다 중요하다면, 비객체지향 언어를 배우거나 찾아보라. - 객체지향은 가장 거대한 형태의 소프트웨어를 가장 단순한 코드들의 집합으로 구현하며,각각의 코드 블록(클래스 혹은 인터페이스 그리고 메소드 등)의 형태는 가장 단순한 형태로 유지하려는 노력이다.
이를 통해, 복잡함이 통제할 수 없는 수준으로 증가하는 것을 방지하고, 문제가 발생하더라고 원인을 알기 쉬우며, 많은 사람들이 협력하는 프로젝트 내에서 조차 다수가 상호협력하면서 또한 독립적인 개발이 가능하게 만든다는 얼핏 이율배반적인 목표를 이추구하는 것이다. - 객체지향의 목표는 기계지향(기계에 친숙한) 코드가 아니라, 인간 지향(사람의 사고 흐름에 가까운)의 코드를 작성하는 것이다.
그런데, 여기서 함정은 객체지향이 서양 철학과 언어 체계에 근접해 있다는 것이다. 그러니, 조금 버겁더라도 가급적 코드(혹은 주석)를 영어 문장으로 읽어보는 시도를 해 볼 필요가 있다. - 객체지향은 절차 지향의 함정에서 벗어나기 위한 노력이다. 절차 지향으로 코드(혹은 논리)의 흐름을 이해하고, 작성하는 습관은 자연스러울 수 있다. (flow-chart 는 절차지향의 설명하는 가장 직관적인 사례다.)
절차지향의 문제를 깨닫지 못하는 한, 당신은 제대로 객체지향을 받아들이기 어려울 것이다. - 객체지향은 수많은 사례에서 연구, 발견 그리고 제안된 우수한 소프트웨어 설계 기법들을 설계자 뿐만 아니라 코드를 만들어 내는 개발자들이 직접 타이핑하는 순간에 쓸 수 있게끔 하려는 노력이다. 따라서, 객체지향 언어 문법과 코드와 패턴은 성능과는 아무런 상관이 없는 관용어(idiom)로 가득차 있다.
Effective Java 1 and 2.ppt
Welcome to object world.doc