Fiziksel gerçek dünya nesnelerine başvurmadan OO'yu nasıl öğretebiliriz? [kapalı]

Bir yerde, OO'nun arkasındaki orijinal kavramların, birden çok sistem arasındaki veri mesajlarını bu verilerin durumunu koruyacak şekilde işlemek için daha iyi bir mimari bulmak olduğunu okuduğumu hatırlıyorum. Şimdi bu muhtemelen zayıf bir açıklamadır, ancak (Bisiklet, Araba, Kişi vb.) Nesne analojileri olmadan OO öğretmenin bir yolu olup olmadığını merak ettim ve bunun yerine mesajlaşma yönlerine odaklanıyor. Makaleleriniz, bağlantılarınız, kitaplarınız vb. Varsa, bu yardımcı olacaktır.

Orijinal OO kavramının bugünün OO'su ile bir ilgisi yoktur. (Bkz. Peki * Alan Kay "nesne yönelimli" terimiyle gerçekten ne demekti? ). Günümüzün nesne yönelimli programlaması, bisikletlerin, evlerin ve insanların metaforları vb. Korelasyonu görmelerine yardımcı olun ve sonra OO hakkında daha derin şeylere daldıklarındaki farkları görmelerine yardımcı olun.

EDIT: Bugünün OO özellikleri ve yetenekleri tamamen / kısmen çeşitli yöntemler (işlevler) ve öznitelikleri (referanslar AKA değişkenleri ve sabitler) kullanılarak açıklanan tamamen bağımsız nesneler oluşturmak ile ilgilidir.

Bağlanma ve uyum kavramları hakkında konuşabilirsiniz. Nesneler, yüksek kohezyon ve dolaylı olarak yüksek bağlanma özelliklerine ve yöntemlerine sahip olmalıdır. Sistemin çalışması için gereken en küçük işlemlerle ve özniteliklerle eşleşmelidirler. Ayrıca, kodu mümkün olduğunca küçük ve açık tutma arzusunu da yerine getirmelidirler, yani bakım ve genişletilebilirlik göz önünde bulundurularak kodlama.

Bu aynı zamanda yaygın nesneler olan "nesne patlaması", aşırı genelleme ve yanlış metafor seçimini de önler.

Gerçek dünyadaki nesnelere ve mesajlaşmaya da odaklanmam. Daha ziyade kullandığım bir örnek, "kendilerini nasıl çizeceğini bilen" nesnelerin olmasını istediğiniz grafiklerde.

Örneğin, OO yerleşik olmayan C'de çalışıyorsanız, işaretçileri veri nesnelerinin içindeki işlevlere depolamayı uygun bulabilirsiniz. Bunu yaparsanız, OOP'a giriyorsunuz.

Alan Kay'a Musa'nın tabletleri teslim ediyormuş gibi bahsetmekten hoşlanmıyorum. Aksine, matematik ve biyoloji eğitimi almış olduğuna inanıyorum. Bir matematikçi olarak, muhtemelen oldukça soyut olan ve donanımla ilgili olmayan Lambda Calculus'a aşinalığa sahipti. LC'de her şeyin bir "nesne" olduğunu söyleyebilirsiniz - 0 sayısı ve 1 sayısı gibi, bir argüman verildiğinde farklı şeyleri değerlendiren nesnelerdir. Bu Smalltalk'a oldukça hoş bir şekilde yol açar. "Mesaj" fikri donanım hakkında konuşmaktan kaçınabilmemizdir. Bir işlevi (veya bir nesnenin yöntemini) çağırdığınızda ona bir mesaj gönderdiğinizi ve geri döndüğünde size (veya devamınıza) bir mesaj gönderdiğini söyleyebilirsiniz. Bu, ayrı bir donanımda eşzamansız olarak çalışan programlar arasında iletişim kurma yollarını açıklamanın bir yolu olarak kilitlendi. Bu iyi, ama sıradan programlama için bu işlem ortadan kalkıyor. OOP fikrinin değerini elde etmek için, yapmaya çalıştığınız somut görevin önemini ya da üzerinde çalıştığınız donanımın somutluğunu reddetmeniz gerekmez. OOP hakkında tartışmalı analojiler açısından öğretmenin, veri tasarımı açısından yazılım tasarımını çok fazla düşünmesine yol açtığını düşünüyorum, aşırı tasarımına yol açıyor, kod patlamasına ve büyük performans sorunlarına yol açıyor. yeterince kötüleşiyor.

