OOP kavramlarını teknik olmayan bir kişiye nasıl açıklayabilirim?

Çoğu zaman insanlara bir programcı olduğumu söylemekten kaçınırım çünkü çoğu zaman onlara gerçekte ne anlama geldiğini açıklarım. Onlara Java'da programlama yaptığımı söylediğimde, genellikle dil ve dilin x ve y'den farkı hakkında genel sorular soruyorlar. Aynı zamanda bazı şeyleri açıklama konusunda da iyi değilim çünkü 1) Alanda bu kadar deneyimim yok ve 2) teknik olmayan insanlara açıklama yapmaktan gerçekten nefret ediyorum.

Bir şeyi bir başkasına açıkladıktan sonra gerçekten anladığınızı söylüyorlar, bu durumda OOP terminolojisini ve kavramlarını teknik olmayan bir kişiye nasıl açıklarsınız?

Genellikle denemek ve gerçek dünya örnekleri kullanarak Nesne Yönelimli-Programlama tanımlamak.

Örneğin, denilen bir sınıfın Vehicle, bir aracın minimum şeylerini tarif ettiğini söyleyebilirim . Kişiden bana bir aracın ne olduğunu düşündüğünü söylemesini isteyeceğim. Bazen "Peki, bir araba ya da bir kamyon gibi" gibi şeyler söylerler, ben de başını sallayarak onaylarım. Sonra bir araba ile bir kamyon arasındaki farkların ne olduğunu soracağım. Bazen büyüklükten, bazen amaçtan ve diğer şeylerden bahsederler.

Sonra onlardan bir araba veya bir kamyonu unutmalarını isteyeceğim ve sadece bir aracı tarif etmeye devam etmelerini isteyeceğim:

"Ah, iyi hareket ediyor"

"Bir operatörü ya da bir sürücüsü var"

vb...

Yakında, bir Aracın ne olduğunu biliyoruz ve OOP'ta bir araç tanımlayacağımızı söyledim ve tartışma uğruna onun hareket edebileceğini ve ona bir çeşit sürücü verebileceğini söyledim. Sonra soracağım, tamam, bir arabanın nesi var?

"Kapılar"

"Pencereler"

Ve sonra bir kamyon ....

"Kapılar" "pencereler" "Daha Fazla Tekerlek!"

Çok geçmeden, birçok tartışmadan sonra, diğer kişi genellikle şunları tespit etti:

1) Bir aracı ne oluşturur

2) Bir arabayı ne oluşturur

3) Kamyonu ne oluşturur

4) Bir uçağı neyin oluşturduğu.

Hepsi herhangi bir teknik olmadan. Her birinin özelliklerini doğru alanlara ayırdık. Miras anlıyorlar ("Evet, bir araba bir araç, bir kamyon bir araç, ama bir araba bir kamyon değil, BASİT, duh!").

Polimorfizmi bile anlıyorlar, "Tabii, temelde aynısını yapıyorlar, ama bu biraz farklı olabilir.". Davranış ve bunun nesneler ağacımızda nerede yaşanması gerektiği hakkında konuşabiliriz.

Eğitimine ve geçmişine bağlı olarak, bazıları diğerlerinden daha hızlıdır. Ama OOP'u gerçek hayattaki nesnelerle karşılaştırdığımda, çoğu insan bunu her zaman elde eder. Aslında, teknik olmayan insanlarla yaptığım konuşmalarda hiç düşünmediğim şeyleri buldum. Araçların insanlı olması gerekmez, örneğin (insansız hava araçları), ama bir programcı aracın operatörünü onun bir özelliği olarak düşünür müydü? Bir operatörün bahsetmesinin doğru ya da yanlış olduğunu söylemiyorum, ancak bizim neyi modellediğimizi ve yazılım geliştirirken neyi başarmaya çalıştığımızı düşünmemize neden oluyor.

Şimdi ise kısmi şablon uzmanlığı .... :)

Nesneler isimlerdir, yöntemler fiillerdir.

Ultra teknik olmayan bir kişiye verdiğim hazır cevabımın bir versiyonu:

Programlama, bilgisayarda gerçekliğin bir temsilini yaratma girişimidir. Bunu zaten yapan birçok araç ve cihaz var - bir e-tablonun muhasebe veya istatistikleri temsil etmemizi nasıl kolaylaştırdığını veya bir Powerpoint sunumunun sunumlarımızı nasıl saklayıp görüntülememize izin verdiğini düşünün.

Bazen iş süreçlerimizi yansıtan yeni veya mevcut uygulamalara gerçekliğin özel temsillerini inşa etmemiz gerekir. Programlamanın birçok yolu vardır ve programlamanın en yaygın yollarından biri, oluşturduğumuz kodun gerçeklik kavramlarını çoğaltmak için özel olarak tasarlandığı nesne yönelimli programlamadır. Gerçekte "şeylerin" nitelikleri ve davranışları vardır. Örneğin, bir insanın genellikle kolları ve bacakları, saç rengi, etnik kökenleri vardır ve genellikle Konuşabilir ve yürüyebilir.

