비전문가에게 OOP 개념을 설명하는 방법?

나는 종종 사람들에게 프로그래머라고 말하는 것을 피하려고 노력한다. 내가 Java로 프로그래밍하고 있다고 말하면 종종 언어에 대한 일반적인 질문과 언어가 x와 y와 어떻게 다른지 묻습니다. 나는 또한 1) 나는 그 분야에서 그다지 경험이 많지 않고 2) 기술이 아닌 사람들에게 물건을 설명하는 것을 정말로 싫어하기 때문에 물건을 잘 설명하지 못합니다.

그들은 당신이 다른 사람에게 설명하면 사물을 진정으로 이해한다고 말합니다.이 경우 OOP 용어와 개념을 기술이 아닌 사람에게 어떻게 설명 하시겠습니까?

나는 일반적으로 실제 예제를 사용하여 Object-Orientated-Programming을 시도하고 설명합니다.

예를 들어, 클래스라는 클래스 Vehicle는 차량의 최소 요소를 설명 한다고 말할 수 있습니다 . 나는 그 사람이 차량이라고 생각하는 것을 말해달라고 부탁 할 것이다. 때때로 그들은 "글쎄, 자동차 나 트럭처럼"이라고 말하며, 나는 그들을 끄덕이며 동의 할 것입니다. 그런 다음 자동차와 트럭의 차이점을 묻습니다. 때로는 크기, 목적 및 기타 사항을 언급하기도합니다.

그런 다음 자동차 나 트럭을 잊어 버리고 계속해서 차량을 설명하도록 요청합니다.

"아, 잘 움직여"

"운영자 또는 드라이버가 있습니다"

기타...

곧 우리는 비히클이 무엇인지 알고 OOP에서 비히클을 정의하겠다고 말했고 논쟁을 위해 움직일 수 있고 일종의 드라이버를 줄 것이라고 말했습니다. 그럼 물어 볼게요, 그래서 자동차는 무엇을 가지고 있습니까?

"문"

"Windows"

그리고 트럭 ....

"문" "창" "더 많은 바퀴!"

곧 많은 토론 끝에 다른 사람은 일반적으로 다음을 확인했습니다.

1) 차량을 구성하는 것

2) 자동차를 구성하는 것

3) 트럭을 구성하는 것

4) 비행기를 구성하는 것.

모든 기술이 없습니다. 우리는 각각의 속성을 올바른 영역으로 나누었습니다. 그들은 상속을 이해합니다 ( "예, 자동차는 차량, 트럭은 차량이지만 자동차는 트럭이 아닙니다, 간단합니다!").

그들은 다형성 (polymorphism)도 이해합니다. "물론 그들은 기본적으로 똑같이하지만 약간 다르게 할 수 있습니다." 우리는 행동과 그것이 우리의 나무에서 어디에서 살아야하는지 이야기 할 수 있습니다.

그들의 교육과 배경에 따라, 어떤 사람들은 다른 사람들보다 더 빨리 얻습니다. 그러나 OOP를 실제 객체와 비교할 때 대부분의 사람들은 항상 그것을 얻습니다. 사실, 내가 생각하지 못한 비 기술적 인 사람들과의 대화에서 발견했습니다. 차량은 예를 들어 (론)과 같이 유인 할 필요는 없지만 프로그래머가 차량의 운전자를 차량의 속성으로 생각했을 것입니까? 운영자를 언급하는 것이 옳고 그른 것은 아니지만 소프트웨어를 개발할 때 모델링 대상과 달성하려는 목표를 생각하게합니다.

다른 한편으로, 부분 템플릿 전문화 .... :)

객체는 명사이고, 메소드는 동사입니다.

기술이 아닌 사람에게 제공하는 통조림 답변의 일부 버전은 다음과 같습니다.

프로그래밍은 컴퓨터에서 현실을 표현하려는 시도입니다. 이미 존재하는 많은 도구와 장치가 있습니다. 스프레드 시트로 회계 나 통계를보다 쉽게 ​​표현할 수있는 방법이나 Powerpoint 프레젠테이션을 통해 프레젠테이션을 저장하고 표시 할 수있는 방법에 대해 생각해보십시오.

때로는 비즈니스 프로세스를 반영하는 새로운 응용 프로그램이나 기존 응용 프로그램에 사용자 지정 현실 표현을 구축해야 할 때가 있습니다. 프로그래밍하는 방법에는 여러 가지가 있으며 프로그래밍하는 가장 일반적인 방법 중 하나는 객체 지향 프로그래밍입니다. 여기서 우리가 구축하는 코드는 현실 개념을 복제하도록 특별히 설계되었습니다. 실제로 "사물"에는 속성과 행동이 있습니다. 예를 들어, 인간은 종종 팔과 다리, 머리 색깔, 민족을 가지고 종종 말하기와 걷기를 할 수 있습니다.

