it-swarm.asia

OOP doğal olmadığı için zor mu?

Çoğu zaman OOP doğal olarak insanların dünya hakkında düşünme şekline karşılık geldiğini duyabiliriz ama bu ifadeye kesinlikle katılmıyorum: Biz (ya da en azından ben) dünyayı - ilişkiler karşılaştığımız şeyler arasında, ancak OOP odak noktası bireysel sınıfları ve hiyerarşilerini tasarlamaktır.

Günlük hayatta, ilişkilerin ve eylemlerin çoğunlukla OOP'ta ilişkisiz sınıfların örneği olabilecek nesneler arasında var olduğunu unutmayın. Bu tür ilişkilere örnekler: "ekranım tablonun üstünde"; "Ben (insan) bir sandalyede oturuyorum"; "bir araba yolda"; "Klavyede yazıyorum"; "kahve makinesi suyu kaynar", "metin terminal penceresinde gösterilir."

Fiili bazı sonuçlar/eylemler üretmek için iki nesne üzerinde çalışan eylem (ilişki) olduğu iki değerlikli (bazen üç değerlidir, örneğin "çiçek verdim" gibi) fiiller olarak düşünüyoruz. odak işlem üzerindedir ve iki (veya üç) [dilbilgisel] nesne eşit öneme sahiptir.

OOP ile ilk önce bir nesneyi (isim) bulmanız ve ona başka bir nesne üzerinde bazı eylemler gerçekleştirmesini söylemeniz gerektiğini düşünün) Düşünme şekli, isimler üzerinde çalışan eylemlerden/fiillerden isimlere kaydırılır. isimler üzerinde çalışıyor - sanki her şey pasif veya refleksif bir sesle söyleniyormuş gibi, mesela "metin terminal penceresi tarafından gösteriliyor" veya belki de "metin kendini terminal penceresine çekiyor".

Odak sadece isimlere kaydırılmakla kalmaz, aynı zamanda isimlerden birine (diyelim ki gramer konusu diyelim) diğerinden (gramer nesnesi) daha yüksek "önem" verilir. Bu nedenle birinin terminalWindow.show (someText) veya someText.show (terminalWindow) olup olmadığına karar vermesi gerekir. Ama neden bu kadar önemsiz kararları olan insanları, gerçekten bir gösteri demek olduğunda hiçbir operasyonel sonucu olmayan yükü (terminalWindow, someText)? [Sonuçlar işlevsel olarak önemsizdir - her iki durumda da metin terminal penceresinde gösterilir - ancak sınıf hiyerarşilerinin tasarımında çok ciddi olabilir ve “yanlış” bir seçim kıvrımlı ve zor olabilir kodunu korumak için.]

Bu nedenle OOP (sınıf tabanlı, tekli gönderim) yapmanın ana yolunun zor olduğunu, çünkü IS UNNATURAL ve nasıl karşılık gelmediğini) İnsanlar dünyayı düşünür CLOS'un genel yöntemleri benim düşünme şeklimize daha yakındır, ama ne yazık ki, bu yaygın bir yaklaşım değildir.

Bu problemler göz önüne alındığında, şu anda ana akım yolun OOP bu kadar popüler hale gelmesi nasıl/neden oldu? Ve bunu gidermek için ne varsa, ne yapılabilir?

86
zvrba

OOP bazı problemler için doğal değildir. Prosedürel. İşlevsel. Bence OOP gerçekten zor görünmesini sağlayan iki sorun var.

  1. Bazı insanlar programlamanın Tek Gerçek Yolu gibi davranırlar ve diğer tüm paradigmalar yanlıştır. IMHO herkes, çokdilli bir dil kullanmalı ve üzerinde çalıştıkları alt sorun için en iyi paradigmayı seçmelidir. Kodunuzun bazı bölümleri OO stiline sahip olacaktır. Bazıları işlevsel olacak, bazıları düz bir prosedür stiline sahip olacak.

    a. OO genellikle üzerinde çalıştıkları duruma güçlü bir şekilde bağlı davranışlarınız olduğunda ve durumun kesin doğası bir uygulama detayı olduğunda en iyisidir, ancak varlığı kolayca soyutlanamaz Örnek: Koleksiyon sınıfları.

    b. Herhangi bir belirli veriye güçlü bir şekilde bağlı olmayan birçok davranışınız olduğunda prosedür en iyisidir. Örneğin, belki ilkel veri türleri üzerinde çalışırlar. Burada davranışı ve verileri ayrı varlıklar olarak düşünmek en kolay yoldur. Örnek: Sayısal kod.

    c. İşlevsel en iyi, herhangi bir durumun varlığı kolayca soyutlanabilecek bir uygulama detayı olacak şekilde deklaratif olarak yazılması oldukça kolay bir şey olduğunda en iyisidir. Örnek: Paralelliğin haritalanması/azaltılması.

  2. OOP genellikle iyi kapsüllenmiş kod parçalarına sahip olmanın gerçekten gerekli olduğu büyük projelerde kullanışlılığını gösterir. Başlangıç ​​projelerinde bu çok fazla olmaz.