Konuşma ve yürüme, hangi dili konuştuğu veya yürüdüğü hız veya yol gibi farklı çeşitlerde olabilir.

İnsanlar, ister hayvan, diğer insanlar, diğer canlı organizmalar veya cansız nesneler olsun, diğer tür "şeylerle" etkileşime girerler. Gerçekte "şeyler" arasındaki etkileşimler, şeylerin kategorizasyonu, vb. Gibi temsil edilmesi gereken bir konuya ihtiyaç duyan temalar vardır. Kuruluşumuzda devam eden iş süreçlerini göz önünde bulundurun. Kuruluşumuzun kullandığı yazılımda temsil edilmesi gereken çok karmaşık bir "iş mantığı" vardır.

Nesneye Yönelik programlama, bu "gerçek dünya kavramlarını" ve "iş mantığını" doğru bir şekilde temsil etmek için bir araç sağlar.

-> Bu ifade genellikle meraklarını gidermek için yeterlidir (veya belki de gözyaşlarına sıkar), ancak daha fazla soruları varsa, yukarıdaki ifade (inanıyorum) konuşmanın nereye gidebileceği için iyi bir temel oluşturur. Teknik olmayan kişinin "Soyutlama", "Kompozisyon," "Çok Biçimlilik" vb. buna dayalı örnekler çekmek.

OOP'u hep böyle öğrendim:

Bir saatiniz var ve zamanı anlatıyor - programlamada, tüm kodları ve hepsini bir araya getirmeniz gerekiyor (oldukça açık görünüyor, ancak insanlar ilk günlerde bu şekilde yapmadılar). Her neyse, buna kapsülleme deniyor .

Şimdi bir saat şeyiniz var, bir çalar saat isteyebilirsiniz - peki, tüm şeyleri bir araya getirdikten sonra, alarmı ayarlamak ve çalmak gibi daha fazlasını yapmak için bir şeyler ekleyebilirsiniz. Buna kalıtım denir .

Ayrıca, bileğimdeki saate bakıyorsunuz, ancak büyükbaba saati veya dijital saat gibi farklı görünen diğer saatleri de yapabilirsiniz. Farklı görünüyor, ama yine de bir saat - buna polimorfizm deniyor .

Ve burada nesne yönelimli programlamanın 3 köşesi var. Geri kalan her şey sadece kodlama.

Onlara gerçekten anlamak istedikleri takdirde OOP'ta bir kursa kaydolmalarını söylerdim.

Yani Car.startEngine () gibi tüm benzerlikler; yüzleşelim - saf rap. Yıllar önce OOP'ye ilk girdiğimde, bunları yalnızca etki alanını daha da soyutlamak için buldum.

OOP'un prosedürel dillerin karmaşıklığını yönetmekle ilgili olduğunu açıklamak yerine, programlama kitabı yazarlarının neredeyse% 80'i programcıların basit bir şekilde konuşulması gereken clueless aptallar olduğunu varsaymaktadır (burada ironi?).

Evet, Listeler ve Vektörler'i açıklamak kesinlikle normaldir, çünkü Car.Engine ve PoliceMan.Arrest ile değil, çoğunlukla birlikte çalıştığımız şeydir (bir oyun geliştiricisi değilseniz, ancak yine de, eski).

Konuya geri dönersek, onlara sadece, programcının zihninde, bordro işleme / oyun oynama / uzay mekiği navigasyonu vb. Amacıyla var olan somut olmayan nesneler oluşturduğumu söyleyebilirim.

Hala soruları varsa, tartışmayı bırakın, çünkü buna değmez. Çoğu insan soyut kavramları hayal etmede başarısız olur ve hemen hemen her şey için örneklere ihtiyaç duyar (bu, gerçek konunun daha basitleştirilmesi / uzmanlaşması anlamına gelir).

Eşimle bu konu hakkında yaptığım bir konuşma hakkında konuştum, buradaki cevapta: /software/45464/how-to-convince-non-programmer-his-notions-about- bilgisayarlar-are-yanlış / 45467 # 45467

EDIT: Orada cevapladığım soru ılımlı oldu, bu yüzden burada cevabımı tekrar yazacağım.

Eşimle bir restoranda otururken bana "Nesneye Yönelik ne anlama geliyor?" Diye sordu.

Kodun yeniden kullanımı, kapsülleme ve polimorfizm hakkında kabarmaya başladım ve bir noktada gözlerinin uç uca gizlendiğini fark ettim.