말하기와 걷기는 언어의 언어 나 걷는 속도 나 방식과 같은 다양한 종류가 있습니다.

인간은 종종 동물, 다른 인간, 다른 살아있는 유기체 또는 무생물 인 다른 유형의 "사물"과 상호 작용합니다. 실제로 "사물", 사물 분류 등의 상호 작용과 같은 표현 방법이 종종 필요한 테마가 있습니다. 조직에서 진행되는 비즈니스 프로세스를 고려하십시오. 조직에서 사용하는 소프트웨어에서 표현해야하는 매우 복잡한 "비즈니스 로직"이 있습니다.

객체 지향 프로그래밍은 이러한 "실제 개념"과 "비즈니스 로직"을 정확하게 표현할 수있는 수단을 제공합니다.

->이 진술은 일반적으로 호기심을 피하기에 충분하지만 (혹은 눈물을 흘리기 위해), 더 많은 질문이있는 경우 위의 진술은 대화가 어디로 갈 수 있는지에 대한 적절한 토대를 마련합니다. 나는 비 기술적 인 사람이 "추상", "구성", "다형성"등과 같은 기술 용어에 너무 많이 관심이 있다고 생각하지 않지만, 만약 그렇다면, 통조림에 사용 된 언어로 인해 이를 기반으로 예제를 가져옵니다.

나는 항상 다음과 같이 OOP를 배웠다 :

당신은 시계를 가지고 있으며 시간을 알려줍니다. 프로그래밍에서, 모든 코드와 모든 것을 함께해야합니다 (사운드가 들리지만 사람들은 초기에는이 방법을 사용하지 않았습니다). 어쨌든,이를 캡슐화 라고 합니다 .

이제 시계가 생겼습니다. 자명종을 원할 수도 있습니다. 일단 모든 것을 모은 후에는 알람을 설정하고 울리는 것처럼 더 많은 일을 할 수 있도록 일을 추가 할 수 있습니다. 이것을 상속 이라고 합니다.

또한 손목에있는 시계를 볼 수 있지만 할아버지 시계 나 디지털 시계와 다르게 보이는 다른 시계를 볼 수 있습니다. 그것은 다르게 보이지만 여전히 시계입니다- 다형성 이라고 합니다.

그리고 여기에는 객체 지향 프로그래밍의 3 가지 코너가 있습니다. 나머지는 모두 코딩입니다.

그들이 정말로 이해하고 싶다면 OOP 코스에 등록하라고 지시하면됩니다.

내 말은, Car.startEngine (); 순수한 랩입니다. 몇 년 전에 OOP를 처음 시작했을 때 도메인을 더 추상화하기 만했습니다.

OOP가 절차 적 언어의 복잡성을 관리하는 것이라고 설명하는 대신 프로그래밍 책 저자의 거의 80 %가 프로그래머가 단순한 말로 말해야 할 단서가없는 바보라고 가정합니다.

그렇습니다. 목록과 벡터를 설명하는 것은 정상입니다. 왜냐하면 Car.Engine과 PoliceMan.Arrest가 아니라 주로 작업하는 것이기 때문입니다 (게임 개발자가 아니라면 다시는 전자).

주제로 돌아가서 나는 단지 그들에게 말할 것입니다. 나는 급여 처리 / 게임 플레이 / 우주 왕복선 탐색 등을 목적으로 프로그래머의 마음에 순수하게 존재하는 무형의 물체를 만듭니다.

그래도 질문이 있으면 그만한 가치가 없기 때문에 논의를 중단하십시오. 대부분의 사람들은 추상적 개념을 상상하지 못하고 거의 모든 것에 대한 예제가 필요합니다 (실제 주제의 단순화 / 전문화를 의미합니다).

내가 여기에이 대답에, 나는 바로이 일에 대해 내 아내와 가진 대화에 대해 이야기 : /software/45464/how-to-convince-non-programmer-his-notions-about- 컴퓨터가 잘못되었거나 / 45467 # 45467

편집 : 내가 대답 한 질문이 완화되었으므로 여기에서 내 대답을 보복 할 것입니다.

아내와 함께 식당에 앉아 그녀는 "개체 지향이란 무엇입니까?"라고 물었습니다.

코드 재사용, 캡슐화 및 다형성에 대해 팽팽하게하기 시작했고 어느 시점에서 나는 그녀의 눈이 말미암아 끝났다는 것을 깨달았습니다.

그래서 컨테이너에서 Splenda 패킷을 가져 왔습니다. "객체가 있습니다. 속성은 무엇입니까?"