97
dsimcha

IMHO kişisel zevk ve düşünme biçimleri meselesidir. OO ile pek bir sorunum yok.

Biz (veya en azından ben), karşılaştığımız şeyler arasındaki ilişkiler açısından dünyayı kavramsallaştırıyoruz, ancak OOP) odağı bireysel sınıfları ve hiyerarşilerini tasarlıyor.

IMHO yaygın bir algı olsa da bu pek de öyle değil. OO teriminin mucidi Alan Kay, nesnelerin kendileri yerine nesneler arasında gönderilen mesajlar öğesini her zaman vurguladı. Ve mesajlar, en azından benim için, ilişkileri gösterir.

Günlük hayatta, ilişkilerin ve eylemlerin çoğunlukla OOP'ta ilişkisiz sınıfların örneği olabilecek nesneler arasında var olduğunu unutmayın.

Nesneler arasında bir ilişki varsa, tanım gereği birbirleriyle ilişkilidir. OO içinde, onu iki sınıf arasındaki ilişkilendirme/toplama/kullanım bağımlılığı ile ifade edebilirsiniz.

Fiili bazı sonuçlar/eylemler üretmek için iki nesne üzerinde çalışan eylem (ilişki) olduğu iki değerlikli (bazen üç değerlidir, örneğin "çiçek verdim" gibi) fiiller olarak düşünüyoruz. Odak eylem üzerindedir ve iki (veya üç) [dilbilgisel] nesne eşit öneme sahiptir.

Ama hala iyi tanımlanmış rolleri var: özne, nesne, eylem vb. "Sana çiçek verdim" ya da "Bana çiçek verdin" aynı değil ("Çiçek bana verdi" demeyin): -)

OOP ile ilk önce bir nesneyi (isim) bulmanız ve ona başka bir nesne üzerinde bazı eylemler gerçekleştirmesini söylemeniz gerektiğini düşünün) Düşünme şekli, isimler üzerinde çalışan eylemlerden/fiillerden isimlere kaydırılır. isimler üzerinde çalışıyor - sanki her şey pasif veya refleksif bir sesle söyleniyormuş gibi, mesela "metin terminal penceresi tarafından gösteriliyor" veya belki de "metin kendini terminal penceresine çekiyor".

Buna katılmıyorum. IMHO İngilizce cümle "Bill, cehenneme git" program kodunda bill.moveTo(hell) yerine move(bill, hell) olarak daha doğal bir şekilde okur. Birincisi aslında orijinal aktif sese daha analog.

Bu nedenle, birinin terminalWindow.show (someText) veya someText.show (terminalWindow) olup olmayacağına karar verilmelidir.

Yine, terminalden bir metin göstermesini istemek veya metinden terminali göstermesini istemek aynı değildir. IMHO hangisinin daha doğal olduğu oldukça açık.

Bu sorunlar göz önüne alındığında, şu anda ana akım yolun OOP) bu kadar popüler hale gelmesi nasıl/neden oldu?

Belki de OO geliştiricilerin çoğunluğu OO sizden farklı görüyor?

48
Péter Török

Bazı programcılar OOD'u zor bulur, çünkü bu programcılar sorunun nasıl çözüleceğini değil, bilgisayarın nasıl çözüleceğini düşünmeyi sever.

... ancak odak noktası OOP bireysel sınıfları ve hiyerarşilerini tasarlamaktır.

