number = Math.abs(number) // Java code
number = number.abs // Ruby code
number = number.abs // Ruby code
strlen(name) // C
name.length // Java, Ruby code
name.length // Java, Ruby code
"이런 부분이 Ruby가 진정한 OOP언어라고 말할수 있다."
- Programming Ruby,Dave Thomas
랭귀지를 떠나서, OO적인 프로그래밍을 하려면 기본적으로 어떻게 코딩해야 하는가를 보여주는 예제로 볼수도 있다.
OO랭귀지를 아직도 procedural스타일로 코드를 짜는 사람이 많은데, 좀더 생각을 해보자. 복잡한 문제 해결을 위해서 어떤 방법이 정말 유지보수를 편하게 할수 있는지.
기본적으로 중복코드가 적고, 데이터가 적게 움직이면, 그 만큼 유지보수 비용이 절감할 수밖에 없다. 약간의 학습곡선이 필요한 부분(디자인 설계와 같은 부분)도 존재하겠지만, 학습곡선을 통해서 좀더 편해질수 있는 것은 불변의 진리다.
학습곡선이 싫다고, 구구단을 외우지 않고, 계속 더하기만 할것인가? 게으름때문에 학습을 피하는 것은 잘못된 생각이다. 학습을 통해서 게을러지자.
왜 객체지향인가?에 대한 질문과 대답들은 너무도 많은 책들과 페이퍼에 나와서 여기서는 생략한다. 그마져도 중복일수 있으므로....
원칙이라는 것은 대부분 많은 경험에서 나오는 관습과 같은 것이므로 스페셜한 케이스가 아니라면, 가능한 지켜주자.
난 요즘 SRP(Single Responsiblity Principle), LSP(Liskov Substitution Principle) 등등의 객체지향원칙을 당연한 이야기지만, 더 지키려고 노력한다.
그리고, 우리가 정말 테스트하기 쉬운 코드를 작성하고 있는지 다시 한번 생각을 해보자. 대부분의 경우 테스트가 어려우면 디자인이나 dependency관계에 문제가 있고 객체지향원칙들이 깨지고 있는 것이다.
OOP만큼 중요한 것은 OO-System이다. 가령, 단순하게 procedural한 수정(인터페이스 변경이 아닌 내부 로직이나 알고리즘 변경같은것)을 했는데, 부적절한 관계로 다른 시스템에서 영향을 받는다면, 진정한 OO-System이 아닐것이다.
