저와 비슷한 생각을 하신 분들이 꽤 많으신가 봅니다. 반갑네요. ^^;;; 이런 생각이 객관적 사실인지 확인할 길은 없겠지만 이런 해석을 해보는 것도 나쁠 것은 없다고 생각합니다. 아, 그리고....저 '권위' 없습니다. ^^;;;;; 그냥 나이만 조금 더 먹었을 뿐입니다. 아직도 C++문법이 헷갈리는 흔한 개발자입니다. ^^;;;;
철학적 접근은 굉장히 중요하다고 생각합니다. 왜? 필요한지... 존재이유가 무엇인지에 대한.. 정답이 존재하지 않지만 생각하면서 생각의 폭이 넓어지게 되는것 같습니다. 인간은 유전자의 자가복제를위한 생존 기계에 지나지 않는다는말이 생각나네요~! 결국 사람들이 많이 사용하는 잘설계된 객체(class)들은 아직까지도 상속받아서 계속 그형태를 유지하고 발전해나가고 현재까지 많이 진화하고 업그레이드 되는것 같습니다..
플라톤과 아리스토텔레스...둘 중 하나 고르라면 저는 아리스토텔레스 입니다. 비록 자연적 관찰로 사람의 마음이 심장에 있다는 오류가 있었습니다만....^^;;;; 그건 중요하지 않고...어쨌든 '객체지향'이라는 개념이 제 입장에서 신기했던 것은 기계에 인간의 사고를 입히는 과정처럼 보였기 때문입니다. 어쩌면 우리도 기계일 수 있다는 생각도 들고...나아가 인간성은 무엇인지 생각하게 되기도 하고...참 어려운 주제이고 재미있는 주제이기도 한 것 같습니다. 의견 감사합니다. ^^
자바로 코딩을 시작해서인지 객체를 항상 현실 세계의 것과 비교해서 (이를테면, 붕어빵과 뿡어빵기계) 그런지 뭔가 와닿는 느낌이 없었는데, 선생님께서 올리신 C로 자료구조 배우는 강의들 듣고 객체 강의를 들으니 객체가 드디아 무엇인지 깨달았습니다.. 아마 객체지향관련된 책에서 자꾸 현실세계와의 비유를 사용하려고 하는 것은 기초적인 cs지식이 없는 독지들을 배려하다보니 그렇게 된게 아닐까 생각도 들고 그게 아니라면 선생님께서 가르치는 일을 넘사벽으로 잘해서라는 생각이드네요. 감동받았습니다 감사합니다
와우~~! 스스로 답을 찾으셨나 보네요. 축하드립니다. :) 이제 본격적으로 OOP 사고를 시작하시면 되겠습니다 노파심에 한 말씀드리면...객체화에 눈뜬 분들이 자주 하는 실수 중 하나가 너무 많은 것을 객체화 한다는 것입니다. 이에 대해 사실 정답은 없습니다. 그리고 그런 실수가 없다면 성장도 없을 것이니...막을 생각도 없습니다. 그러나 꼭 지나친 객체화에 대해 함께 고민함으로써 더 빨리 성장하시기를 바랍니다. 고맙습니다. :)
선생님 덕분에 객체지향을 이해하게 됐습니다.. 대부분의 다른 영상에서는 객체지향에서 파생된 객체지향 프로그래밍만을 설명하더라구요.. 객체지향 프로그래밍을 이해하고 싶었는데 객체지향관점으로 파생된 객체지향 프로그래밍만 얘기하니 너무 답답했는데, 근본적인 객체지향 관점 자체에 대해서 말씀해주시니 속이 뻥 뚫렸습니다 :)
사실 누구도 확인할 수 없는 것입니다. 플라톤과 아리스토텔레스가 객체지향 프로그래밍을 공부했을 가능성도 없고요. 음...그냥 추론입니다. 근거도 저의 주관적 의견에 불과하고요...이것을 제대로 규명하려면 논문도 꽤 나오지 싶습니다. 그저 재미와 OOP공부 보조 수단으로 이해해주시면 좋겠습니다. 감사합니다. ^^
우와 갑자기 '객체지향'이라는 단어가 선생님 영상에서 보여서 깜짝 놀라서 달려왔어욬ㅋㅋ자바개발자가 되고싶은 인문학도인데, 저도 철학에 관심이 많아서 객체지향 배울 때 플라톤이 제일 먼저 떠올랐어요 ㅋㅋ 자바를 점점 깊게 배우다보니까 사알짝 다르긴 한 것 같지만 ㅎㅎㅎ 처음에 이렇게 생각하니까 OOP 너무 쉽게 이해되더라구요 앞으로 객체지향 프로그래밍 강의해주신다고 하니까 너무 좋아요~~ 아 글구 가능하시다면 가끔 웹 이야기도 해주시면 정말 감사할 것 같아요 너무 재밌어서요ㅋㅋ 오늘도 영상 잘봤습니당!!
저는 죄송하지만 약간 다르게 봅니다. 아름다움은 부모 클래스가 가지는 속성 중 하나입니다. 속성의 형식이 "아르다움" 이죠. class 아름다움 { public int 심적; public int 외적; } 이 속성을 보유한 부모로부터 파생된 모든 자식은 아름다움이란 속성을 물려 받습니다. 부모: class 인기인 { public 아름다움(형식) 아름다움(이름); } 자식: class 연예인 : 인기인 class 얼짱 : 인기인 설인아, 김혜수, 김태희는 실존하는 연예인 즉, 연예인의 인스턴스입니다. 이들은 공통적으로 아름답지만, 개별 인스턴스마다 정도의 차이가 있는 것(상태가 다른 것)이죠.
프로그래밍 공부 시작하고나서 추상체와 구현체에 대해 배울때 말씀하신 것처럼 이거 딱 이데아 얘기같네 싶었는데 아주 조금 더 공부하다 보니까 이 생각에서 추상체는 구현체를 다루기 위한 버튼 정도로 생각되더라구요 더더욱 공부하다 보면 또 이게 다시 원래의 이데아로 바뀔까요?? 좋은 강의 감사합니다 ㅎㅎ 지금 딱 UML과 객체지향, 클린코드에서 계속 고통받는 중인데 딱 좋은 타이밍이네요!! 매일 꼭 챙겨보겠습니다!
쓰는 코드만 쓰는 이유는 소위 실무에서 검증됐기 때문이고 1분 1초라도 빨리 퇴근할 수 있는 방법론이기 때문이지 않나 생각합니다. 문제는 그 틀에 갖혀 복붙을 반복하다보면 내가 개발자가 맞는지 회의감이 몰려온다는 것이고 더 큰 문제는 나만 쳐지는 것 같은 불안함이죠. 네, 제 경험입니다. ^^;;;;; 열심히 강의 만들어서 제 경험을 공유해드리겠습니다. 즐프하세요.
객체지향 이야기를 한참 하다보면 내가 IT기술에 대해 말하고 있는 것이 맞는지 헷갈릴 때가 종종 있습니다. 김춘수님의 '꽃' 이야기를 하면 나라는 실체는 그에 대해 '꽃'이라는 추상화된 인터페이스를 제공하는 것인가? 그렇다면 이는 인터페이스 분리 원칙에 따라... 뭐 대충 이런 생각을 하게 됩니다. -_-;;;
문과 출신인 제가 이해하는 객체는 아래와 같습니다. 객체라는 번역어의 원어는 object 입니다. 이 object 는 수학의 집합론에서 나온 개념으로, 정의(definition)의 대상 또는 목적입니다. definition is about an object. object가 집합론에 출현한 이유는 정의를 다루는 수학이 집합론이기 때문입니다. 수학에서는 부인 불가능한 오류가 없는 정의가 필요합니다. "한 마을의 이발사는 자신의 손으로 머리를 깍지 않는 사람이다" => 부인 가능한 정의의 한 예입니다. 이발사는 자신의 머리를 깍을 수도 깍지 않을 수도 있기 때문입니다. 어떻게 하면 부인되지 않는 방식으로 정의를 할 수 있을까에 대한 고민의 결과물 중에 하나는 "부류"로 정의를 하는 것입니다. 부류는 "특징의 집합"으로 표현됩니다. (그래서, 집합론...) 정의를 위한 집합에 속한 각 요소를 그 집합의 멤버라고 합니다. 부류를 영어로 하면 class 가 되죠 (classfy : 분류하다). 특정 부류에 속한 모든 특징을 부류의 유형(type)이라고 합니다. 특정 부류로 정의된 object가 실체화된 것을 instance라고 합니다. 호랑이라는 관념(object)은 호돌이 그림으로, 살아 있는 동물로, 컴퓨터 그래픽으로 실체화될 수 있습니다. 프로그래밍에서는 일정 영역의 메모리 덩어리로 실체화됩니다. 집합론의 정의방법을 차용한 대표적인 것이 생물학적 분류법입니다. 계-문-강-목-과-속-종... 어떤 특징이 있으면 A계, 없으면 B계, A계 중에서 또다른 특징이 있으면 AA 문, 아니면 AB문... 집합론의 정의 방식을 차용한 프로그래밍 기법이 객체 지향 프로그래밍(object oriented programming)입니다. 이 기법에서는 프로그램적으로 존재하는 관념적인 것을 object로 보고, 그것을 부류(class)로 정의하고, 메모리에 인스턴스화시킵니다. 이 기법에서 요구하는 원칙 중, 정의의 구체성에 관한 것이 추상성입니다. 추상성은 합목적성과 계층성으로 나타납니다. 합목적성은 한 object가 가질 수 있는 모든 특징을 클래스에 전부 나열하려 들지 말고, 가급적 다 빼버리고, 꼭 필요한 것들만 멤버로 선택하라는 의미입니다. "다 빼버린다" 요 말이 추상성의 핵심입니다. 사람 class 는 사람 object가 가질 수 있는 모든 특징 중에 이름과 나이만 필요하다면 그 두개만으로 정의해야 합니다. 이렇게 정의되면 모든 사람 instance 는 이름과 나이만 보유합니다. 만약 특정 인스턴스가 전화번호도 가지고 있으면 사람이 아니무니다~~ 계층성은 한 부류에 대한 정의는 수직적 계층 구조로 나눠서 정의한다는 것입니다. 그 부류의 상위 계층에 대한 정의는 작은 집합(멤버의 갯수가 적음)으로, 하위 계층으로 갈수록 상위 집합에 특징을 추가합니다. (멤버 갯수가 많아짐) 동물 부류는 "움직임"이라는 특징만을 담고, 그 하위부류인 포유류는 동물 부류에 "젖을 먹임"이라는 특징을 추가하고, 그 하위부류인 사람은 포유류에 "지능"이라는 특징을 추가하는 식으로.. 하위 계층으로 갈수록 그 부류가 가진 특징의 갯수가 늘어나서 더 구체적인 정의가 되고, 반대로 상위로 갈수록 추상적인 정의가 됩니다. 그리고, 하위 계층의 부류는 여전히 상위 계층의 유형으로 치부할 수 있습니다. 사람이 동물이기도, 포유류이기도 한 것처럼요. 수직적 계층 구조는 곧 특정 부류의 정체성의 범위를 한정하는 역할을 하는데, 이는 자원 (메모리)의 효율적 운영과 연관이 있습니다. "움직임"만 필요한데, "젖먹이고", "지능" 이 있는 인스턴스를 사용하는 것은 낭비이기 때문이죠. 영상에서 설명하신 추상성은 abstract 키워드에 관한 것입니다. 이는 객체의 추상성에 관한 것이 아니라 주로 멤버의 추상성을 나타내기 위한 것입니다. 그 키워드는 어떤 부류에 특정 속성이 있기는 한데, "구체적으로 정의되지 않음"을 나타냅니다. 쉽게 얘기하면 현 계층에서는 그 특징이 무엇인지 확정하기에 곤란하니 후대에서 확정하라는 의미입니다. 반대로, 후대에서 너무 다양하게 구체화되니까 현 계층에서는 딱 꼬집어 말할 수 없다는 의미도 됩니다. 사람은 "놀다"라는 특징이 있는데.. 하위 계층인 직장인은 당구치며 놀고(당구장에 의존), 또 다른 하위 계층인 학생은 게임(피씨방에 의존)하며 놀죠. "놀다"라는 특징은 직장인/학생 계층에서 갑자기 나타나는 특징이 아니라, 사람이 가지는 특징입니다. 다만, 사람 계층에서 그 내용을 구체적으로 확정할 수 없다는 사정이 있을 뿐인 것입니다. abstract 키워드는 그런 멤버에게 사용하는 것인데, 그 이면은 멤버가 구체적으로 정의되지 않아도 컴파일러에게 뭐라하지 말라는 일종의 까방권입니다. 참고로 인터페이스는 수평적인 부류를 나타냅니다. 비행기, 날치, 참새는 동일한 정체성을 공유한다고 볼 수는 없지만 공통적으로 "날 수 있는" 특징을 공유합니다. 인터페이스는 정체성이 아니라,공통적으로 나타나는 특징을 하나의 부류로 정의하는 수단입니다. 날수 있는 유형의 객체들은 모두 날 수 있습니다. 그래서, 그 객체들에게 "날아봐!"라고 명령하면, 비행기는 엔진을 돌리고, 참새는 날개짓을, 날치는 수면위로 점프를 하는 등, 각자 자기만의 방식으로 "날다"를 구체적으로 정의합니다. 이와 같이 인터페이스에 속한 멤버들은 하위 부류에서 너무 다양하게 나타나기에 구체적으로 정의되지 않아야 합니다. 즉, 인터페이스 멤버들은 abstract 키워드가 없어도 기본빵으로 abstract 한 특징이 있습니다. 그래서, 인터페이스 유형은 점멤버가 까방권이 있습니다. 스스로 공부하며, 인터넷을 떠돌다 보니.. C/C++ 기반의 개발자들이 객체를 메모리적인 개념으로만 이해하려는 경향이 강해, 객체 지향 언어의 다양한 개념들을 이해하는데 어려움 또는 오해하고 있는 것을 많이 보고 안타까운 나머지 장문이지만 댓글을 남겨 봅니다. 저는 C -> Java 조금 -> 스몰토크 를 거쳐 현재는 C#에 안착한 한량입죠. ㅠㅠ
좋은 의견 감사합니다. C/C++ 개발자들의 객체를 메모리적 개념으로 이해하는 경향은 구조체의 연장으로 이해하기 때문이 아닐까...추측해봅니다. (딱히, 근거는 없습니다. ^^;;) 앞으로 객체지향 프로그래밍에 대한 제 의견을 계속 올려보겠습니다. 그 때도 의견 부탁드립니다. ^^
@@nullnull_not_eq_null 별 말씀을요.. 영상을 통해 많은 위안을 받고 있습니다. 전공자가 아니다보니.. 하드웨어 저수준에 대한 개념을 매우 긴 시간동안 어깨넘어로.. 파편화된 글들로 익히다 보니, 억지로 끼워 맞춘 연결고리가 많았습니다. 어떤 영상은 저의 추측이 옳았음을 확인시켜주셨고, 어떤 영상은 부족한 연결고리를 채워주셨습니다. 그점 많이 감사하게 생각합니다. 이 댓글에서도 C/C++ 개발자들의 경향성이 구조체에 있다는 말씀으로 저의 오랜 의구심이 해소되는 것 같습니다. 사실, C#에서는 구조체가 이제는 거의 사용하지 않는 계륵과 같은 존재입니다(제 느낌). 그래서 그런 사정을 이해할 리가 없죠. ^^ 저는 필터링할 모델 객체가 많을 때(수백만 개를 넘을 때) 성능 개선을 위해 몇번 써보았는데, 별도움은 못 받았습니다. 최근에는 record 라는 또 다른 형식이 도입되어서 구조체에 달린 인공호흡기마저 떼는 것만 같습니다.
제가 C#하고는 많이 친하지가 않아서...^^;;; 다만 요즘 C/C++이 이젠 시대적 사명을 다한 것 같다는 생각을 하고 있습니다. 심지어 '성능'에서 조차 큰 장점을 찾기 어려워지는 것 같고요. 나중에 다시 C#도 복습할 예정입니다. 그 때, 제가 잘못다루는 내용이 있다면 꼭 알려주시면 좋겠습니다. 감사합니다.
철학 몹시 조아라 합니다. 뚜껍 한게 라면 받침으로도 좋겠고, 목침 대신으로도 딱....쩝... 추상클래스 저누므 시키 공부하다...음 ...난 객체랑 안맞나 했는데... 역시 원인은 저걸 만든 놈들이, 나랑은 다른 삶을 사는것들이 만들다 보니 음...그럴수 있겠네요... 역시...력시... 하하 감사합니다. 😮
저도 학부때 (교육)철학 공부를 해서 그런지 자바의 객체지향 공부할때 플라톤 부터 떠올랐습니다. 그래서 객체지향 개념을 철학적으로 이해해 버렸죠. 권위있으신 분이 똑 같이 생각하고 말씀해 주시니 반가웠습니다 ^_^
저와 비슷한 생각을 하신 분들이 꽤 많으신가 봅니다. 반갑네요. ^^;;;
이런 생각이 객관적 사실인지 확인할 길은 없겠지만 이런 해석을 해보는 것도 나쁠 것은 없다고 생각합니다. 아, 그리고....저 '권위' 없습니다. ^^;;;;; 그냥 나이만 조금 더 먹었을 뿐입니다. 아직도 C++문법이 헷갈리는 흔한 개발자입니다. ^^;;;;
철학적 접근은 굉장히 중요하다고 생각합니다. 왜? 필요한지... 존재이유가 무엇인지에 대한.. 정답이 존재하지 않지만 생각하면서 생각의 폭이 넓어지게 되는것 같습니다.
인간은 유전자의 자가복제를위한 생존 기계에 지나지 않는다는말이 생각나네요~!
결국 사람들이 많이 사용하는 잘설계된 객체(class)들은 아직까지도 상속받아서 계속 그형태를 유지하고 발전해나가고 현재까지 많이 진화하고 업그레이드 되는것 같습니다..
플라톤과 아리스토텔레스...둘 중 하나 고르라면 저는 아리스토텔레스 입니다. 비록 자연적 관찰로 사람의 마음이 심장에 있다는 오류가 있었습니다만....^^;;;;
그건 중요하지 않고...어쨌든 '객체지향'이라는 개념이 제 입장에서 신기했던 것은 기계에 인간의 사고를 입히는 과정처럼 보였기 때문입니다. 어쩌면 우리도 기계일 수 있다는 생각도 들고...나아가 인간성은 무엇인지 생각하게 되기도 하고...참 어려운 주제이고 재미있는 주제이기도 한 것 같습니다. 의견 감사합니다. ^^
재미있는 해석이네요. 재미있는 영상 감사합니다.
피드백 감사합니다. 딱! 재미로 이해해주시면 좋겠습니다. ^^;;
철학도 좋아하고 코딩도 좋아하는 저에게 딱 맞는 강의입니다. 천천히 음미하며 푹 빠져보겠습니다. 좋은 강의 감사합니다. ^^!
저도 철학을 좀 좋아라 합니다. ^^;;;; 좋은 평가와 피드백 감사합니다.
좋은 설명 감사합니다
좋은 평가 고맙습니다. :)
자바로 코딩을 시작해서인지 객체를 항상 현실 세계의 것과 비교해서 (이를테면, 붕어빵과 뿡어빵기계) 그런지 뭔가 와닿는 느낌이 없었는데, 선생님께서 올리신 C로 자료구조 배우는 강의들 듣고 객체 강의를 들으니 객체가 드디아 무엇인지 깨달았습니다..
아마 객체지향관련된 책에서 자꾸 현실세계와의 비유를 사용하려고 하는 것은 기초적인 cs지식이 없는 독지들을 배려하다보니 그렇게 된게 아닐까 생각도 들고 그게 아니라면 선생님께서 가르치는 일을 넘사벽으로 잘해서라는 생각이드네요. 감동받았습니다 감사합니다
와우~~! 스스로 답을 찾으셨나 보네요. 축하드립니다. :)
이제 본격적으로 OOP 사고를 시작하시면 되겠습니다 노파심에 한 말씀드리면...객체화에 눈뜬 분들이 자주 하는 실수 중 하나가 너무 많은 것을 객체화 한다는 것입니다. 이에 대해 사실 정답은 없습니다. 그리고 그런 실수가 없다면 성장도 없을 것이니...막을 생각도 없습니다.
그러나 꼭 지나친 객체화에 대해 함께 고민함으로써 더 빨리 성장하시기를 바랍니다. 고맙습니다. :)
선생님 덕분에 객체지향을 이해하게 됐습니다..
대부분의 다른 영상에서는 객체지향에서 파생된 객체지향 프로그래밍만을 설명하더라구요.. 객체지향 프로그래밍을 이해하고 싶었는데 객체지향관점으로 파생된 객체지향 프로그래밍만 얘기하니 너무 답답했는데, 근본적인 객체지향 관점 자체에 대해서 말씀해주시니 속이 뻥 뚫렸습니다 :)
'이해'라는 결론에 도달하셨니 우선 축하드립니다. 이해도 된 마당에 열공모드로 더 달려서 OOP를 섭렵하시면 될 것 같습니다. :)
아 그래서 클래스 와 객체 인스턴스도 객체라는말이 영상 19:20초 즘 때문인가요?
객체가 추상클래스 인스턴스가 implementaion class 라하셨잖아요
클래스 중에 추상 클래스, 구현 클래스가 있는 것입니다. 참고하시기 바랍니다. :)
오늘도 감사합니다
인문학적 소양까지 갖춘 엔지니어는 멋있네요
좋은 평가 감사합니다. 인문학 + 뇌과학 재미도 있고 프로그래밍 공부에 도움이 된다고 믿고 있습니다. 특히 UI/UX분야는 더 그런 것 같습니다. ^^
객체의 표현은 C의 구조체로도 가능하고 내부적으로도 똑같이 동작하지만 C++는 문법적으로 좀더 쓰기 쉽게(편리하게) 되어 있다?
C로 객체를 표현할 수는 있으나 '상속'관계를 처리하지 못하는 문제가 있지요.
객체지향 프로그래밍의 진가는 '상속'에 있다고 생각합니다. 조만간 더 언급하도록 하겠습니다. 의견 감사합니다. ^^
객체지향 잼있게 봤습니다. 혹시 함수형 프로그래밍도 조금 설명 해 주실수 있으신가요? 이건 잘 이해가 안되서 ^^;;
피드백 감사합니다. 조만간 준비해보겠습니다만...이런 영상을 올리니까 댓글 공격도 함께 들어와서 대응은 필요해 보입니다. ^^
근데 매번 볼때마다 궁금한건데
판서 프로그램 뭔가요? ^^;;
파워포인트 같지는 않고 ㅎㅎ
MS 화이트보드 입니다. 감사합니다. ^^
항상 잘 듣고있습니다 정말 감사합니다
좋은 평가와 피드백 감사합니다. ^^
널널한 개발자님 조금만있으면 구독자 5만까지도 달리실거같습니다! 정말 축하드려요
응원 감사합니다. 그래도 2023년이 오기 전에 4만은 달성했으면 바라고 있습니다. ^^;;
서양철학에 영향으로 객체지향이 등장했다는 이야기는 뇌피셜이라고 하셨지만 여러 사람들이 이런 이야기를 하더라고요 어쩌면 정설이 아닐지 어떤 블로그에선가 이런 비슷한 이야기를 읽었던 기억이나네요 좋은 영상 감사합니다
사실 누구도 확인할 수 없는 것입니다. 플라톤과 아리스토텔레스가 객체지향 프로그래밍을 공부했을 가능성도 없고요. 음...그냥 추론입니다. 근거도 저의 주관적 의견에 불과하고요...이것을 제대로 규명하려면 논문도 꽤 나오지 싶습니다. 그저 재미와 OOP공부 보조 수단으로 이해해주시면 좋겠습니다. 감사합니다. ^^
흥미로운 접근에 시간이 가는 줄 모르고 봤네요.!! 감사합니다
좋은 평가 감사합니다. 이런 해석도 있다는 정도로 가볍게 이해해주시면 좋겠습니다. ^^
철학은 무한 세상에 대한 정의이고 프로그래밍은 유한 세상에 대한 정의죠.
저도 철학을 개발에 활용하고 있습니다.
저에게 영감을 주는 철학자는 비트겐슈타인입니다.
수학과 철학이 결합된 분이라...요즘 세상에 태어나셨다면 개발자가 되지 않았을까 싶은 생각이 듭니다. 의견 감사합니다. ^^
선생님 설명을 정말 잘해주셔서 잘 보고 있습니다. 혹시 회원 전용 동영상에는 어떤 것들이 있는지 알수 있나요?
회원 전용 영상은...라이브 방송 다시 보기와 멤버십 전용으로 묶인 영상들이 전부입니다. 어떤 영상들이 있는지는 재생목록에서 확인 할 수 있습니다. 참고하시기 바랍니다. 감사합니다. ^^
@@nullnull_not_eq_null 선생님 재생 목록에서 [멤버쉽 전용 - 주제없음]이라고 묶인 목록에는 영상이 하나밖에 보이지 않아서요. 이렇게 확인하는게 맞나요?
@@pengpeng7106 네트워크 강의에도 공개된 것과 멤버십으로 묶인 것들이 표시됩니다. 즉, 목록이 공개되어 있다 해도 모든 영상이 다 볼 수 있도록 공개되어 있지 않습니다. 참고하시기 바랍니다. ^^
@@nullnull_not_eq_null 아 네 선생님 이해했습니다. 목록만으로 회원 전용 영상인지 아닌지는 확인이 안되는군요. 감사합니다.
솔직히 공감가는 이야기입니다...
사실관계를 떠나...딱히 부정하기도 애매한...^^;;; 공감 감사합니다.
재밌는 얘기 감사합니다
피드백 감사합니다. 딱 재미로 이해해주시면 좋겠습니다. ^^
안녕하세요 객체지향 설명 감사합니다. 이데아론 보고 질문 드리는데요 근데 객체지향에서 유명한 비유있잖아요 클래스는 붕어빵틀이고 객체는 붕어빵
근데 이비유가 틀렸나요? 어떤분은 나의 상상속 붕어빵이 클래스고 객체가 붕어빵이라는 사람도있고
어떤사람은 클래스+인스턴스 등등을 합쳐서 객체이고 클래스 자체도 객체라고 하는데 데체 뭐가 맞는건가요???
영상으로 답변합니다. :)
ruclips.net/video/alZBfnOiZQw/видео.html
코딩에 관심 1도없는 사람이 듣더라도 재미있게 들을 것 같네요
좋은 가르침 감사합니다!
좋은 평가와 피드백 감사합니다. ^^
우와 갑자기 '객체지향'이라는 단어가 선생님 영상에서 보여서 깜짝 놀라서 달려왔어욬ㅋㅋ자바개발자가 되고싶은 인문학도인데, 저도 철학에 관심이 많아서 객체지향 배울 때 플라톤이 제일 먼저 떠올랐어요 ㅋㅋ 자바를 점점 깊게 배우다보니까 사알짝 다르긴 한 것 같지만 ㅎㅎㅎ 처음에 이렇게 생각하니까 OOP 너무 쉽게 이해되더라구요
앞으로 객체지향 프로그래밍 강의해주신다고 하니까 너무 좋아요~~ 아 글구 가능하시다면 가끔 웹 이야기도 해주시면 정말 감사할 것 같아요 너무 재밌어서요ㅋㅋ 오늘도 영상 잘봤습니당!!
의견과 피드백 감사합니다. 좋은 평가도 감사하고요.
웹 이야기도 더 자주 하도록 노력하겠습니다. 재밌게 봐주셔서 감사합니다. ^^
"아름다움"이 추상 부모클래스라고 하면
"설인아", "김혜수","김태희"는 그 추살클래스를 구현한 구체클래스라고 할때,
말씀하신 "실체"는 구체클래스일까요 아니면 구체클래스의 인스턴스일까요?
설인아, 김혜수, 김태희는 구현(구체) 클래스의 인스턴스 입니다.
따라서 질문오류가 되겠습니다.^^;;;
저는 죄송하지만 약간 다르게 봅니다.
아름다움은 부모 클래스가 가지는 속성 중 하나입니다. 속성의 형식이 "아르다움" 이죠.
class 아름다움 { public int 심적; public int 외적; }
이 속성을 보유한 부모로부터 파생된 모든 자식은 아름다움이란 속성을 물려 받습니다.
부모:
class 인기인 { public 아름다움(형식) 아름다움(이름); }
자식:
class 연예인 : 인기인
class 얼짱 : 인기인
설인아, 김혜수, 김태희는 실존하는 연예인 즉, 연예인의 인스턴스입니다.
이들은 공통적으로 아름답지만, 개별 인스턴스마다 정도의 차이가 있는 것(상태가 다른 것)이죠.
유럽에서 오래 생활한 경험에 비춰볼 때, 철학보다는 오히려 법리를 옮겨 놓은 느낌이 강했습니다..
아하~~! 그렇군요. 좋은 의견 감사합니다. ^^
애기를 듣다 보니 이마를 딱 쳤습니다. ㅋㅋ 한수 배우고 갑니다~!
이런 생각도 있구나...정도로 이해해주시면 좋겠습니다. 피드백 감사합니다. ^^
강사님! 개인적으로 정보보안과 해킹기법에 대해 관심이 많은데요! 강사님이 해주시는 강의가 듣고 싶습니다! 실습도 하면서 할 수 있으면 좋을 것 같긴 한데… 무리일까요?
공개강의로 해킹 기법을 다룰 수는 없습니다. '윤리'문제 때문입니다. 뭐, 간단한 것 정도는 다룰 수 있긴 하겠네요. 그러나 이론에 국한 될 것입니다. 의견 감사합니다. ^^
잘 들었습니다~
대학생입니다. 요즘 밥친구(밥먹으면서 보는 영상)로 꾸준히 보고있습니다. 항상 유익한 영상 감사합니다~
아하~~! 성공이네요. 피드백 감사합니다.
그냥 편하게 개념을 이해하는데 도움을 드리는 것까지가 목표라서요. ^^;;
프로그래밍 공부 시작하고나서 추상체와 구현체에 대해 배울때 말씀하신 것처럼 이거 딱 이데아 얘기같네 싶었는데
아주 조금 더 공부하다 보니까 이 생각에서 추상체는 구현체를 다루기 위한 버튼 정도로 생각되더라구요
더더욱 공부하다 보면 또 이게 다시 원래의 이데아로 바뀔까요??
좋은 강의 감사합니다 ㅎㅎ
지금 딱 UML과 객체지향, 클린코드에서 계속 고통받는 중인데 딱 좋은 타이밍이네요!! 매일 꼭 챙겨보겠습니다!
음...버튼이 주로 인터페이스죠. 자판기의 복잡한 구조를 추상화한 인터페이스! ^^;;;
그리고 원래의 이데아로 갈지는 잘 모르겠습니다. 저는 의견만 드릴 수 있을 것 같네요. 의견 감사합니다.
Data 와 Code 를 서로 분리하는 이점은 어떤 것이 있나요? 함수형 프로그래밍의 인문학적 접근도 해주세요 ㅎㅎ 철학적 접근 재밌네요
좋은 평가와 피드백 감사합니다. 그리고 요청하신 영상은 이미 올렸습니다. ^^
ruclips.net/video/YY9lvCFxXpY/видео.html
와... 진짜 생각해보니까 그러네요
좋은 강의 잘 들었습니다
공감 감사합니다. 근거는 오직 저의 뇌피셜입니다. 그러니까...음...이렇게도 생각할 수 있구나 정도로 이해해주시면 좋겠습니다. ^^;;;;
명강의 감사합니다. 객체지향을 코드로 배우면 이해할 수 없지요. 특히 c++
23분짜리 올린지 이제 5분됐는데...
거의 라이브죠. ^^;;;
좋은 평가와 의견 감사합니다. 돌이켜 생각해보면...'객체지향'이라는 관념을 이해하기 까지 상당한 시간이 걸렸던 것 같습니다. 해서 그런 이야기들을 올려보려 합니다. ^^
감사합니다!
항상 좋은 강의 감사드립니다. 요즘은 국비지원웹개발학원을 다니고 있는데 짬짬이 선생님 강의보는게 낙이네요 ㅋㅋ.. 화이팅입니다!
좋은 평가 감사합니다. 열공하시고 좋은 성과 거두기를 바랍니다. 필요한 강의가 있으면 언제든 요청하시고요. ^^
감사히 잘 들었습니다! :)
피드백 감사합니다. 즐프 하세요. ^^
와 객체지향 강의 기대됩니다. 오랫동안 c++. java 개발자로 살아왔지만 맨날 쓰는 코드만 쓰다보니 전반적인 지식이 부족함을 항상 느껴왔습니다. ^^
강의 열심히 듣겠습니다!!
쓰는 코드만 쓰는 이유는 소위 실무에서 검증됐기 때문이고 1분 1초라도 빨리 퇴근할 수 있는 방법론이기 때문이지 않나 생각합니다. 문제는 그 틀에 갖혀 복붙을 반복하다보면 내가 개발자가 맞는지 회의감이 몰려온다는 것이고 더 큰 문제는 나만 쳐지는 것 같은 불안함이죠. 네, 제 경험입니다. ^^;;;;;
열심히 강의 만들어서 제 경험을 공유해드리겠습니다. 즐프하세요.
@@nullnull_not_eq_null 네 정말 맞는 말씀입니다.. 클래스 설계를 언제해봤는지 기억도 가물가물합니다.... 맨날 복붙복붙복붙...T.T
@@chancethe9374 가볍게 보실 수 있는 영상으로 자주 올리겠습니다. 그렇게 조금씩 조금식 다른 사람들 의견도 듣다보면 변화가 있으리라 생각합니다. 즐프하세요~~~! ^^
노자 도덕경 1장에 도가도 비상도 명가명 비상명이라고 도를 도라고 말하는 순간 그것은 도가 아니며 이름을 이름이라 말하면 그것은 이름이 아니다 는 구절과 김춘수의 꽃이라는 시가 떠오르네요.
객체지향 이야기를 한참 하다보면 내가 IT기술에 대해 말하고 있는 것이 맞는지 헷갈릴 때가 종종 있습니다. 김춘수님의 '꽃' 이야기를 하면 나라는 실체는 그에 대해 '꽃'이라는 추상화된 인터페이스를 제공하는 것인가? 그렇다면 이는 인터페이스 분리 원칙에 따라... 뭐 대충 이런 생각을 하게 됩니다. -_-;;;
문과 출신인 제가 이해하는 객체는 아래와 같습니다.
객체라는 번역어의 원어는 object 입니다. 이 object 는 수학의 집합론에서 나온 개념으로, 정의(definition)의 대상 또는 목적입니다.
definition is about an object.
object가 집합론에 출현한 이유는 정의를 다루는 수학이 집합론이기 때문입니다.
수학에서는 부인 불가능한 오류가 없는 정의가 필요합니다.
"한 마을의 이발사는 자신의 손으로 머리를 깍지 않는 사람이다" => 부인 가능한 정의의 한 예입니다. 이발사는 자신의 머리를 깍을 수도 깍지 않을 수도 있기 때문입니다.
어떻게 하면 부인되지 않는 방식으로 정의를 할 수 있을까에 대한 고민의 결과물 중에 하나는 "부류"로 정의를 하는 것입니다.
부류는 "특징의 집합"으로 표현됩니다. (그래서, 집합론...)
정의를 위한 집합에 속한 각 요소를 그 집합의 멤버라고 합니다.
부류를 영어로 하면 class 가 되죠 (classfy : 분류하다). 특정 부류에 속한 모든 특징을 부류의 유형(type)이라고 합니다.
특정 부류로 정의된 object가 실체화된 것을 instance라고 합니다. 호랑이라는 관념(object)은 호돌이 그림으로, 살아 있는 동물로, 컴퓨터 그래픽으로 실체화될 수 있습니다. 프로그래밍에서는 일정 영역의 메모리 덩어리로 실체화됩니다.
집합론의 정의방법을 차용한 대표적인 것이 생물학적 분류법입니다. 계-문-강-목-과-속-종...
어떤 특징이 있으면 A계, 없으면 B계,
A계 중에서 또다른 특징이 있으면 AA 문, 아니면 AB문...
집합론의 정의 방식을 차용한 프로그래밍 기법이 객체 지향 프로그래밍(object oriented programming)입니다.
이 기법에서는 프로그램적으로 존재하는 관념적인 것을 object로 보고, 그것을 부류(class)로 정의하고, 메모리에 인스턴스화시킵니다.
이 기법에서 요구하는 원칙 중, 정의의 구체성에 관한 것이 추상성입니다.
추상성은 합목적성과 계층성으로 나타납니다.
합목적성은 한 object가 가질 수 있는 모든 특징을 클래스에 전부 나열하려 들지 말고, 가급적 다 빼버리고, 꼭 필요한 것들만 멤버로 선택하라는 의미입니다. "다 빼버린다" 요 말이 추상성의 핵심입니다.
사람 class 는 사람 object가 가질 수 있는 모든 특징 중에 이름과 나이만 필요하다면 그 두개만으로 정의해야 합니다.
이렇게 정의되면 모든 사람 instance 는 이름과 나이만 보유합니다. 만약 특정 인스턴스가 전화번호도 가지고 있으면 사람이 아니무니다~~
계층성은 한 부류에 대한 정의는 수직적 계층 구조로 나눠서 정의한다는 것입니다. 그 부류의 상위 계층에 대한 정의는 작은 집합(멤버의 갯수가 적음)으로, 하위 계층으로 갈수록 상위 집합에 특징을 추가합니다. (멤버 갯수가 많아짐)
동물 부류는 "움직임"이라는 특징만을 담고, 그 하위부류인 포유류는 동물 부류에 "젖을 먹임"이라는 특징을 추가하고, 그 하위부류인 사람은 포유류에 "지능"이라는 특징을 추가하는 식으로..
하위 계층으로 갈수록 그 부류가 가진 특징의 갯수가 늘어나서 더 구체적인 정의가 되고, 반대로 상위로 갈수록 추상적인 정의가 됩니다.
그리고, 하위 계층의 부류는 여전히 상위 계층의 유형으로 치부할 수 있습니다. 사람이 동물이기도, 포유류이기도 한 것처럼요.
수직적 계층 구조는 곧 특정 부류의 정체성의 범위를 한정하는 역할을 하는데, 이는 자원 (메모리)의 효율적 운영과 연관이 있습니다.
"움직임"만 필요한데, "젖먹이고", "지능" 이 있는 인스턴스를 사용하는 것은 낭비이기 때문이죠.
영상에서 설명하신 추상성은 abstract 키워드에 관한 것입니다.
이는 객체의 추상성에 관한 것이 아니라 주로 멤버의 추상성을 나타내기 위한 것입니다.
그 키워드는 어떤 부류에 특정 속성이 있기는 한데, "구체적으로 정의되지 않음"을 나타냅니다.
쉽게 얘기하면 현 계층에서는 그 특징이 무엇인지 확정하기에 곤란하니 후대에서 확정하라는 의미입니다. 반대로, 후대에서 너무 다양하게 구체화되니까 현 계층에서는 딱 꼬집어 말할 수 없다는 의미도 됩니다.
사람은 "놀다"라는 특징이 있는데.. 하위 계층인 직장인은 당구치며 놀고(당구장에 의존), 또 다른 하위 계층인 학생은 게임(피씨방에 의존)하며 놀죠. "놀다"라는 특징은 직장인/학생 계층에서 갑자기 나타나는 특징이 아니라, 사람이 가지는 특징입니다. 다만, 사람 계층에서 그 내용을 구체적으로 확정할 수 없다는 사정이 있을 뿐인 것입니다.
abstract 키워드는 그런 멤버에게 사용하는 것인데, 그 이면은 멤버가 구체적으로 정의되지 않아도 컴파일러에게 뭐라하지 말라는 일종의 까방권입니다.
참고로 인터페이스는 수평적인 부류를 나타냅니다.
비행기, 날치, 참새는 동일한 정체성을 공유한다고 볼 수는 없지만 공통적으로 "날 수 있는" 특징을 공유합니다. 인터페이스는 정체성이 아니라,공통적으로 나타나는 특징을 하나의 부류로 정의하는 수단입니다.
날수 있는 유형의 객체들은 모두 날 수 있습니다. 그래서, 그 객체들에게 "날아봐!"라고 명령하면, 비행기는 엔진을 돌리고, 참새는 날개짓을, 날치는 수면위로 점프를 하는 등, 각자 자기만의 방식으로 "날다"를 구체적으로 정의합니다.
이와 같이 인터페이스에 속한 멤버들은 하위 부류에서 너무 다양하게 나타나기에 구체적으로 정의되지 않아야 합니다.
즉, 인터페이스 멤버들은 abstract 키워드가 없어도 기본빵으로 abstract 한 특징이 있습니다. 그래서, 인터페이스 유형은 점멤버가 까방권이 있습니다.
스스로 공부하며, 인터넷을 떠돌다 보니.. C/C++ 기반의 개발자들이 객체를 메모리적인 개념으로만 이해하려는 경향이 강해, 객체 지향 언어의 다양한 개념들을 이해하는데 어려움 또는 오해하고 있는 것을 많이 보고 안타까운 나머지 장문이지만 댓글을 남겨 봅니다.
저는 C -> Java 조금 -> 스몰토크 를 거쳐 현재는 C#에 안착한 한량입죠. ㅠㅠ
좋은 의견 감사합니다. C/C++ 개발자들의 객체를 메모리적 개념으로 이해하는 경향은 구조체의 연장으로 이해하기 때문이 아닐까...추측해봅니다. (딱히, 근거는 없습니다. ^^;;) 앞으로 객체지향 프로그래밍에 대한 제 의견을 계속 올려보겠습니다. 그 때도 의견 부탁드립니다. ^^
@@nullnull_not_eq_null 별 말씀을요.. 영상을 통해 많은 위안을 받고 있습니다. 전공자가 아니다보니.. 하드웨어 저수준에 대한 개념을 매우 긴 시간동안 어깨넘어로.. 파편화된 글들로 익히다 보니, 억지로 끼워 맞춘 연결고리가 많았습니다. 어떤 영상은 저의 추측이 옳았음을 확인시켜주셨고, 어떤 영상은 부족한 연결고리를 채워주셨습니다. 그점 많이 감사하게 생각합니다.
이 댓글에서도 C/C++ 개발자들의 경향성이 구조체에 있다는 말씀으로 저의 오랜 의구심이 해소되는 것 같습니다.
사실, C#에서는 구조체가 이제는 거의 사용하지 않는 계륵과 같은 존재입니다(제 느낌). 그래서 그런 사정을 이해할 리가 없죠. ^^ 저는 필터링할 모델 객체가 많을 때(수백만 개를 넘을 때) 성능 개선을 위해 몇번 써보았는데, 별도움은 못 받았습니다.
최근에는 record 라는 또 다른 형식이 도입되어서 구조체에 달린 인공호흡기마저 떼는 것만 같습니다.
제가 C#하고는 많이 친하지가 않아서...^^;;;
다만 요즘 C/C++이 이젠 시대적 사명을 다한 것 같다는 생각을 하고 있습니다. 심지어 '성능'에서 조차 큰 장점을 찾기 어려워지는 것 같고요. 나중에 다시 C#도 복습할 예정입니다. 그 때, 제가 잘못다루는 내용이 있다면 꼭 알려주시면 좋겠습니다. 감사합니다.
@@nullnull_not_eq_null 여부가 있겠습니까. 그래도 저 보다는 나으시겠지요.
자바보다는 C#이 좀 더 다듬어진 것 같아 사용하고는 있지만 요즘은 스크립트 언어가 워낙 강세라서 위기이기는 매한가지입니다. 그래도 마이크로소프트 믿고 갈 밖에요
나을 것 별로 없습니다. 개발자는 은퇴하는 그 날까지...새로움을 받아들어야 하는 운명인지라...안 해봤다면...초보죠 뭐. 최근에는 JS에 흥미가 생겨서 조금 파고 있습니다. 의견 감사합니다. ^^
RAM 을 자료(구조)라고도 말한다. 몰랐습니다.
메모리는 자료(혹은 정보)를 담는 수단이지요. 이렇게도 표현하는 구나 정도로 이해하시면 되겠습니다. ^^
아 진짜..감사합니다.
피드백 감사합니다. 열공하세요~!!! ^^
개발쪽 전문성으로 이렇게 구독자수 끌어올리기 굉장히 어렵다는걸 압니다ㅎㅎ
공감해주셔서 감사합니다. ^^
탁견이십니다.
좋은 평가 감사합니다. 정설이 아니므로...이런 생각도 있을 수 있겠다 정도로 봐주시면 좋겠습니다. ^^;;;
선댓글 후감상 제목부터가 심상치가 않아 .. 하악
아...그럼 실망하실 수도...^^;;;;;
요 근래 들어 제목이, 아주 그냥 구독자 쭉쭉 빨아들이는 뭐랄까 아주 감각적? 이신듯... ^^ 늘 화이팅입니다~!!!
좋은 평가로 이해하겠습니다. ^^;
조금 오래된 개인적 생각입니다만...한번 썰을 풀었습니다. 응원 감사합니다. ^^;;;;;
유튜브 순기능의 극한
좋은 평가 감사합니다. ^^
생명과학에서 아이디어를 얻었다는 주장이 있네요.
ruclips.net/video/MXLw0EsxBjI/видео.htmlsi=2dnYaJotsc5wmGMW
관련해 몇 가지가 더 있습니다. 다만....이런 이야기를 나열하다보면 프로그래밍이 아니라 철학이나 종교 문제를 다루는 것 같은 난해함이 있지요. 정보 고맙습니다. :)
철학 몹시 조아라 합니다.
뚜껍 한게 라면 받침으로도 좋겠고, 목침 대신으로도 딱....쩝...
추상클래스 저누므 시키 공부하다...음 ...난 객체랑 안맞나 했는데...
역시 원인은 저걸 만든 놈들이, 나랑은 다른 삶을 사는것들이 만들다 보니 음...그럴수 있겠네요...
역시...력시...
하하 감사합니다. 😮
이게 참 그런 것이...우리나라 사상은 '중용'으로 설명되는 경우가 많다보니...서양인의 그것과는 차이가 좀 크다고 생각합니다. 무엇보다 우리는 동사가 중요한데 저들은 주어가 중요하죠. 그것도 관련이 있지 않을까...라는 생각도 합니다. ^^;;;
왠만한 미드도 씹어먹는 재미..
와우~~~! 좋은 평가 감사합니다. ^^;;;