OOD bu konuda DEĞİLDİR. OOD, işlerin nasıl davrandığını ve etkileşime girdiğini bulmakla ilgilidir.

Fiili bazı sonuçlar/eylemler üretmek için iki nesne üzerinde çalışan eylem (ilişki) olduğu iki değerlikli (bazen üç değerlidir, örneğin "çiçek verdim" gibi) fiiller olarak düşünüyoruz. Odak eylem üzerindedir ve iki (veya üç) [dilbilgisel] nesne eşit öneme sahiptir.

OOD'a odaklanmak, eylemlerin nesnelerin davranışları olduğu eylem üzerinde bulunur. Nesneler davranışları olmadan hiçbir şey değildir. OOD'un tek nesne kısıtlaması, her şeyin bir şey tarafından yapılması gerektiğidir.

Yapıcıyı, bir şey yaptıklarından daha önemli görmüyorum.

Ama neden bu kadar önemsiz kararları olan insanları, gerçekten bir gösteri demek olduğunda hiçbir operasyonel sonucu olmayan yükü (terminalWindow, someText)?

Bana göre bu farklı bir gösterimle aynı şey. Hala shower'ın ve shower'ın kim olduğuna karar vermelisiniz. Bunu öğrendikten sonra, OOD'da karar yoktur. Windows metni göster -> Pencere Göster (metin).

Orada çok şey (özellikle eski alanda) diyor ki OO olmadığında. Örneğin OOD incir uygulamayan büyük miktarda C++ kodu vardır.

Bilgisayarlar için bir sorunu çözdüğünüz zihniyetten çıktıktan sonra OOD kolaydır. Bir şeyler yapan şeyler için problem çözüyorsunuz.

10
Matt Ellen

Belki, bunu anlayamıyorum, ama:

OOP (90'ların başı, Borland'ın Pascal için ince el kitabı) hakkındaki ilk kitabı okurken basitliği ve potansiyeli beni çok şaşırttı. (Daha önce Cobol, Fortran, Assembly dili ve diğerlerini kullanıyordum) tarih öncesi şeyler.)

Benim için oldukça açık: bir köpek bir hayvandır, bir hayvan yemesi gerekir, köpeğim bir köpektir, bu yüzden yemesi gerekir ...

Öte yandan, programlamanın kendisi doğal olarak doğal değildir (yani yapay). İnsan konuşması yapay (beni suçlama, hepimiz dillerini başkalarından öğrendik, kimse İngilizce icat eden kişiyi tanımıyor). Bazı bilim adamlarına göre, insanın zihni ilk öğrendiği dilden oluşur.

Kabul ediyorum, modern OO dillerindeki bazı yapılar biraz garip, ama evrim.

7
Nerevar

Benim için zorlaştıran bir şey, OOP dünyayı modellemekle ilgili olduğunu düşünüyordu. her şeyin bir nesne ya da varlık olduğunu iddia etmenin problemlerinin çok farkındaydım, bu beni OOP'ta programlama konusunda çok belirsiz ve güvensiz hale getirdi.

Sonra SICP'yi okudum ve bunun gerçekten veri türleri ve bunlara erişimi kontrol etmekle ilgili olduğunu anladım. Ertelediğim tüm problemler, yanlış bir önermeye dayandığı için, OOP içinde dünyayı modelliyorsunuz).

Hala bu sahte öncülün bana verdiği muazzam zorluğa (ve kendime nasıl baktığım) hayret ediyorum.

6
Pinochle

Biz (veya en azından ben), karşılaştığımız şeyler arasındaki ilişkiler açısından dünyayı kavramsallaştırıyoruz, ancak OOP) odağı bireysel sınıfları ve hiyerarşilerini tasarlıyor.

Yanlış bir öncül (IMO) ile başlıyorsunuz. Nesneler arasındaki ilişkiler muhtemelen nesnelerin kendisinden daha önemlidir. Nesneye yönelik bir program yapısı veren ilişkilerdir. Kalıtım, sınıflar arasındaki ilişki elbette önemlidir, çünkü bir nesnenin sınıfı o nesnenin ne yapacağını belirler can. Ancak, sınıf tarafından tanımlanan sınırlar içinde bir nesnenin ne olduğunu aslında yaptı ve dolayısıyla programın nasıl davrandığını belirleyen nesneler arasındaki ilişkilerdir.