그녀는 "직사각형이고 종이로 만들어졌으며, 화려 함을 포함하고 있으며 파란색이며 인쇄되어 있습니다"라고 말했습니다.

나는 설탕 소포를 집어 들었다. "이것과 공통점이 무엇입니까?"

그녀는 "직사각형, 종이, 인쇄가있다"고 말했다.

나는 "둘 다 단 것을 포함하고있는 것은 어떻습니까?"

그녀는 "물론"이라고 말했다.

"이 둘은 우리가 추상 감미료 패킷이라고 부르는 것의 실례입니다. 원한다면 플라토닉 이상적인 감미료 패킷입니다."

그녀는 "물론"이라고 말했다.

"각각 추상 패킷에서 상속 된 속성을 가지고 있으며, 그 유형에 따라 다른 것들에 대한 변형이 있습니다."

그녀는 "맞습니다. 아! 그리고 만약 사카린 패킷과 같은 것을 만들고 싶다면, 나는 사카린 패킷을 가지고 사카린에 대한 세부 사항을 설정하고 나서 그것을 가질 것입니다!"

"빙고 : 객체 지향 프로그래밍"이라고 말했습니다.

당신과 나는 그녀가 방금 공장 디자인 패턴으로 그녀의 길을 직감했다는 것을 알고 있습니다. 도대체 무엇이. 상속, 캡슐화, 객체 클래스의 정체성을 보여줍니다.

그럼에도 불구하고이 질문은 마감 될 후보로 보인다.

대부분의 경우와 마찬가지로 OOP는 실제로 개념 수준에서 설명하기가 매우 간단합니다. 프로그래머는 객체를 모델링합니다. 과:

• 개체 상태 (필드 / 데이터 멤버)
• 객체에는 액션이 ​​있습니다 (방법 / 기능)
• 서로 위에 쌓인 물건 (상속)

이것들은 수백 가지의 세밀한 세부 사항입니다. 그러나 누군가에게 10 초 개요를 제공하려는 경우 좋은 출발이라고 생각합니다. 설명하는데 문제가있는 더 구체적인 개념이 있습니까?

휴대 전화 예 :

공장 소유자라고 가정하고 일반 전화를 설명하려고합니다.

• 1 단계 :이 일반 전화 속성을 나열 합니다 ( 예 : 신장, 체중, 색상 등)
• 2 단계 : 일반 전화 기능 나열 예 : 전화 걸기, 전화 받기, SMS 보내기 등

이제 일반적인 "청사진"을 가지고 다음 전화를 만드십시오.

전화 1 :

• 높이-> 102mm

• 무게-> 85g

• 컬러-> 핑크

전화 2 :

• 높이-> 125mm

• 무게-> 96g

• 컬러-> 레드

OOP에 대해 비 기술적 인 유형을 설명하는 가장 좋은 방법은 OOP와 관련이 있다고 생각합니다.

본질적으로 OOD & OOP는 상호 작용하는 세계로 설계하고 구현하는 시스템에 대해 생각하기를 원합니다.

따라서 인터넷에서 결코 잘되지 않는 논쟁을 위해 OOD & P에 대해 쓰레기 수집가에게 설명하고 있다고 가정 해 봅시다. 그의 이름은 밥입니다. 당신은 15 년 전에 그와 함께 학교에 다녔고, 술집에서 그를 만났고, 서로의 삶에 관심을 가지고 있습니다.

"그래, 존, 너는 프로그래머라고 말해. 내 조카는 그 말도 안돼 Bob은 맞춤법이 잘못된 철자 영국식입니다.

"음, 밥." "정말 간단하다. 쓰레기를 모으는 게 맞지? 일반적으로 직장에서 뭐하니?"

"글쎄, 나는 마을 주변의 밴을 따라 쓰레기를 집어 들고 밴에 넣었다"고 밥은 대답했다.

그리고 당신은 그것을 들어야합니다. 그것들은 우리의 행동입니다. 기본적으로 디자인에 필요한 전부입니다. 객체 지향 프로그래밍은 본질적으로 디자인을 구현하는 방법입니다. 언어마다 다릅니다. "

밥은 그의 맥주에서 잠 들었다. 당신은 멀리 걸어갑니다.

나는 상속을 설명하기위한 자동차 예제를 좋아합니다 (차량보다는 동물을 사용하는 경향이 있지만 같은 생각입니다).하지만 객체 지향 프로그램이 어떻게 작동하는지 설명하기 위해 Chris Crawford의 웹 사이트에서 한 번 읽은 비유를 말합니다. 정말 효율적인 관료. 프로그램의 모든 다른 대상은 관료주의의 다른 부서와 같습니다. 각 부서는 자체적으로 지정된 업무를 수행하고 있으며, 정의 된 입력 (누가 대화해야하고 어떤 양식을 작성해야하는지)을 가지고 있으며 다른 부서는 종종 내부에서 진행되는 일에 대해 많이 알지 못합니다. HR은 추상 공장과 같으며 IT는 싱글 톤 등입니다.

