객...객체지향??
프로그래밍???
뿌잉뿌잉
개념적으로는
철차 지향은 프로그램의 흐름에 중점을 두고
객체 지향은 data의 논리적 집합을 만들어 그 집합을 중심적으로 생각한것 정도 아닐까요..
레고 맞출때
하나씩 하나씩 블록 조립하는게 절차지향
부분부분 맞춰놓고 나중에 합체! 하는게 객체지향.
전문적인 설명은 기본 개념만 잡고 있으면 어느정도 이해되지 않나엽.
저런 형태를 이해하겠는데.....
용어와 함께 말하니 햇갈림.....
객체가 그러니까 무었이냐...
그리고 클래스랑 메쏘드는 또 뭐시여;;;
백문이 불여일견 백견이 불여일행이라고.. 어차피 설명만 보고 전부 알 수 없습니다.
흔한 예제라도 따라서 짜보시는걸 추천합니다.
프로세스 위주로 프로그램을 분석/모델링/개발 하면 절차지향
실세계를 반영하여 객체간의 메세징을 위주로 프로그램을 분석/모델링/개발 하면 객체지향
둘다 지향일뿐이라 완벽히 분리되는 개념은 아니며, 그냥 그걸 지향한다 라는 정도로 보시면 무방...
문제의식없이 배우는 모델링기법은 그닥 와 닿지 않으므로, 뭐가 됐던 많이 작성해 보시고, 아... 썅! 뭔가 내 코드에 냄새가 나는데!! 라는 생각이 들기 시작하면
그때가서 객체지향이건, 데이터드리븐이건 뭐건 공부하시고 적용해 보심이 더 피부에 와닿고 살아있는 지식이 될 것임니돠.
객체지향은 글로는 그 진수를 전달하기 어렵고 프로그래밍 경험을 통해 절차적 프로그램밍의 불쾌감과의 차이를 느낄수 있어야 합니다.^^;
오랫 동안 프로그래밍한 프로그래머가 객체지향의 효용을 느낄 수 없다면 "객체지향 불감증"에 걸린 것입니다.
프로그래밍을 하고 싶은 사람이 뭔가 부족한 듯 느끼는 증상이 있으면 프로그래머 병원에 가서 컴퓨터 의사(프로그래머)에게 치료 받아야 합니다.^^`;
모든 컴퓨터 의사(프로그래머)가 다양한 분야의 달인은 아닙니다. 예를 들자면 어셈블리어 같은 경우 실제 달인은 꽤 드믑니다.
그래서 프로그래밍 명의(명인)은 따로 있습니다.
약은 약사에게 진료는 의사에게 IT컨설팅은 프로그래머에게~
절차지향이
main {
코드 블라블라블라
여기서 계산하고 치고박고 블라블라
하나 바뀌면 이리저리 영향을 줌
}
라면
객체지향은
main {
최소의 일만.
구체적인 일들은 a,b,c에서.
call a
call b
call c
}
a{
행동1
}
b{
행동2
}
c{
행동3
}
같은거라고 이해하시면 될듯?