Nesneye yönelik paradigma ilk başta zor olabilir, çünkü yeni nesne kategorilerini düşünmek zor değildir, ancak bir nesne grafiği tasavvur etmek ve aralarındaki ilişkilerin ne olması gerektiğini anlamak, özellikle de bu ilişkileri tanımlamanın bir yolu. Tasarım kalıplarının bu kadar faydalı olmasının nedeni budur. Tasarım kalıpları neredeyse tamamen nesneler arasındaki ilişkilerle ilgilidir. Desenler bize hem nesne ilişkilerini daha yüksek bir seviyede tasarlamak için kullanabileceğimiz yapı taşlarını hem de bu ilişkileri tanımlamak için kullanabileceğimiz bir dil verir.

Aynı şey fiziksel dünyada çalışan yaratıcı alanlarda da geçerlidir. Herkes bir grup odayı bir araya getirip ona bina diyebilir. Odalar bile en son teçhizat ile tamamen döşenmiş olabilir, ama bu bina işe yaramaz. Bir mimarın işi, bu odaları kullanan insanların ihtiyaçları ve binanın çevresi açısından bu odalar arasındaki ilişkileri optimize etmektir. Bu ilişkileri doğru yapmak, bir yapıyı hem işlevsel hem de estetik açıdan yapan şeydir.

OOP'ye alışmakta güçlük çekiyorsanız, nesnelerinizin birbirine nasıl uyduğu ve sorumluluklarının nasıl düzenlendiği hakkında daha fazla düşünmenizi öneririm. Henüz yapmadıysanız, tasarım desenleri hakkında bilgi edinin - muhtemelen okuduğunuz desenleri zaten gördüğünüzü fark edeceksiniz, ancak onlara isim vermek sadece ağaçları değil, aynı zamanda standları, polisleri, çalılıkları, ormanlar, korular, ormanlar ve nihayetinde ormanlar.

4
Caleb

Evet, OOP kendisi çok doğal değil - gerçek dünya tamamen hiyerarşik taksonomilerden yapılmıyor.Bazı küçük kısımları bu şeylerden oluşuyor ve bu parçalar yeterince yeterli olabilecek tek şey Geri kalan her şey doğal olarak bu kadar önemsiz ve sınırlı bir düşünme biçimine sığamaz.Genel bilimlere bakın, en basit veya en azından anlaşılabilir olarak ifade etmek için kaç farklı matematiksel dil icat edildiğine bakın. ve neredeyse hiçbiri kolayca bir nesne ve mesaj diline çevrilemez.

4
SK-logic

DÜZENLENMIŞ

Her şeyden önce şunu söylemek isterim ki OOP diğer programlama paradigmalarından daha zor veya daha zor bulamadım. Programlama doğal olarak zordur çünkü gerçek dünyadan ve gerçek dünyadan sorunları çözmeye çalışır Öte yandan, bu soruyu okuduğumda kendime sordum: OOP "diğer paradigmalardan" daha doğal "ve bu nedenle daha etkili mi?

Bir keresinde, zorunlu programlama (IP) ve nesne yönelimli programlama (OOP) arasındaki karşılaştırmalı bir çalışma hakkında bir makale buldum (keşke tekrar bulabilmeyi diliyorum). Temelde IP ve OOP kullanarak farklı projelerde profesyonel programcıların verimliliğini ölçtüler ve sonuçta büyük farklılıklar görmedikleri için iddia, büyük bir fark olmadığıydı. iki grup arasındaki verimlilik ve gerçekten önemli olan deneyimdir.

Öte yandan, nesne yönelimi taraftarları, bir sistemin erken gelişimi sırasında OOP zorunlu olandan daha fazla zaman alabilir, ancak uzun vadede kodun korunmasının daha kolay olduğunu ve veri ve işlemler arasındaki sıkı entegrasyon nedeniyle genişletilebilir.

Ben esas olarak OOP dilleri (C++, Java) ile çalıştım ama genellikle büyük projeler için hiç denemedim bile Pascal veya Ada kullanarak üretken olabileceğini hissediyorum.