Bir örnek için fiziksel bir nesne kullanma ve örnek olarak fiziksel olmayan bir nesne kullanma konusunda çok az fark olduğunu iddia ediyorum. Kod olarak her ikisi de aynı parçalara sahiptir. Grafik örneğini kullanır ve Küre, küp, silindir ile öğretirsek, top, kutu, kutup kullanmakla neredeyse aynıdır.

Bu yüzden fiziksel örnekler kullanmadan öğretmek için hiç örnek kullanmamanızı öneririm, ama neden fiziksel örnekler istemeyeceğinizi anlamıyorum, bu yüzden konu hakkındaki tutumum

Hayır, bunu fiziksel gerçek dünya nesneleri olmadan öğretmemelisiniz

Gerçek dünya metaforlarına başlamaktan nasıl kaçınabileceğinizi görmüyorum , ama orada kalmak istemezsiniz . OOP'u doğru yapıyorsanız, hızlı bir şekilde soyutlaşır, ancak bir sonraki anlayış düzeyinde, öğrenci nesneleri nesne olarak anlamalıdır.

İlginçtir ki en sevdiğim örneklerimden bazıları fiziksel nesneler değil. Örneğin Banka Hesabını ele alalım. Herkes, bakiyenin değerini değiştirmek ve servis ücretini almayı hatırlamak yerine arama koduna güvenmek yerine, depozito () ve pulldraw () 'in neden hizmet ücretini alması gerektiğini "alır". Ekrandaki şekiller iki kat somut değildir ve Stroustrup bana klasik "Şekiller" örneğinin 40 yıl öncesine ait bildiği en eski iki OO örneğinden biri olduğunu söyledi (diğeri şimdi 44 yaşında olan araçlar).

Önemli olan, insanların örneklerinizi hemen anlamalarıdır. Asansörler sadece asansöre aşina olan insanlara iyi bir örnektir. Vb.

Bir programlama grubundaysanız, birkaç kişiyi bir araya getirin ve sisteme ne yapmanız gerektiğini yapmak için birbirlerine nasıl söyleyeceğinizi tartışmaya başlayın. Kelimenin tam anlamıyla sistemde rol al (bunu her rolü oynayarak kendi başına yapabilirsin, ama bir grup insanla daha kolay. Sahip oldukları verilere değil, her bir kişinin ne yaptığına / yapacaklarına odaklanın. Bunu insanlarla yapmak, mesajlara ve rollere odaklanmaya yardımcı olur, çünkü insanlar ne yaptıklarını hatırlıyorlar, ancak sahip oldukları verileri hatırlamıyorlar.

Birbirinden ne yapman gerektiğini sorman gerektiğini ve bunu yapmak için hangi bilgilere ihtiyacın olduğunu not al. Başka bir programcı verilerinizi hayır deyin diye sorarsa ve neden ona ihtiyaç duyduğunu sorarsa (verilerin kapsüllenmesine yardımcı olur) kendi verilerinizi koruyun.

Ben aşağıdan yukarıya / metal bir yaklaşım yararlı olabilir düşünüyorum. Öncelikle, doğrudan ilkelleri kullanmak yerine verilerin nasıl yapılandırılabileceğini göstermek için C tarzı yapıları ve işaretçileri açıklayın. Sonra geç bağlama ve fonksiyon göstergelerini açıklayınız. Daha sonra bunları temelde iyi kapsüllenmiş veri yığınları ve adı geçen veriler üzerinde çalışması için gereken işlevlere işaret eden nesneler oluşturmak için kullanabileceğinizi açıklayın.

Bu açıklama, kavramın uygulamadan bağımsız olarak öğretilmesinin geleneksel matematik / comp-sci yoluyla çelişmektedir, ancak beni (kuşkusuz bir compi sci, arka planı olmayan bir mühendisliğe sahip biri) sonunda OO elde eden perspektiftir.