(부치의 OOP책에서 OOP 컨셉)

하스켈,LISP 하는데 객체지향 하겠다는 것도 말도 안되고

다중 패러다임 언어라고하지만, 사실상 객체지향에 가까운 자바하는데 굳이 OOP 아예 안하겠다도 또 솔직히 굳이 싶고.

또 굳이 객체지향 없이 절차지향에 가까운 임베디드에서 객체지향 코드 짜면 말도 안되고(다만 말이 완전히 말이 안되는건 아님. 요즘은 OOP도 들어가고 있다는 기사들이 있으니)

OOP는 애초부터 자바를 위시한 코드로 나온건 둘째치고 

C++도 STL이 기본적으로 OOP 존나 깠지만 STL에 함수에 OOP 편입됐듯이

꼭 지향에 매몰될 필요가 없음

지향을 알아야하지만 매몰될 필요가 전혀없는 것

지향은 단순하게 말해서, 코드가 커질수록 일관성을 어떻게 유지시키는가에 대한 일종의 추상화 방식의 일종임.

단순한 코드에 지향을 무조건 도입할 이유가 없어.

하지만 지향을 도입하면 나중에 생산성에서 도움이 되는 측면도 있긴함.

유튜브 애들이 애초에 이런 내용들을 다 어깨너머로 보고 블로그로 정리한 것만 보니까 역사적 맥락에서 어떻게 생겼고 어떻게 주창됐는지를 모르니까.

무조건 XX해야한다 이딴식으로 설명하는거임. 원론적으로 Object-Oriented Analysis and Design with Applications의 서문에서 OOP가 어떻게 탄생했는지 봐라.

저기 적힌 컨셉 그 자체가 내가 하는 말 그 자체임.

문제는 이걸 한국에서 번역하고 또 책팔아먹으면서 잘라내고 간추리면서 왜곡되는 내용도 있고.

대부분 책 내용들을 안 읽고 블로그 자료등으로 공부하니까 이런 문제가 생기면서 그런 왜곡되고 잘라진 개념들이 시뮬라크르가 시뮬라시옹이 되버리는거임.

즉 책 전체 내용을 가지고 가져와서 이야기해보면서 맥락에 맞는 이야기를 해야하는데, 책에서 일부를 가져와서 재조합해서 새 개념이 되버리는거지

저 내용을 쉽게 말하면 노가다에서 노가다 십장들이 이유 설명 못하고 그래야만한다는 식으로 유튭 강의나 부캠에서 팔아먹는다라고 이해하면된다.

즉 설명하다가 잘못된 개념들이 새로운 실재가 되버리는거임.

애초에 전공서적 내용을 다 간추리고 현장위주로 가르치는게 국비-부캠- 유튜버들이니까.

그리고 애초에 추상화라는 걸 어떻게 하느냐는 정량적으로 측정할 수가 없기때문에 말이 갈리는데 한국은 여기에 시험 제도까지 넣어지면서 원래라면 무조건 맞다고 할 수 없는 방법론도 시험이라는 제도를 통해서 정량화 시키기때문에 왜곡이 되는거.

시험이라는게 그런거잖아 결국 정답이 있어야하는데, 보통 이런 지향이나 문제든 정답이 존재할수가 없는 문제임.

지향이 필요 없다하는 애들도 어느정도 일리가 있지만 보통 대체로 커질수록 어떻게 코드의 일관성을 유지시키는가에 대한 가이드 라인이 지향인거임.

근데 굳이 작은 코드에서 OOP 지키면 복잡성 커지고 굳이 재사용도 안하는데 생산성이 떨어지게 꼭 지향을 지향할 필요가 없는데

기본적으로 OOP건 다른 지향이건 소프트웨어 사업이 다각화되고 복잡해짐에 따라서 만들어진 개념이고 

애초에 결국 필요성은 개인의 프로젝트 상황 프로젝트 크기등에 따라 가변적인거라서 

무조건은 없음.

근데 보통 팀단위에서 어떤 지향에 대해서 사용할 것을 결정하면 결국은 유지 보수때문에 한사람이 짠 것처럼 만들어야하는게 결론적으로 유지보수에 매우 유리하기때문에

그 팀을 따르는게 맞음.

그리고 기본적으로 데드라인에 맞춰야하는데, 언제 또 코드 가이드 라인을 다 맞추겠냐. 

결국 상황적 맥락, 그리고 프로그래밍 자체가 가지는 가변성에 따라서 상황에 따라 맞추는게 프로그래머인거

실용주의 프로그래머라는 명저중에 명저를 봐라.