Bunun ilk önce bir nesne (isim) bulmanız ve ona başka bir nesne üzerinde işlem yapmasını söylemeniz OOP ile kontrast).

[kesme]

Bu nedenle OOP (sınıf tabanlı, tekli gönderim) yapmanın ana yolunun zor olduğunu, çünkü IS UNNATURAL ve nasıl karşılık gelmediğini) İnsanlar dünyayı düşünür CLOS'un genel yöntemleri benim düşünme şeklimize daha yakındır, ama ne yazık ki, bu yaygın bir yaklaşım değildir.

Bu son paragrafı daha dikkatli okuduğumda nihayet sorunuzun ana noktasını anladım ve cevabımı sıfırdan yeniden yazmak zorunda kaldım. :-)

Biliyorum diğer OO burada birden çok nesne bir yerine bir mesaj alır, yani birkaç nesne bir mesaj alırken simetrik bir rol oynar. EVET, bu daha genel ve belki daha doğal görünüyor ( daha az kısıtlayıcı) OOP bana yaklaşım.

Diğer yandan, "çoklu gönderim", "tek gönderim" kullanılarak kolayca simüle edilebilir ve "tek gönderim" uygulaması daha kolaydır. Belki de "çoklu dağıtım" ın ana akım haline gelmemesinin bir nedeni budur.

3
Giorgio

OOP zor değil. İyi kullanılmasını zorlaştıran şey, programcıların rastgele maksimumları duydukları ve ilahi Dörtlü Çetenin, mübarek Martin Fowler'ın kutsamalarını almak için onları kendi nefesleri altında tekrar ettikleri için iyi bir şey olduğunu gösteren sığ bir anlayıştır. başka kim okuyorlarsa.

3
Marcin

Bu, OOP ile ilgili sorunların sadece bir kısmı.

Esasen, işlevler ikinci sınıf vatandaş olur ve bu kötüdür.

Modern diller (Ruby/python) bu soruna maruz kalmaz ve birinci sınıf nesneler olarak işlevler sağlamanın yanı sıra herhangi bir sınıf hiyerarşisi oluşturmadan programlar yapmanıza izin verir.

3
hasen

Yalnızca OOP paradigmasını aramayı bırakın ve JavaScript kullanmaya çalışın.

Şu anda UI nesnelerimin olay güdümlü bir arayüz altında çalıştığı bir şema çalıştım. Yani, işten çıkarıldığında dahili olarak tanımlanmış bir eylemle sonuçlanan tipik bir genel yönteme benzeyeceğim. Ancak kovulduğunda, gerçekten olan şey, nesnenin kendisinde bir olayı tetiklemem ve bu nesnenin içindeki önceden tanımlanmış bir işleyicinin yanıt vermesidir. Bu olay ve diğer dinleyicilere aktarılan özellikleri ekleyebileceğiniz olay nesnesi, dinlemeyi önemseyen her şey tarafından duyulabilir. Doğrudan nesneyi dinleyebilir veya genellikle bu olay türünü dinleyebilirsiniz (olaylar fabrika tarafından oluşturulan tüm nesnelerin dinleyebileceği genel bir nesne üzerinde de tetiklenir). Şimdi örneğin, açılır listeden yeni bir öğe seçtiğiniz bir birleşik giriş kutum var. ComboBox, kendi görüntüleme değerini ayarlamak ve gerekiyorsa sunucuyu güncellemek için ne yapılacağını bilir, ancak geçerli değerine bağlı olan seçme listelerini değiştirmek için dinlerken istediğim kadar başka birleşik kutuya da sahip olabilirim. ilk birleşik giriş kutusu.

İsterseniz (ve genellikle istemediğimi keşfetmeye şaşırdım - olayın nereden geldiğini göremediğinizde bir okunabilirlik sorunu), tam bir nesne ayrıştırma işlemine sahip olabilir ve geçirilen bir olay nesnesi aracılığıyla bağlam oluşturabilirsiniz. Her şeye rağmen, birden fazla yanıtlayıcı kaydederek tek bir gönderimden kaçıyorsunuz.

Ama bunu sadece OOP ile yapmıyorum ve JS komik bulduğum bazı tanımlarla 'düzgün' OOP bile değil. Bence, uygulama geliştirmenin daha yüksek seviyeleri için, durumunuz için işe yarayan her şeye paradigmayı bükme gücüne sahip olmak ve eğer ilgilenirsek sınıfları taklit edebiliriz. Ancak bu durumda, işlevsel (işleyenleri işleyen) yönlerini OOP ile karıştırıyorum.