컴퓨터 프로그램에 잘못된 것을 입력했기 때문에 오류 메시지가 나타나는 것은 사무실에 제출하기 위해 잘못된 양식을 작성하는 것과 정확히 같습니다.

OOP는 인간의 사고 과정에 대한 추상화와 세계에 대한 이해가 기능을 디지털 "void"로 투영하여 친숙한 프로세스와 분류를 디지털 방식으로 모방하는 경우 전체적으로 단순화합니다. 많은면에서 우리는 "컴퓨터와 같이 생각하는 것"보다 원시 언어 상태에 관한 것입니다.

프로그래밍이 현실이나 인간의 생각을 모방하면 자연에서 훨씬 더 유기적이고 혼란스럽고 우연이 될 것입니다. 대신 우리는 현실을 아기 단계, "2 + 2 논리", 조잡한 범주, 재사용 가능한 작은 도구 및 선사 시대 추론으로 단순화합니다.

우리는 여전히 우리의 생각과 욕구를 프로토콜과 공통 언어로 다운로드하는 방법을 연구하려고 노력하고 있습니다. 그리고 저는 역사 학자들이 언젠가는 복잡한 원유에 매료 될 것이라고 생각합니다. 전혀 "영리한"것이 아닙니다. 가장 단순한 것까지 어떻게 결정하거나 이해하는지 쉽게 설명 할 수없는 방법을 강조합니다. 컴퓨팅은 여전히 ​​"개는 개가 아니기 때문에 개는 개"수준의 사고 진화 수준에 있습니다. 기본 언어조차도 수천 년 뒤에 있습니다.

두 종류의 마법사가 있습니다. 마법의 단어로 구체적인 일을하는 사람이 있습니다. 그는 소환에 대한 단어가 있습니다. 그는 얼어 붙은 닭고기를 얇은 공기로 보이게하는 단어를 받았습니다. 그리고 어리석은 선함으로 가득 찬 힘의 냄비 (나는 녹색, 윤기 나는 반투명을 선호합니다)를 만들기위한 또 다른 단어. 그의 말을 올바르게 적용하면 프라이드 치킨을 만들 수 있습니다.

그리고 OOP 마법사가 있습니다. 식료품 점에가는 방법을 알고있는 임프를 소환하고 닭고기 (또는 다른 음식을 준비 할 다른 재료)를 사서 요리하고 저녁 식사를 제공합니다. OOP 마법사는 자신의 임프에게 그 방법을 알려줄 필요가 없습니다. 그는이 경우 프라이드 치킨이 무엇인지 원하는 것을 알려 주면됩니다. 뿐만 아니라 OOP 마법사는 다른 미니언을 소환하여 자신의 임프 셰프에게해야 할 일을 알려줄 수 있습니다.

그래서, 주문형 수사관은 파티에서 감동을 받았지만 OOP 마법사는 많은 캐릭터 (유니콘 웨이터와 트롤 플로어 매니저와 같은)로 마술 식당을 시작할 때 원하는 사람입니다. 함께 일해야합니다. 당신이 "레스토랑"을 해결하는 문제의 모든 단계를 호출하려고하면 세부 사항에 쉽게 얽힌 수 있으며 실수를하는 것은 정말 쉽습니다. OOP 마법사는 미니언을 미리 훈련시켜 세부 정보를 정리하여 사람들이 상호 작용하도록하여 더 큰 문제를 해결하는 데 집중할 수 있도록합니다.

초등학교 카페테리아 문제로 요리사-임프를 재사용하는 것이 더 쉽다는 것은 말할 것도없고 단어를 불러서 한 번에 한 단계 씩 모두 할 때 재사용하거나 사용하지 않을 수있는 모든 쓰레기를 분리하는 것입니다 그리고 다른 단어 집합을 호출하는 단어 (더 많은 문제를 처리해야할수록 더 많아집니다).

매우 신중하게 적용하면 공정 마법사가 OOP 마법사만큼 빠르게 완료 할 수 있습니다. 그는 올바른 주문을 호출하면 OOP 마법사보다 더 많은 작업이 필요하지 않도록 올바른 방식으로 항목을 분류 할 수 있습니다. 그러나이 작업은 하나의 특정 복잡한 문제로 묶여 있기 때문에 이해하거나 복제하기가 훨씬 어렵고 많은 부분을 재사용하기가 훨씬 어렵습니다.