여러분의 고견을 청합니다.
루트랑 대화하면서 느낀건데, 객체지향이 주는 장점이 무얼까?
codesaf..(codesafer)
2016-10-20 17:28
추천 4
댓글 59
다른 게시글
-
야 니들 상대방 페이스북 아이디 알아내는법익명(58.236) | 16.10.20추천 0
-
codesafer님은 vim사용하시나요? [3]익명(110.70) | 16.10.20추천 0
-
페이지 소스보고 있는데 [4]익명(58.236) | 16.10.20추천 0
-
대학생 짧은시간 학점 잘따는 꼼수 (특히 자연대, 공대몇몇과목이 잘통함) [20]내가생각하..(14.43) | 16.10.20추천 13
-
반고닉ㅇㅇ 가 또 유동갖고 장난치고 있군.codesafer(codesafer) | 16.10.20추천 0
-
노트북에 home키랑 end키가 없는데 단축키 이동 뭐로 하냐? [3]익명(210.179) | 16.10.20추천 0
-
루트야 [15]codesafer(codesafer) | 16.10.20추천 0
-
나 혼자 짤수 있는 프로그램/라이브러리라도 남들하고 같이 하는게 [2]루-트(223.62) | 16.10.20추천 0
-
한 기능을 한 줄만 써서 바꾸는게 아니라... [3]codesafer(codesafer) | 16.10.20추천 2
-
숭사리 새끼가 명문대흉내네네 ㅋㅋㅋㅋㅋ 개념글 주작이나 하고 그나이쳐먹고주어없음(27.117) | 16.10.20추천 4
안 그런게 있을까요? 좀 더 구체적인...
네임컨벤션이 좀 여유있다는거?
스코프를 보고 계시군요.
제가 느낀 점은.. 재사용 뭐 이런건 이점이 없는 것 같구요. 여러 사람이 협업할 때, 좀더 이해하기 쉽고 가져다 쓰기 좋은 것 같아요.
프개리님의 표현도 좀 더 구체화해주셨으면...
재사용의 이점이 없다는 말씀은 오타가 아니시지요?
아둔님은 공개 범위및 권한 관리를 특징지어주셨군요.
사실, 절차지향적인 C 로 작성해도 static 이냐 아니냐로 약간의 권한 관리는 됩니다. static 으로 선언하면 다른 모듈에서 사용할 수 없거든요.
여태까지.. 뭔가 재사용에 대해서 이점을 못느꼇어요. 책이나 누군가가 맨날 말하지만요.. 참고로, 제가 말한 재사용은 A프로젝트를 위해 만든 내용들을 다시 A프로젝트를 확장시킨 A'프로젝트에 다시 쓸 수 있다는 의미에서의 재사용이에요.
만약 이게 시험이라면 재사용이 이점입니다... 라고 쓰겠지만, 걍 제 경험상으로는 별로 느끼지 못했슴당
제가 느끼는 점도 여러분의 의견과 대동소이한데, 멤버 ( 상수, 변수, 메서드 ) 를 타입 하나로 묶어주는건 모듈화와 크게 차이는 없어보이지만, 타입이란 말 자체가, 덩어리 단위로 운용해주는 장점외에도 동시에 다시 타입의 크기로 줄여주는 의미를 갖는 것 같습니다.
씨알메리님의 지적은, 일반화가 덜 진행된 클래스가 갖는 문제점을 지적해주신것 같습니다.
전 솔직히 아직도 메서드가 왜필요한건지 모르겠음
객체지향의 핵심이 재사용가능한 코드인데 문제는 객체지향없어도 재사용이 가능...
그래서 함수형이 인기지
그러니까, 예를 들자면,
절차적 프로그래밍으로 구현한 소스코드는, 상세 지도죠.
그걸 줌 아웃 해서 항공 사진 정도의 스케일로 멀리서 바라보면, 글자가 하나도 안보일 지경이예요.
객체지향의 장점은, 재사용, 안정성, 확장성, 개발속도 ( 모든것은 협업하고 있는 상황임을 전제로 합니다 ) 입니다.
타입에 대한 연산만 있으면 되걸 그걸 굳이 접근제한걸고 메서드로 쓰는게 맘에안듦
도시와 도시를 잇는 식의 간략화된 지도를 제공하려면 일일이 다시 상세 스케일에서 작업을 해야합니다.
혼자서 뭔가 만들때는 절차지향이던 객체지향이던 큰 차이를 못느낍니다. 오히려 절차지향이 더 퍼포먼스를 잘뽑고, 코드에대한 효율이 올라갈때가 많은 것 같아요.
거 공부할때마다 책에써있는말로는 사이드이펙트갖고 시뮬레이션 할때 와따라는데 솔직히 그거말곤 모르겠음
우리가 수학에서 복잡한 수식을 대수 T 같은걸로 정의할 수 있잖아요? 그리고 똑같은 수학적 노테이션을 활용할 수 있죠. 그게 우리가 가지는 일반논리거든요.
근데 클래스가 아닌 모듈 단위에선 그 순간부터 확연히 효율이 떨어진다는거죠.
대규모 프로젝트를 할 때, 또는 협업할 때, 절차지향보다 객체지향이 더 편리하고 객체지향의 특성을 잘 발휘할 수 있는 것 같습니다.
대수로 표현할수있는거면 상황이 나은거고 대수로 안될때 객체지향쓰면 차라리 속편하던데
접근 제한은, 본인이 다 알고 안전하게 짤때는 불편해보일 수 있어요.
마치 혼자사는데 화장실 문 잠그고 다니는 느낌이랄까.
그런데 같이 쓰는 화장실이 막히기 직전이라 남들이 건들면 안되는데, 열어놓고다니면 꼭 넘치는 사태가 벌어지겠죠.
리습같은걸로 대수구조 옮기는건 별로 안어려운데 상태를 갖는건 골때리고 그거하는데 그나마 나은게 객체지향이고
물론, 통합개발환경상에서 멤버를 열어봤을 때 불필요한 내부 처리 메서드들을 눈으로 스킵하는 비효율도 줄여주지만요.
많은 과학자들은 아직도 포트란 이나 C 아니면 하스켈같은걸로 지들끼리 라이브러리 잘만 만들어서 몇번이고 재활용하고 개선해 써먹는데 ㅋㅋㅋㅋㅋㅋ 객체지향 필요없음 땔깜들이나 쓰는거지
한마디로 접근제한은 폴더 개념이죠. 보지 않아도 되는건 접어둘 수 있는.
전 은폐까진 좋은데 그게 굳이 메서드의 모양으로 호출되는게 항상 맘에 안들었음 프랜드같이 접근뚫은 함수가 더 좋고
그건 많은 과학자들이 다양한 성격의 구조들을 활용하진 않기 때문입니다.
아, 그건 말이죠.
대수적옮기기 불편한거에만 메서드쓰고 다른건 다 함슬람으로 해결하는게 좋다고 생각해왔으요
clear_image, clear_buffer 가 함수들이고 포인터를 받는다 칩시다.
역할과 이름이 비슷하면서 대상이 다른 함수들이 무지 많을수 있겠죠?
Cpp에서 컴파일타임때 논리를 함슬람으로 해결하고 나머지는 런타임에 넘기고 이런건 아름답다생각함
그러면 꼭 실수하는 사람들이 생깁니다. 그리고 항상 함수와 데이타를 기억하고 다녀야해요.
저런 메서드들을. image.clear buffer.clear 처럼 다루게 되는건, 자연스레 실수의 여지도 줄고, 지금 당장 다루는 객체 이름만 치면 걔가 지원하는 인벤토리가 열리는 식이라 직관적이죠.
속된 말로, "나는 밥" 이라는 표현이 편한 표현이잖아요? 하지만 문맥 없이는 알 수 없죠. 이게 식당의 주문인지, 내가 애들 앞에서 맨날 까인다는건지 말이죠.
추상화가 너무 편해서 - return 0;
쓰다보니 뜬구름잡는소리가 됐는데 clear같은건 대수구조로 옮기기가 골때리고 이런건 걍 객체지향으로(메서드) 손보는게 맞다봄
즉, 객체나 객체의 인스턴스의 이름을 앞에 세우고, 메서드를 이야기 하면 사실상 컨텍스트를 깔고 표현하는게 되는거죠.
지금 스마트폰 마냥 각 데이터를 관리하는 함수들을 미리 만들어둔다는게 이용하기는 편하죠 - return 0;
주어, 동사 나 목적어.동사 구조가 자연히 형성될수 있구요
제가 말하는건 함수나 메서드라기보다 기본연산자처럼 오버로딩해도 항상 의미가 유지되는 그런거
컨텍스트를 갖는다는 말이 좋은듯 컨텍스트에 의존이 적을수록 메서드에서 멀어질수있고
ㅇㅇ STL 을 보면 2016052 님이 원하는 그런형태에 가깝게 구현되어 있다고 생각해요.
좀 구구절절할 뿐이지만, 핵심 논리는 같죠. 알고리즘 즉 연산자를 만들어 놓으면 기본 골격이 동일한 여러 컨테이너나 데이타 타입에 고스란히 적용할수 있으니까요.
이 글의 제 요점을 다시 정리하면 그거예요. 객체화는, 그 덩어리를 다시 타입이란 이름으로 작게 만들어준다.
그 말은, 연관된 오퍼랜드와 오퍼레이터의 조합이 다시 오퍼랜드가 되었으므로, 재귀적으로 문제를 풀 수 있게끔 일반화 되었다. 라는 거죠.
저녁 맛있게 드세요~
상속을 통한 재사용으로 개발을 빠르게 하려는 목적으로 객체지향언어가 나온거임 . 상속이 없으면 객체가 필요 한 이유가 없음. 객체는 C 구조체 + 포인터로도 만들 수 있음. 멤버를 은닉하는 이유는 ㅇㅇ 멤버가 다른 객체에서 사용되어서 꼬임을 방지하기위한ㅇㅇ 그러니까 재사용을 위한 독립성을 높이는거 말고는 없음ㅋ
모든것을 상속 받자~ 하는 그 모라해야하지 흑수저 노가다꾼들이 남이 만들어 놓은 객체를 갖뎌다 쓸려고 맹든거 ㅋ
ㄴ 아니야... 앨런 케이가 객체지향 왜 만들었는지 모르네 - return 0;