Daha da önemlisi, sahip olduğum şey oldukça güçlü geliyor. Bir nesnenin diğerine etki etmesi açısından düşünmüyorum. Temelde nesnelerin neye önem verdiğine karar veriyorum, onlara işleri çözmek için ihtiyaç duydukları araçları veriyorum ve sadece bir miksere bırakıp birbirlerine tepki vermelerine izin veriyorum.

Demek istediğim şu: Bu bir switch deyimi gibi bir sorun değil. Karıştır ve eşleştir. Sorun uber alles bir şey olduğuna inanmanızı isteyen diller ve fads. Örneğin bir genç Java dev, varsayılan olarak her zaman düzgün bir şekilde yaptıklarını düşündüklerinde OOP'i gerçekten takdir edebilir mi?

3
Erik Reppen

Sanırım insanlar gerçeği temsil etmek için OOP kullanmaya çalıştığında zorlukların bir kısmı geliyor. Herkes bilir bir otomobilin dört tekerleği ve bir motoru olduğunu. Herkes bilir arabaların Start(), Move() ve SoundHorn() yapabileceğini bilir.

Bunu yapmaya çalışmayı bırakmam gerektiğini fark ettiğimde kafamda bir ışık tıkladı. Bir nesne bir ismi paylaştığı şey değildir. Bir nesne, sorunun kapsamıyla ilgili verilerin yeterince ayrıntılı bir bölümüdür (yani olmalıdır). Soruna çözümün tam olarak neye ihtiyacı olduğunu, daha fazla ve daha az değil ought. Bir nesneyi bazı davranışlardan sorumlu kılmak, aynı davranışın bazı belirsiz üçüncü tarafların (bazıları 'poltergeist' olarak adlandırılabilir) işinden daha fazla kod satırıyla sonuçlanırsa, poltergeist fişlerini kazanır.

2
Tom W

Bana açıklanma şekli ekmek kızartma makinesi ve araba ile oldu. Her ikisinin de yayları var, bu yüzden bir "yay" nesnesine sahip olacaksınız ve farklı boyutlar, güçler ve her neyse, ama her ikisi de "yaylar" olacak ve daha sonra bu metaforu araca genişleteceklerdi, (Tekerlekler, tabii ki, artı direksiyon simidi, vb) ve bu çok mantıklıydı.

Daha sonra programı bir nesne listesi olarak düşünebilirsiniz ve o zaman "Bu bir şeyler yapan şeylerin bir listesi, bu yüzden daha önce gördüğünüz talimatlar listesi gibi değil" görselleştirmek çok daha kolay.

Ben OOP ile asıl sorun insanlara nasıl açıklanır olduğunu düşünüyorum. Genellikle (benim uni sınıflarım) "Bu küçük şeyler yapan birçok sınıf hakkında ve bunun dışında nesneler oluşturabilir "ve her şey birçok insanı karıştırır, çünkü bu kavramları açıklamak için temel olarak soyut terimleri kullanmakta, insanların 5 yaşında lego ile oynarken kavradığı somut fikirlerden ziyade.

2
Trezoid

Dünyayı kategorizasyon yoluyla düşünmenin doğal yolu budur. Aşağı yukarı bu OO hakkında.) OOP zor çünkü programlama zor.

2

Hayır. Programlama kullanarak bir problemi çözmenin birkaç yolu vardır: fonksiyonel, Prosedürel, mantıksal, O.O.P., diğer.

Gerçek dünyada, bazen insanlar fonksiyonel paradigmayı kullanırlar, bazen de prosedürel paradigmayı kullanırız vb. Bazen karıştık. Ve sonunda onları belirli bir programlama tarzı veya paradigması olarak temsil ediyoruz.

LISP'de kullanılan "her şey bir liste veya bir öğe" paradigması da vardır. İşlevsel programlamadan farklı bir şey olarak bahsetmek istiyorum. PHP bunu ilişkilendirilebilir dizilerde kullanır.

