자바로 프로그램을 짜고 짜고 또짜고 계속짜다보니
3467
points
points
무언가를 깨달은 것이 있습니다.
그게 뭐냐면 학교에서 매일 듣던 OOP 이죠.
저는 단지 OOP 는 책에 써있는데로 클래스를 사용한다고 막연히 생각하고 있었고
조금이라도 이해한다고 생각했는데
오늘도 계속 자바로 삽질을 하던중 깨달아 지더군요.
!_! 그리고 지금까지 이해가 안되었던 다른사람들이 써놓은 API 들과
소스코드들을 읽는데 거침이 없어 졌습니다.
제가 느린걸까요...ㅋㅋ 이제야 Class must be reusable 의 의미를 알게됬다는....ㅠㅠ 흑흑
points
빠르신데요..
저는 8년만에...
그것도 책보고 깨달았습니다.
지금까지 OOP해왔다고 생각한게
알고보니 전혀 OOP가 아니었다는걸..
points
으흠 빠른건가요....
저는 5 년걸렸으니 빠른건가요? 으흠... 저는 아직도 완벽하게 객체지향을 이해한것 같지는 않은듯합니다.
아직 초보단계임...ㅠㅠ
points
그런가요...;
C로만 코딩하다가 어느 순간 갑자기 C++ 로 코딩해볼까 하는 마음이 들어서 레퍼런스 참고해가면서 템플릿 써가며 "오, 이거 괜찮네" 라고 느낀 저는 갈길이 아직 한참 먼거군요;;;
--
from bzImage
It's blue paper
points
Design Patterns
OOP라면 그냥 막연한 개념들만 알고 있다가, python을 공부하기 시작하면서
객체지향 공부를 제대로 해봐야겠다는 생각이 들더군요.
요즘은 Design Patterns라는 책을 보고 있습니다.
"아, 이래서 객체지향이 많이 쓰이는구나" , "난 아직 멀었구나"
라는 생각이 절로 드는데...
저는 왜 java/CPP은 정이 안갈까요. 웬만하면 python으로 다 해보고싶다는...
points
그런데 막상
그런데 막상 python으로 DP를 구현해 보면, 이건 또 다른 세계죠...
--
콘쏠의힘
points
추상화 추상화 추상화...
Reusability of code의 다음 단계가 기다리고 있습니다. ^^
다음 단계는 코드의 단계를 넘어가는 겁니다.
좀 과장하면 객체들이 생물체처럼 보이기 시작하는 단계가 오실겁니다 ㅎㅎ;;
소프트웨어의 발전 방향은 "추상화"라고 요약될 듯 싶습니다.
하드웨어, 소프트웨어의 실제 내부는 숨기고
그 내용을 사영하는 모습으로 모델링함으로써
보다 인간의 생각에 가깝게.. 가깝게... 가깝게 점근해 가는 겁니다. (추상화 되어 가는 겁니다)
꿈 속에서 풀 뜯어 먹는 소리처럼 들릴지도 모르겠습니다만 끄적여 봤습니다. ^^
points
음.. 뭐 학부에서
음.. 뭐 학부에서 동아리 활동하면서 까지 포함하긴 하지만 C 3년 C++ 1~2년
대학원에서 날림으로 C랑 병행해서 Java 프로그램 죽어라 짜다보니까
이제야 클래스와 인스턴스와 ... 엄하게도 포인터가 대충 보입니다.
갈길이 머네요 ... ㅜ.ㅜ
아직 저에게는 Class may be reusable 일 뿐입니다..
가끔 재사용 해주긴 하지만... 다시 쓰는거보단 다시 짜는게 아직은 맘편해서...
자바 한 3년째 날코딩하다가 1년 자바 안만졌는데 갑자기 이벤트 리스너가 뭔지 알듯말듯 하네요..
예전에 막연히 그렇지 않을까 개념만 가지고있다가 이젠 구현할수 있겠더군요...
작년까지는 이벤트 리스너가 뭔지 이해못했는데 한 1년 자바 코드 안보다가 만지는데 인터페이스와 이벤트 리스너간의 상관관계가 문득 떠오르더군요...
디자인 패턴 등은 ... 내년쯤에나 도전해봐야겠네요 으으..
멀고도 먼 OOP입니다....
points
군대갔다 온 후 느꼈던 느낌?...
하여간 눈앞에서 내려놓고 잊을만큰 있다가 다시 하게 되면 되는 경우가 종종 있죠.
미세한 부분은 실수가 다시 나오지만(예를 들어 semicolon 빼먹는 거라던가...)
전체적인 안목은 성장하는 경우가 많은 것 같습니다.
어쩌면 성장한 것이 아니라 불필요할 정도로 특정한 것에 매몰되어 있던 것을
빠져나온 것일지 모르지만 말이죠.
points
OOP가 만능은 아닐
OOP가 만능은 아닐 것입니다.
한 10년 넘게 OOP, Design Pattern 해보니 모든 것을 부지불식간에 쓰게 되었습니다. 순수 OOP 보다는 그때 그때 문제에 따라 적절한 방식의 프로그래밍 패러다임을 사용합니다. 스몰토크를 예로 들자면, 처음에는 참 그럴 듯 했는데, 갈수록 싫어지더군요. 다양한 패러다임을 활용할 줄 알게 되면 OOP는 단지 그중 하나에 불과하게 됩니다.
points
OOP의 한계중 하나가...
로깅 기능같은 광범위한 기능들이 문제가 되죠.
따라서 AOP 같은 것들도 나오고 말이죠...
points
-_-..
글세요 OOP는 아주 일부분이고 실제 코딩해보면 ..
루프.. 비교 검색.. 대입.. 펑션 Or Method 정도가 97%고
OOP는 패턴이나 프레임워크에 녹아 있는게 아니면.. 구지
신경쓰질 않게 되던데요..
솔직히.. 개인적으론 패턴이나 방법론이나 하는것들 보다도..
결국 코딩은 개발자 실력에 달렸다는건.. 마이크로 소프트도 아는 사실이잖아요..
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================