Bu yüzden bir Splenda paketini kaptan aldım. Dedim ki, "İşte bir nesne. Özellikleri nelerdir?"

"Dikdörtgen, kağıttan yapılmış, splenda içerir, mavi, üzerine baskı var."

Bir şeker paketi aldım. "Bununla ortak noktası nedir?"

Dedi ki, "Dikdörtgenlik, kağıt, baskı var."

"İkisinin de tatlı bir şey içermesine ne dersiniz?" Dedim.

"Tabii" dedi.

Ben de "Her ikisi de soyut bir tatlandırıcı paketi diyebileceğimiz şeylerin örnekleridir. İsterseniz platonik bir ideal tatlandırıcı paketi."

"Tabii" dedi.

Dedim ki, "Ve her birinin soyut paketten miras alınan özellikleri ve daha sonra onun türüne özgü varyasyonları var."

Dedi ki, "Doğru. Oh! Ve eğer bir Sakarin paketi yapmak istersem, jenerik olanı alırdım ve onunla ilgili ayrıntıları Sakarin için ayarladım ve sonra buna sahip olurdum!"

"Bingo: Nesneye Yönelik Programlama" dedim.

Sen ve ben, fabrika tasarım örüntüsüne doğru ilerlediğini biliyoruz. Her neyse. Kalıtım, kapsülleme, nesne sınıfı kimliğini gösterir ... İyi şeyler.

Yine de bu soru kapalı olmaya aday görünüyor ...

Çoğu şey gibi OOP da aslında kavramsal düzeyde açıklamak için çok basittir. Programcılar nesneleri modeller; ve:

• nesnelerin durumu vardır (alanlar / veri üyeleri)
• nesnelerin eylemleri vardır (yöntemler / işlevler)
• birbiri üzerine inşa edilen nesneler (kalıtım)

Bunlar yüzlerce ince ayrıntı, elbette. Ama birisine sadece 10 saniyelik bir genel bakış sunmaya çalışıyorsanız, bunun iyi bir başlangıç ​​olduğunu düşünüyorum. Açıklamakta zorlandığınız daha spesifik kavramlar var mı?

Cep Telefonu örneği:

Bir fabrika sahibi olduğunuzu, genel bir telefon tanımlamak istediğinizi düşünün

• Adım 1: Bu jenerik telefonların özelliklerini listeleyin , örneğin: boy, ağırlık, renk, vb.
• Adım 2: Bu genel telefon işlevlerini listeleyin , örneğin: arama yapma, arama alma, sms gönderme vb.

Artık genel "plan" a sahip olduğunuza göre bana aşağıdaki telefonları oluşturun:

Telefon 1:

• Yükseklik-> 102mm

• Ağırlık-> 85g

• Renk-> pembe

Telefon 2:

• Yükseklik-> 125mm

• Ağırlık-> 96g

• Renk-> kırmızı

OOP ile ilgili teknik olmayan bir türe açıklamanın en iyi yolunun onlarla ilişkilendirmek olduğunu düşünüyorum.

Esasen OOD & OOP, etkileşime giren bir dünya olarak tasarladığınız ve uyguladığınız sistemi düşünmenizi istiyor.

Öyleyse, (internette asla iyi gitmeyen) tartışma uğruna, bir çöp toplayıcıya OOD & P hakkında açıkladığınızı varsayalım. Onun adı Bob. 15 yıl önce onunla okula gidiyordun, bir barda ona çarptın ve ikiniz de birbirinizin hayatına ilgi duyuyorsunuz.

"Yani, John, sen bir programcı olduğunu söylüyorsun. Yeğenim tüm bu saçmalıkların içinde. Nesneye yönelik programlama ya da bir şey hakkında devam ediyor. Bu da ne hakkında?" Bob'un yanlış yazdığı yönlerden İngiliz olduğunu unutmayın.

"Şey, Bob," diye cevap veriyorsun, yönlendirerek. "Gerçekten çok basit. Çöp topladın, değil mi? Ne, genellikle işinde misin?"

"Şey, ben kasabanın etrafında çöp toplama ve minibüste koyarak minibüs takip," diye cevaplıyor Bob, merakla.

ve bunu dinlemeniz gerekecek. Bunlar bizim davranışlarımız. Tasarım için ihtiyacınız olan tek şey bu. Nesneye yönelik programlama aslında tasarımı nasıl uyguladığınızdır. Dilden dile farklılık gösterir. "

Bob birasında uyuyakaldı. Sen git.