O.O.P. ve "Her şey bir liste veya öğedir" paradigmaları bazı Yapay Zeka sınıflarında hatırladığım gibi DAHA FAZLA DOĞAL programlama stilinden 2 tanesidir.

Bana garip geliyor, "O.O.P. doğal değil", belki de öğrenme şekliniz ya da O.O.P. yanlış, ama O.O.P. kendisi.

1
umlcat

OOP ve OOP dillerinde de sorun var.

Eğer doğru anlarsanız, OOP üzerinde itilebilir düğmeler (yöntemler) olan kara kutular (nesneler) hakkındadır.Sınıflar sadece bu kara kutuları düzenlemek için var.

Bir sorun programcı Push düğmelerini yanlış nesneye koyduğundadır. Terminal kendi üzerinde metin gösteremez, metin kendini terminalde gösteremez. İşletim sisteminin bunu yapabilen pencere yöneticisi bileşeni. Terminal penceresi ve metin sadece pasif bir varlıktır. Ancak bu şekilde düşünürsek, çoğu varlığın pasif şeyler olduğunu ve aslında her şeyi yapan (ya da sadece bir: bilgisayar) çok az nesneye sahip olduğumuzu fark edersek. Gerçekten de C'yi kullandığınızda, modüller halinde düzenlersiniz, bu modüller bu kadar az nesneyi temsil eder.

Başka bir nokta da bilgisayar talimatları sırayla yürütür. Bir VCR ve Television nesneniz olduğunu varsayalım, nasıl video oynatırsınız? Muhtemelen böyle bir şey yazıyorsunuz:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

Bu basit olurdu, ancak bunun için en az 3 işlemciye (veya işlemler) ihtiyacınız olacak: biri sizin rolünüzü oynar, ikincisi VCR'dir, üçüncüsü TV'dir. Ancak normalde sadece bir çekirdeğiniz vardır (en azından tüm nesneleriniz için yeterli değildir). Üniversitede, sınıf arkadaşlarımın çoğu, bir Push düğmesi pahalı bir işlem yaptığında GUI'nin neden dontuğunu anlamadı.

Bence nesne yönelimli bir tasarım dünyayı oldukça iyi tanımlayabilir, ancak bu bilgisayar için en iyi soyutlama değildir.

1
Calmarius

Karmaşıklığı yönetmek için işlevselliği modüller halinde gruplandırmamız gerekir ve bu genel olarak zor bir sorundur. Kapitalizm hakkındaki eski söz gibi, OOP, denediğimiz her şey hariç, orada yazılımı düzenlemek için en kötü sistemdir.

İsimler içindeki etkileşimleri gruplandırmamızın nedeni, iki isimden hangisini gruplayacağı konusunda sık sık bir belirsizlik olsa da, isimlerin miktarının yönetilebilir büyüklükteki sınıflar için işe yaraması, fiillerin gruplandırılması ise tek seferlik gibi çok küçük gruplar veya göster gibi bir işlev için çok büyük gruplar. İsimlerle gruplandırırken, miras gibi yeniden kullanım kavramları da çok daha kolay çalışır.

Ayrıca, pencereye veya metne show koyup koymamaya karar verme sorunu pratikte teoride olduğundan neredeyse çok daha açıktır. Örneğin, kapsayıcıyla neredeyse tüm GUI araç setleri grubu add, ancak widget ile show. Kodu başka bir şekilde yazmaya çalışırsanız, iki yöntem birbirinin yerine geçebilir gibi görünse de, neden oldukça hızlı bir şekilde ortaya çıkar.

1
Karl Bielefeldt

Bu problemler göz önüne alındığında, şu anda ana akım yolun OOP bu kadar popüler hale gelmesi nasıl/neden oldu? Ve bunu gidermek için ne varsa, ne yapılabilir?

OOP popüler oldu, çünkü programınızı, kendisinden önceki popüler prosedür dillerinden daha yüksek bir soyutlama düzeyinde organize etmek için araçlar sunuyor. Yöntemlerin içinde prosedürel yapıya sahip bir dil ve onları çevreleyen nesne yönelimli yapı yapmak da nispeten kolaydı. Bu, prosedürel olarak nasıl programlanacağını zaten bilen programcıların OO ilkeleri teker teker almasına izin verir, bu da bir sınıf içinde örtülü yordamsal programlar olan çok sayıda yalnızca OO programına yol açtı. ya da iki.

OO'yu tahttan indirmek için, çoğu programcının bugün bildiklerinden (çoğunlukla prosedürel, küçük bir OO ile) tercih ettiğiniz paradigmaya kademeli olarak geçişi kolaylaştıran bir dil oluşturun. Ortak görevleri yerine getirmek için uygun API'ler sağladığından emin olun ve iyi tanıtın. İnsanlar yakında kendi dilinizde sadece X-in-name programları yapacaklar. O zaman insanların aslında X yapmakta iyi olmaları yıllar ve yıllar alabilir.

1
Sean McMillan

MVC modelinin mucidi tarafından icat edilen DCI (veri, bağlam ve etkileşim) 'e bir göz atın.

DCI'nin amacı (Wikipedia'dan alıntılanmıştır):

  • Sistem davranışını birinci sınıf duruma, nesnelerin üstüne (isimler) verin.
  • Hızla değişen sistem davranışını (sistemin yaptığı) yavaşça değişen alan bilgisini (sistemin ne olduğunu) koddan, her ikisini de tek bir sınıf arabiriminde birleştirmek yerine koddan temiz bir şekilde ayırmak.
  • Sınıf düşünce biçiminden ziyade, insanların zihinsel modellerine yakın olan bir nesne düşünce biçimini desteklemek.

İşte bir yazarlar tarafından iyi bir makale ve burada bir kod görmek istiyorsanız küçük örnek uygulama (.NET) . Göründüğünden çok daha basit ve çok doğal geliyor.

0
Sire

Sıklıkla duymak mümkün OOP doğal olarak insanların dünya hakkında düşünme şekline karşılık gelir. Ama bu ifadeye kesinlikle katılmıyorum (...)

On yıllardır kitaplarda ve başka yerlerde evanjelleştirildiği için ben de buna katılmıyorum. Bununla birlikte, bence Nygaard ve Dahl bunu böyle yapanlardır ve bence zamanın alternatifleriyle karşılaştırıldığında simülasyon tasarlamanın ne kadar kolay olduğuna odaklanıyorlardı.

(...) ancak OOP) odağı tek tek sınıflar ve bunların hiyerarşilerini tasarlamaktır.

Bu iddia, OOP popüler yanılgılarının ne kadar hassas olduğu ve OO tanımının ne kadar hassas olduğu göz önüne alındığında) mantıklı bir alana girer. Sahada on yıldan fazla süredir var hem endüstri çalışması hem de program dilleri üzerine akademik araştırmalar ve size "ana akım OO" nun öğrenimini çözmek için uzun yıllar harcadığımı söyleyebilirim, çünkü önceki içerik oluşturucuların amaçladığı şeyden ne kadar farklı (ve daha aşağı) olduğunu fark etmeye başladım. konunun güncel tedavisi W. Cook'un son çabasına atıfta bulunacağım:

"" Nesne "ve" Nesneye Yönelik "Basitleştirilmiş, Modern Tanımlar için Bir Öneri http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

Bu sorunlar göz önüne alındığında, şu anda ana akım yolun OOP) bu kadar popüler hale gelmesi nasıl/neden oldu?

Belki de aynı neden QWERTY klavye popüler hale geldi veya DOS işletim sistemi popüler hale geldi aynı sebep.İşler özelliklerine rağmen popüler araçlara biniyor ve kendileri de popüler oluyor. bir şeyin benzer ama daha kötü sürümleri asıl şey olarak alınır.

Ve bir şey varsa, tahttan indirmek için ne yapılabilir?

Üstün bir yaklaşım kullanarak bir program yazın. Aynı programı bir OO yaklaşımını kullanarak yazın. Birincisinin önemli olan her yönüyle ikincisinden daha iyi özelliklere sahip olduğunu göster (sistemin kendisinin özellikleri ve mühendislik özellikleri). ilgili yaklaşımdır ve önerilen yaklaşım, diğer program türlerine uygulandığında yüksek özelliklerin kalitesini korur Analizinizde titiz olun ve gerektiğinde kesin ve kabul edilen tanımları kullanın.

Son olarak, bulgularınızı bizimle paylaşın.

0
Thiago Silva