Kalıtımın açıklanması için araba örneğini seviyorum (araçlardan ziyade hayvanları kullanma eğilimindeyim ama aynı fikir) ama nesne odaklı bir programın nasıl çalıştığını açıklamak için bir zamanlar Chris Crawford'un web sitesinde okuduğum bir benzetmeye atıfta bulunuyorum: program şöyle gerçekten verimli bir bürokrasi. Programdaki tüm farklı nesneler bir bürokrasideki farklı bölümler gibidir; her departmanın kendine özgü görevleri vardır, iyi tanımlanmış girdileri vardır (kiminle konuşulacağı ve hangi formların doldurulacağı) ve diğer departmanlar genellikle içeride neler olduğu hakkında çok fazla şey bilmezler. İK soyut bir fabrika gibidir, bu bir singleton vb.

Bir bilgisayar programına yanlış bir şey yazdığınız için bir hata mesajı almak, bir ofise göndermek için yanlış formu doldurmak gibidir.

OOP, insan düşünce sürecinin herhangi bir şeyi - bir soyutlama - ve bilindik süreçleri ve sınıflandırmaları dijital olarak taklit etmek için işlevselliği dijital bir “boşluğa” yansıtmak için dünyanın anlaşılması durumunda kaba bir sadeleştirmedir. Birçok açıdan, ilkel dil durumumuz hakkında "bilgisayar gibi düşünmekten" daha çok şey var.

Programlama gerçekliği veya insan düşüncesini taklit ederse, doğada çok daha organik, kaotik ve gelişigüzel olurdu - hatta yanal. Bunun yerine, gerçekliği bebek adımlarına, "2 + 2 mantığına", kaba kategorilere, yeniden kullanılabilir küçük araçlara ve tarih öncesi akıl yürütmeye dönüştürüyoruz.

Hala düşüncelerimizi ve arzularımızı bir protokole ve ortak dile nasıl indireceğimizi araştırmaya çalışıyoruz. Hiç de "akıllı" değil - en basit şeylere bile nasıl karar verdiğimizi veya anladığımızı nasıl kolayca açıklayamayacağımızı vurgular. Bilgi işlem hala "köpek bir köpek çünkü kedi değil" düşünce evrim düzeyindedir - temel konuşma dilinin bile binlerce yılı gerisindedir.

İki çeşit sihirbaz var. Sihirli sözlerle belirli şeyleri yapan adam var. Ateşi çağırdığı için bir sözü var. Donmuş bir tavuğu ince havadan göstermesi için bir kelimesi var. Ve çırpınan iyilikle dolu bir kuvvet potu oluşturmak için başka bir kelime (kuvvetimi yeşil, parıltılı ve yarı saydam tercih ederim). Kelimelerinin doğru uygulamasıyla kızarmış tavuk üretebilir.

Bir de OOP sihirbazı var. Kim sadece markete gitmeyi, bir tavuk (veya hazırlamasını istediğiniz diğer yiyecekler için malzemeler) almayı, pişirmeyi ve size akşam yemeği servis etmeyi bilen bir küçük çocuğu çağırır. OOP Sihirbazı, imp'sine nasıl yapılacağını söylemek zorunda değil. Sadece bu durumda kızarmış tavuk olan ne istediğini ona bildirmesi gerekiyor. Sadece bu değil, OOP sihirbazı imparatoruna ne yapacağını söylemek için diğer minyonları çağırabilir.

Yani, büyücü adam partilerde etkileyicidir, ancak OOP sihirbazı, bir sürü karakterle (örneğin, sinirli bir tek boynuzlu garson ve bir trol kat yöneticisi) sihirli bir restorana başlayacağınız zaman istediğiniz kişidir. birlikte çalışmak zorunda. "Restoran" çözme sorununun her adımını çağırmaya çalışırsanız kolayca detaylarda karışık alabilirsiniz ve hata yapmak gerçekten kolaydır. OOP sihirbazı, minyonlarını, ayrıntılarını sıralamak için önceden eğitir, böylece daha büyük problemi, halkının etkileşimde bulunmasını sağlamaya odaklanabilir.

Bahsetmemek gerekirse, ilkokul kafeterya probleminiz için şef-imp'nizi tekrar kullanmak daha kolay, o zaman sözcükleri arayarak her seferinde tek bir adım yaparken tekrar kullanabileceğiniz veya kullanamayacağınız tüm çöpleri ayırmaktır. ve diğer kelime gruplarını çağıran kelimeler (daha fazla problemle başa çıkmanız gerektiğinden daha fazla sayılacaktır).

Adil olmak gerekirse, çok, çok dikkatli bir uygulama ile, büyücü sihirbazı OOP sihirbazı kadar hızlı yapabilirsiniz. İşleri doğru şekilde parçalayabilir, böylece doğru büyüleri çağırmak, OOP sihirbazından daha fazla çalışma gerektirmez. Ancak işin anlaşılması veya çoğaltılması çok daha zordur ve büyük bölümlerini yeniden kullanmak çok daha zordur, çünkü hepsi tek bir karmaşık sorun için birbirine bağlıdır.