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

Bir kişi sıklıkla OOP'un doğal olarak insanların dünya hakkında düşündüklerine karşılık geldiğini duyabilir. Ancak bu ifadeye kesinlikle katılmıyorum: Biz (ya da en azından ben) dünyayı karşılaştığımız şeyler arasındaki ilişkiler açısından kavramlaştırıyoruz , ancak OOP'un odağı bireysel sınıfları ve hiyerarşilerini tasarlıyor.

Günlük yaşamda, ilişkilerin ve eylemlerin çoğunlukla OOP'da ilgisiz sınıfların örnekleri olabilecek nesneler arasında bulunduğunu unutmayın. Bu tür ilişkilerin örnekleri: "ekranım tablonun tepesinde"; “Ben (bir insan) bir sandalyede oturuyorum”; "bir araba yolda"; "Klavyede yazıyorum"; "kahve makinesi suyu kaynatıyor", "metin, terminal penceresinde gösterilir."

İki değerli (örneğin, "Size çiçek verdim" de olduğu gibi üç değerlikli) fiillerin fiilde bir fiil sonuç / eylem üretmek için iki nesne üzerinde işlem yapan eylem (ilişki) olduğu fiilleri olduğunu düşünüyoruz. Odak eylem ve iki (ya da üç) [gramer] nesneleri eşit öneme sahiptir.

OOP ile bir nesneyi (isim) ilk bulmanız ve başka bir nesne üzerinde bir işlem gerçekleştirmesini istemeniz ile zıtlaştırın. Düşünme biçimi, isimler üzerinde çalışan eylemlerden / fiillerden isimler üzerinde çalışan isimlere kaydırılır - sanki her şey pasif ya da yansımalı bir sesle söyleniyormuşçasına, örneğin, "metin terminal penceresi tarafından gösteriliyor". Veya belki de "metin kendini terminal penceresine çekiyor".

Odak sadece isimlere kaydırılmamış, aynı zamanda isimlerden birine (gramer konusu diyelim) diğerinden (gramer nesnesi) daha yüksek "önem" verilmiştir. Bu nedenle birinin terminalWindow.show (someText) veya someText.show (terminalWindow) diyip söylemeyeceğine karar vermesi gerekir. Fakat neden insanlar gerçekten gösterdiği zaman (terminalWindow, someText) işlemsel sonuçlara neden bu kadar önemsiz kararlar yüklüyor? [Sonuçlar operasyonel açıdan önemsiz - her iki durumda da metin terminal penceresinde gösteriliyor - ancak sınıf hiyerarşilerinin tasarımında çok ciddi olabilir ve "yanlış" bir seçim kodlamada zor ve zor olabilir.]

Bu nedenle, OOP'yi (sınıf tabanlı, tek sevkıyatlı) yapmanın ana yolunun zor olduğunu, çünkü UNNATURALAL olduğunu ve insanların dünya hakkında ne düşündüğüne uymadığını iddia ediyorum. CLOS'tan gelen genel yöntemler benim düşünme biçimime daha yakın, fakat ne yazık ki, bu yaygın bir yaklaşım değil.

Bu problemler göz önüne alındığında, şu anda OOP yapmanın ana yolunun bu kadar popüler olması nasıl / neden oldu? Ve ne, eğer bir şey olursa, onu tahttan çıkarmak için yapılabilir mi?

OOP bazı problemler için doğal değildir. Yani prosedür. Yani işlevsel. Bence OOP gerçekten zor görünecek iki sorunu var.

1. Bazı insanlar programlamanın Tek Doğru Yolu ve diğer tüm paradigmaların yanlış olduğu gibi davranırlar. IMHO herkes bir çoklu paradigma dili kullanmalı ve üzerinde çalıştıkları alt problem için en iyi paradigmayı seçmelidir. Kodunuzun bazı kısımları bir OO stiline sahip olacaktır. Bazıları işlevsel olacak. Bazıları düz bir prosedür stiline sahip olacaktır. Tecrübe ile neyin paradigmanın neye göre daha iyi olduğu belli oluyor:

   a. OO genel olarak, faaliyet gösterdikleri devlete güçlü bir şekilde bağlı davranışlarınız olduğunda ve devletin gerçek niteliği bir uygulama detayı olduğunda en iyisidir, ancak bunun varlığı kolayca ortadan kaldırılamaz. Örnek: Koleksiyonlar sınıfları.

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

   c. İşlevsel olarak, herhangi bir devletin varlığının kolaylıkla soyutlanabilecek bir uygulama detayı olacağı şekilde, bildirimsel olarak yazması oldukça kolay bir şeyiniz olduğunda en iyisidir. Örnek: Harita / Paralelliği azaltın.

2. OOP genellikle, iyi kapsüllenmiş kod parçalarına sahip olmanın gerçekten gerekli olduğu büyük projelerde faydasını gösterir. Bu başlangıç ​​projelerinde çok fazla olmuyor.

IMHO, kişisel zevkler ve düşünme biçimleri meselesidir. OO ile ilgili fazla sorunum yok.

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

IMHO bu pek de öyle değil, ancak ortak bir algı olabilir. OO teriminin mucidi Alan Kay, nesnelerin kendisinden ziyade nesneler arasında gönderilen mesajları her zaman vurgulamıştır . Ve mesajlar, en azından benim için, ilişkileri ifade ediyor.

Günlük yaşamda, ilişkilerin ve eylemlerin çoğunlukla OOP'da ilgisiz sınıfların örnekleri olabilecek nesneler arasında bulunduğunu unutmayın.

Nesneler arasında bir ilişki varsa, tanım başına, o zaman ilişkilidir. OO'da bunu iki sınıf arasında bir ilişkilendirme / toplama / kullanım bağımlılığıyla ifade edebilirsiniz.

İki değerli (örneğin, "Size çiçek verdim" de olduğu gibi üç değerlikli) fiillerin fiilde bir fiil sonuç / eylem üretmek için iki nesne üzerinde işlem yapan eylem (ilişki) olduğu fiilleri olduğunu düşünüyoruz. Odak eylem üzerindedir ve iki (veya üç) [gramer] nesnesi eşit öneme sahiptir.

Ama hala bağlamda iyi tanımlanmış rolleri var: konu, nesne, eylem vb. "Sana çiçek verdim" veya "Bana çiçek verdin" aynı değil ("Çiçek bana vermişti" deme): -)

OOP ile bir nesneyi (isim) ilk bulmanız ve başka bir nesne üzerinde bir işlem gerçekleştirmesini istemeniz ile zıtlaştırın. Düşünme biçimi, isimler üzerinde çalışan eylemlerden / fiillerden isimler üzerinde çalışan isimlere kaydırılır - sanki her şey pasif ya da yansımalı bir sesle söyleniyormuşçasına, örneğin, "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" bill.moveTo(hell)yerine program kodunu daha doğal okuyor move(bill, hell). Ve birincisi, asıl aktif sese daha benzer.

Bu nedenle, birinin terminalWindow.show (someText) veya someText.show (terminalWindow) diyip söylemeyeceğine karar vermesi gerekir.

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 problemler göz önüne alındığında, şu anda OOP yapmanın ana yolunun bu kadar popüler olması nasıl / neden oldu?

Belki de OO geliştiricilerinin çoğunluğu OO'yu sizden farklı görüyor olabilir?

Bazı programcılar OOD'yi zor buluyor, çünkü programcılar, sorunun nasıl çözüleceğini değil, bilgisayarın sorunun nasıl çözüleceğini düşünüyor.

... ancak OOP'un odağı bireysel sınıfları ve hiyerarşilerini tasarlamaktır.

OOD bununla ilgili değil. OOD, işlerin nasıl davrandığını ve etkileşimde bulunduğunu bulmakla ilgilidir.

İki değerli (örneğin, "Size çiçek verdim" de olduğu gibi üç değerlikli) fiillerin fiilde bir fiil sonuç / eylem üretmek için iki nesne üzerinde işlem yapan eylem (ilişki) olduğu fiilleri olduğunu düşünüyoruz. Odak eylem üzerindedir ve iki (veya üç) [gramer] nesnesi eşit öneme sahiptir.

OOD'ye odaklanma, eylemlerin nesnelerin davranışları olduğu her zaman eylemdedir. Nesneler, davranışları olmadan hiçbir şey değildir. OOD'un tek nesne kısıtı, her şeyin bir şey tarafından yapılması gerektiğidir.

Bir şeyi yapan şeyin o zamandan daha önemli olduğunu düşünmüyorum.

Fakat neden insanlar gerçekten gösterilince (terminalWindow, someText) operasyonel sonuçları olmayan insanlara bu kadar önemsiz kararlar yüklüyor?

Bana göre farklı bir gösterimde aynı şey. Şovun kim ve şovun kim olduğuna hala karar vermelisin. Bunu öğrendikten sonra, OOD'da karar yoktur. Windows metin göster -> Window.Show (metin).

Dışarıda bir sürü şey (özellikle eski alanda), olmadığında OO olduğunu söylüyor. Örneğin, bir OOD inciri uygulamayan çok miktarda C ++ kodu vardır.

OOD, bilgisayarlar için bir problem çözmekte olduğunuz zihniyetten kurtulduğunuzda kolaydır. İş yapan şeyler için problem çözüyorsun.

Belki, bir şey anlamadım ama:

OOP hakkındaki ilk kitabı okurken (90'ların başında, Borland'ın Pascal için ince el kitabı) Basitliği ve potansiyeli ile şaşırmıştım. (Daha önce Cobol, Fortran, Assembly dili ve diğer tarih öncesi şeyleri kullanıyordum.)

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

Diğer taraftan, programlamanın kendisi doğal değil (yani yapay). İnsan konuşması yapaydır (beni suçlama, hepimiz dillerimizi başkalarından öğrendik, hiç kimse İngilizce'yi icat eden kişiyi bilmiyor). Bazı bilim adamlarına göre, insanın zihni ilk önce öğrendiği dil tarafından oluşturulmaktadır.

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

Benim için zorlaştıran şeylerden biri, OOP'nin dünyayı modellemekle ilgili olduğunu düşünmekti. Bunu doğru yapmazsam, bir şey gelip kıçımda beni ısırır diye düşündüm (bir şey ya doğru ya da değil). Herşeyi taklit etmenin bir nesne ya da varlık olduğu sorunların farkındaydım. Bu beni OOP'ta programlama konusunda çok geçici ve güvende hissettirdi.

Sonra SICP'yi okudum ve veri tipleriyle ilgili olduğunu ve bunlara erişimi kontrol ettiğini anladım. Çözdüğüm tüm problemler, yanlış bir öncüllere dayanıyorlardı, OOP'da dünyayı modelleniyorsunuz.

Hala bu sahte öncülün bana verdiği (ve kendime nasıl bakmamı sağladığımı) verdiği büyük zorluklara hayret ediyorum.

Evet, OOP'un kendisi çok doğal değil - gerçek dünya tamamen hiyerarşik taksonomilerden oluşmuyor. Bazı küçük parçaları bu şeylerden oluşur ve bu kısımlar OO açısından yeterince ifade edilebilecek tek şeylerdir. Geri kalan her şey doğal olarak bu kadar önemsiz ve sınırlı bir düşünce tarzına uygun olamaz. Doğa bilimlerine bakın, gerçek dünyanın karmaşıklığını en basit veya en azından anlaşılabilir şekilde ifade etmek için kaç farklı matematik dilinin icat edildiğini görün. Neredeyse hiçbiri kolayca nesnelerin ve mesajların diline çevrilemez.

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

(IMO) 'dan sahte bir öncülden başlıyorsunuz. Nesneler arasındaki ilişkiler tartışmalı olarak nesnelerin kendisinden daha önemlidir. Nesneye yönelik program yapısı veren ilişkiler. Kalıtım, sınıflar arasındaki ilişki elbette önemlidir çünkü bir nesnenin sınıfı o nesnenin ne yapabileceğini belirler. Ancak, nesnenin sınıf tarafından tanımlanan sınırlar içinde gerçekte ne yaptığını belirleyen bireysel nesneler arasındaki ilişkiler ve dolayısıyla programın nasıl davrandığıdır.

Nesne yönelimli paradigma ilk başta zor olabilir, çünkü yeni nesne kategorilerini düşünmek zor değildir, ancak nesnelerin grafiğini düşünmek ve aralarındaki ilişkilerin ne olması gerektiğini anlamak zor, çünkü özellikle bu ilişkileri tanımlamanın yolu. Bu yüzden tasarım desenleri çok faydalı. Tasarım desenleri neredeyse tamamen nesneler arasındaki ilişkilerle ilgilidir. Desenler bize hem nesne ilişkilerini daha yüksek düzeyde tasarlamak için kullanabileceğimiz yapı taşlarını hem de bu ilişkileri tanımlamak için kullanabileceğimiz bir dil verir.

Aynısı, fiziksel dünyada çalışan yaratıcı alanlarda da geçerlidir. Herkes bir sürü odayı bir araya getirip bina diyebilirdi. Odalar bile en son düzenlemelerle tamamen döşenmiş olabilir, ancak bu binanın çalışmasını sağlamıyor. Bir mimarın görevi, bu odaları kullananların ve binanın çevresinin gereksinimlerine göre bu odalar arasındaki ilişkileri optimize etmektir. Bu ilişkileri doğru yapmak, bir binanın hem işlevsel hem de estetik açıdan çalışmasını sağlayan şeydir.

OOP'a alışmakta sorun yaşıyorsanız, nesnelerinizin nasıl bir araya geldiği ve sorumluluklarının nasıl düzenlendiği hakkında daha fazla düşünmenizi tavsiye ederim. Henüz yapmadıysanız, tasarım kalıplarını okuyun - muhtemelen okuduğunuz kalıpları gördüğünüzü fark edersiniz, ancak onlara ad vermeniz yalnızca ağaçları değil, aynı zamanda stantları, polisleri, çalılıkları görmenizi sağlar. ormanlar, korular, ormanlıklar ve nihayetinde ormanlar.

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

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

Modern diller (ruby / python) bu sorunla karşılaşmaz ve birinci sınıf nesneler olarak işlevler sağlar, ayrıca herhangi bir sınıf hiyerarşisi oluşturmadan programlar yapmanıza izin verir.

OOP zor değil. İyi kullanılmasını zorlaştıran şey, programcıların rastgele makbuzlar duydukları ve ilahi Çetenin kutsamaları Martin Fowler’ın kutsamalarını almak için kendilerine, nefeslerinin altında kendilerine tekrar ettikleri, başka kim okuyorlarsa.

DÜZENLENMİŞ

Öncelikle, OOP'yi hiçbir zaman zor veya başka programlama paradigmalarından daha zor bulmadığımı söylemek isterim. Programlama doğası gereği zordur çünkü gerçek dünyadaki sorunları çözmeye çalışır ve gerçek dünya son derece karmaşıktır. Öte yandan, bu soruyu okuduğumda kendime şunu sordum: OOP diğer paradigmalardan “daha ​​doğal” mı? Ve bu nedenle daha etkili?

Bir keresinde bir makaleyi buldum (keşke tekrar bulabilseydim referans olarak gönderebilseydim), zorunlu programlama (IP) ve nesne yönelimli programlama (OOP) arasındaki karşılaştırmalı bir çalışma hakkında. Farklı projelerde IP ve OOP kullanan profesyonel programcıların verimliliğini temelde ölçtüler ve sonuçta büyük farklılıklar görmediler. Dolayısıyla iddia, iki grup arasında verimlilik açısından büyük bir fark olmadığı ve gerçekte önemli olan şeyin deneyim olduğu idi.

Öte yandan, nesne yönelimi savunucuları, bir sistemin ilk gelişmesi sırasında OOP'nin zorunlu olmaktan daha fazla zaman alabildiğini, uzun vadede kodun veriler arasındaki sıkı entegrasyon nedeniyle sürdürülmesinin ve genişletilmesinin daha kolay olduğunu iddia ediyor. operasyonlar.

Genelde OOP dilleri (C ++, Java) ile çalıştım, ancak bunları büyük projeler için hiç denememiş olmama rağmen, Pascal veya Ada kullanarak üretken olabileceğimi hissediyorum.

OOP ile bir nesneyi (isim) ilk bulmanız ve başka bir nesne üzerinde bir işlem gerçekleştirmesini istemeniz ile zıtlaştırın.

[kesmek]

Bu nedenle, OOP'yi (sınıf tabanlı, tek sevkıyatlı) yapmanın ana yolunun zor olduğunu, çünkü UNNATURALAL olduğunu ve insanların dünya hakkında ne düşündüğüne uymadığını iddia ediyorum. CLOS'tan gelen genel yöntemler benim düşünme biçimime daha yakın, fakat ne yazık ki, bu yaygın bir yaklaşım değil.

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. :-)

Birden fazla nesnenin yalnızca bir mesaj yerine bir mesaj aldığı diğer OO önerileri biliyorum, yani bir mesaj alırken birkaç nesne simetrik bir rol oynamaktadır. EVET, bu bana daha genel ve belki daha doğal (daha az kısıtlayıcı) bir OOP yaklaşımı gibi geliyor.

Öte yandan, "çoklu gönderme", "tekli gönderme" kullanılarak kolayca simüle edilebilir ve "tekli gönderme" uygulaması daha kolaydır. Belki de bu, "çoklu gönderme" nin ana akım olmamasının bir nedenidir.

Sadece bir OOP paradigması aramayı bırak ve bazı JavaScript'i dene.

Şu anda, UI nesnelerimin olaya dayalı bir arabirim altında çalıştığı yerlerde çalışan bir programım var. Yani, ateş edildiğinde dahili olarak tanımlanmış bir eylemle sonuçlanan tipik bir kamu yöntemine benzeyen bir şeye sahip olacağım. Ancak kovulduğunda, gerçek olan şey, nesnenin kendisinde bir olayı tetiklemem ve o nesnenin içinde önceden tanımlanmış bir işleyicinin yanıt vermesidir. Bu olay ve başka herhangi bir dinleyiciye iletilen özellikleri ekleyebileceğiniz olay nesnesi, dinlemeye önem veren herhangi bir şey tarafından duyulabilir. Doğrudan nesneyi dinleyebilir veya bu olay türünü genel olarak dinleyebilirsiniz (olaylar, fabrika tarafından oluşturulan tüm nesnelerin dinleyebildiği genel bir nesnede tetiklenir). Mesela şimdi, açılan listeden yeni bir öğe seçtiğiniz bir seçimim var.

İsterseniz (ve genellikle istemediğimi keşfettiğimde şaşırdım - bu olayın nereden geldiğini göremediğinizde okunaklı bir meseledir) nesnenin tamamen ayrılmasını ve geçirilmiş bir olay nesnesi aracılığıyla bağlam oluşturabilirsiniz. Yine de, birden fazla yanıtlayıcıyı kaydedebilmeniz için hala tek bir gönderimden kaçıyorsunuz.

Ancak bunu yalnızca OOP ile yapmıyorum ve JS, bazı tanımlamalar ile çok komik bulduğum OOP 'düzgün' bile değil. Doğru, bence uygulama geliştirme seviyelerinin daha yüksek olması için, paradigmayı sizin durumunuz için ne işe yarayacaksa bükme gücüne sahip olmaktır ve eğer ilgilenirsek, sadece sınıfları taklit edebiliriz. Ancak bu durumda, işlevsel yönleri (geçen işleyicileri) OOP ile karıştırıyorum.

Daha da önemlisi, sahip olduklarım oldukça güçlüydü. Bir nesneye diğerine etki eden açıdan düşünemiyorum. Temel olarak nesnelerin neye değer verdiğine, bunları çözmek için ihtiyaç duydukları araçları vererek, sadece bir miksere bırakmalarını ve birbirlerine tepki göstermelerine izin veriyorum.

Sanırım söylediğim şudur: bu bir anahtar ifadesi bir sorun değil. Karıştır ve eşleştir. Sorun şu ki, herkesin aldatıcı bir şey olduğuna inanmanızı isteyen diller ve tuhaflıklar. Örneğin küçük bir java dev, OOP'yi her zaman varsayılan olarak doğru şekilde yaptıklarını düşündüklerinde OOP'yi nasıl gerçekten takdir edebilir?

Bana anlatıldığı gibi ekmek kızartma makinesi ve araba ile. Her ikisinde de yaylar var, bu yüzden bir "yay" nesnesine sahip olacaksınız ve farklı boyutlarda, güçlülüklerde ve her neyse, ama her ikisi de "yaylar" olacaktı ve sonra bu metaforu araca genişletecek, çok fazla tekerleğe sahip olsaydınız (Tekerlekler, açıkçası, direksiyon simidi, vb.)

Daha sonra programı bir nesneler listesi olarak düşünebilirsiniz ve daha sonra "Daha önce görmüş olduğunuz şeylerin bir listesi, bu yüzden daha önce gördüğünüz talimatların listesi gibi değil" görselleştirmek çok daha kolaydır.

Bence OOP ile ilgili asıl sorun insanlara nasıl anlatıldığı. Genelde (benim üniversite sınıflarımda) "Çok az şey yapan birçok sınıfla ilgili ve bunun dışında nesneler yaratabilirsin" diyerek açıklandığını görüyorum ve hepsi çok fazla insanın kafasını karıştırıyor, çünkü temelde soyut olanı kullanıyor Bu kavramları açıklamak için terimler, daha ziyade insanların 5 yaşındayken lego ile oynarken yakaladıkları somut fikirler.

Kategorizasyonla dünyayı düşünmenin doğal yolu bu. Bu, OO'nun konusu hakkında az ya da çok. OOP zor, çünkü programlama zor.

İnsanların gerçeği temsil etmek için OOP kullanmaya çalıştıklarında bazı zorlukların geldiğini düşünüyorum. Herkes bir arabanın dört tekerleği ve bir motoru olduğunu bilir . Herkes bilir arabalar can olduğunu Start(), Move()ve SoundHorn().

Her zaman bunu yapmaya çalışmaktan vazgeçmem gerektiğini anladığımda kafamda bir ışık tıkladı. Bir nesne, onunla bir isim paylaştığı şey değildir. Bir nesne, problemin kapsamı ile ilgili verilerin yeterince ayrıntılı bir bölümüdür (yani olması gerekir). Bu oughtsorunun çözümü ne fazlası ne de daha az sahip olması ihtiyacı tam olarak ne var. Bazı davranışlardan sorumlu bir nesneyi yapmak, bazı kötü üçüncü şahısların (bazılarına 'poltergeist' diyebilir) aynı davranıştan daha fazla kod satırıyla sonuçlanırsa, poltergeist fişlerini kazanır.

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

İsimlerin içindeki etkileşimleri gruplandırmamızın nedeni, iki ismin hangisiyle gruplanacağı konusunda sıkça bir belirsizlik olsa da, isimlerin miktarının yönetilebilir büyüklükteki sınıflar için işe yaramadığı, ama fiillerle gruplamanın her iki üründe de üretim yapma eğilimi gösterdiğidir. tek seferlik gibi çok küçük gruplar veya gösteri gibi bir işlev için çok büyük gruplar . Miras gibi yeniden kullanım kavramları da adlara göre gruplanırken daha kolay sonuçlanır.

Ayrıca, pencereyle mi yoksa metinle gösterip göstermeyeceğine karar verme sorunu pratikte teoride olduğundan hemen hemen her zaman daha açıktır. Örneğin, neredeyse tüm GUI araç kitleri grubu kapsayıcı ile ekler , ancak widget ile birlikte gösterilir . Başka bir şekilde kod yazmaya çalışırsanız, neden soyut olarak düşünülse de, iki yöntem birbirinin yerine geçebilir gibi görünse de neden oldukça hızlı bir şekilde görünür.

Hayır . Problama kullanarak problem çözmenin birkaç yolu vardır: İşlevsel, Prosedürel, mantıksal, OOP, diğer.

Gerçek dünyada, bazen insanlar işlevsel paradigmayı, bazen de prosedürel paradigmayı vb. Kullanırız. Ve bazen karıştırdık. Ve sonunda onları belirli bir programlama stili veya programlama paradigması olarak temsil ediyoruz.

Ayrıca LISP'de kullanılan "her şey bir liste veya bir öğedir" paradigması da vardır. İşlevsel programlamadan farklı bir şeyden bahsetmeyi seviyorum . PHP, ilişkisel dizilerde bunu kullanır.

OOP ve "Her şey bir liste ya da öğedir" paradigmaları, bazı Yapay Zeka derslerinde hatırladığım gibi , DAHA DOĞAL DOĞAL programlama stillerinin 2'sidir.

Kulağa tuhaf geliyor, "OOP doğal değil", belki de öğrenme şeklin ya da OOP hakkında öğretilme biçimin yanlış, ama OOP'un kendisi değil.

Bu problemler göz önüne alındığında, şu anda OOP yapmanın ana yolunun bu kadar popüler olması nasıl / neden oldu? Ve ne, eğer bir şey olursa, onu tahttan çıkarmak için yapılabilir mi?

OOP popüler oldu çünkü programınızı, onu izleyen popüler prosedürel dillerden daha yüksek bir soyutlama düzeyinde organize etmek için araçlar sunuyor. Metotların içinde prosedürel bir yapıya sahip bir dil ve onları çevreleyen nesne yönelimli bir yapı oluşturmak da oldukça kolaydı. Bu, prosedürel olarak nasıl programlanacağını bilen programcıların OO prensiplerini birer birer seçmelerine izin verdi. Bu aynı zamanda bir ya da iki sınıfa sarılmış prosedürel programlar olan birçok isimsiz OO programına yol açtı.

OO'dan kurtulmak için, çoğu programcının bugün bildiği şeylerden (çoğunlukla prosedürle, biraz OO ile) tercih ettiğiniz paradigmaya aşamalı olarak geçişi kolaylaştıran bir dil oluşturun. Ortak görevler yapmak için uygun API'ler sağladığından emin olun ve iyi tanıtın. İnsanlar çok yakında kendi dilinizde yalnızca X-in-programlarını yapacaklar. O zaman, insanların gerçekten X yapma konusunda iyi olmalarının yıllar ve yıllar alacağını bekleyebilirsiniz.

OOP ve OOP dillerinin de sorunları olduğunu düşünüyorum.

Düzgün bir şekilde anlarsanız, OOP üzerlerinde basılabilen düğmelere (yöntemler) sahip siyah kutular (nesneler) hakkındadır. Sınıflar sadece bu kara kutuların organize edilmesine yardımcı olmak için orada.

Bir sorun, programcının basma düğmeleri yanlış nesneye koymasıdır. Terminal kendi üzerinde metin gösteremez, metin kendi üzerinde terminal gösteremez. Bunu yapabilen işletim sisteminin pencere yöneticisi bileşeni. Terminal penceresi ve metin sadece pasif bir varlıktır. Ancak, bu şekilde düşünürsek, çoğu varlıkların pasif şeyler olduğunun farkındayız ve aslında her şeyi (veya sadece bir tane: bilgisayarı ) yapan sadece çok az sayıda nesneye sahip oluruz . Aslında C'yi kullandığınızda, onu modüller halinde düzenlersiniz, bu modüller bu az sayıda nesneyi temsil eder.

Başka bir nokta, bilgisayarın sadece talimatları sırayla yerine getirmesidir . VCRBir Televisionnesneniz olduğunu varsayalım , nasıl video oynatırsınız? Muhtemelen böyle bir şey yazarsın:

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 bu kadar basit olurdu, ama bunun için en az 3 işlemciye ( veya işlem ) ihtiyacınız olacak : biri sizin rolünüzü oynuyor, ikincisi VCR, üçüncüsü TV. Ama normalde sadece bir çekirdeğiniz var (en azından bütün nesneler için yeterli değil). Üniversitede, sınıf arkadaşlarımın çoğu, bir buton pahalı bir işlem yaptığında GUI'nin donma nedenini anlamadı.

Bu yüzden, nesne yönelimli bir tasarımın dünyayı oldukça iyi tanımlayabileceğini düşünüyorum, ancak bilgisayar için en iyi soyutlama bu değil.

Bakabilirsiniz DCI MVC deseni mucidi tarafından icat (veriler, içerik ve etkileşim).

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

• Nesnelerin (adların) üstüne sistem davranışını birinci sınıf statüde verin .
• Her ikisini de bir sınıf arayüzünde birleştirmek yerine, hızla değişen sistem davranışının (sistemin ne yaptığını), yavaşça değişen alan bilgisinin (sistemin ne olduğunu) kodundan temiz bir şekilde ayırmak.
• Sınıf düşünme tarzından ziyade insanların zihinsel modellerine yakın olan bir nesne düşünme tarzını desteklemek.

İşte yazarlar tarafından iyi bir makale ve bazı kod görmek istiyorsanız işte küçük bir örnek uygulama (.NET) . Kulabileceğinden çok daha basit ve çok doğal hissettiriyor.

Bir kişi sıklıkla OOP'un doğal olarak insanların dünya hakkında düşündüklerine karşılık geldiğini duyabilir. Ancak bu açıklamaya kesinlikle katılmıyorum (...)

Onlarca yıldır kitaplarda ve başka yerlerde anlatıldığı için ben de aynı fikirde değilim. Yine de, Nygaard ve Dahl'ın bunu yapanlar olduğunu düşünüyorum ve zamanın alternatifleriyle karşılaştırıldığında simülasyon tasarlamayı düşünmenin ne kadar kolay olduğuna odaklandıklarını düşünüyorum.

(...) ancak OOP'un odağı bireysel sınıfları ve hiyerarşilerini tasarlamaktır.

Bu iddia, OOP'nin popüler yanılgılarının ne olduğu ve OO'nun tanımı için ne kadar hassas olduğu göz önüne alındığında makul bir alana girmektedir. Sahada on yılı aşkın bir süredir hem endüstri çalışması hem de prog üzerine akademik araştırma yapıyorum. diller ve size şunu söyleyebilirim ki, "mainstream OO" yu öğrenmeden yıllarca geçirdim, çünkü önceki yaratıcıların hedeflediklerinden ne kadar farklı (ve aşağı) olduğunu fark etmeye başladım. Konunun modern, güncel bir tedavisi için W. Cook'un son çabasına değineceğim:

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

Bu problemler göz önüne alındığında, şu anda OOP yapmanın ana yolunun bu kadar popüler olması nasıl / neden oldu?

Belki aynı sebepten QWERTY klavyelerin popüler olması ya da DOS işletim sisteminin popüler olmasının nedeni aynıydı. İşler, özelliklerine rağmen popüler araçlara biniyor ve kendileri popüler oluyor. Bazen, bir şeylerin benzer ancak daha kötü versiyonları gerçek şey olarak kabul edilir.

Ve ne, eğer bir şey olursa, onu tahttan çıkarmak için yapılabilir mi?

Üstün bir yaklaşım kullanarak bir program yazın. Bir OO yaklaşımı kullanarak aynı programı yazın. Eski olanın önemli olan her yönünden daha iyi özelliklere sahip olduğunu gösterin (hem sistemin kendisinin hem de mühendislik özelliklerinin). Seçilen programın alakalı olduğunu ve önerilen yaklaşımın, diğer program türlerine uygulandığında yüksek kaliteli özellikleri sürdürdüğünü gösterin. Analizinizde titiz olun ve gerektiğinde kesin ve kabul edilen tanımları kullanın.

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

Java'yı alın: nesneler bir tür soyutlama darboğazıdır, çoğu "şey" nesnelerin kesinlikle alt bileşenleridir veya nesneleri alt bileşenleri olarak kullanırlar. Nesneler, bu iki şey arasında bir soyutlama katmanına yetecek kadar çok amaçlı olmalıdır - muti-amaç, somutlaştırdıkları tek bir metafor olmadığı anlamına gelir. Özellikle Java, kodları çağırdığınız / gönderdiğiniz tek katman nesneler (& sınıflar) yapar. Bu nesnelerin içerdiği şeyler, onları açıkçası çok fazla karmaşık kılar. Herhangi bir faydalı açıklaması bazı özel veya kısıtlanmış formlarla sınırlandırılmalıdır.

Kalıtım ve arayüz hiyerarşileri, nesneleri alt bileşenler olarak kullanan "şeyler" dir. Bu, nesnelerin genel olarak anlaşılmasını sağlamak için değil, nesneleri tanımlamanın uzmanlaşmış bir yoludur.

"Nesneler", "OO Langauge" de çok ya da daha az evrensel olan çok amaçlı bir soyutlama oldukları için birçok şeye sahip oldukları ya da oldukları söylenebilir. Yerel değişken durumu içermek ya da bazı dış dünya durumuna erişmek için kullanılıyorlarsa, o zaman bir "isim" gibi görünürler.

Buna karşılık, bir işlemi temsil eden bir nesne, örneğin "şifrelemek" veya "sıkıştırmak" veya "sıralamak", "fiil" gibi görünüyor.

Bazı nesneler isim alanı gibi rolleri için kullanılır, örneğin Java'da "statik" işlevini yerleştiren bir yer.

Java'nın nesne yöntemi çağrılarında çok ağır olduğu ve nesne üzerinde gönderme olduğu iddiasına katılmaya meyilliyim. Muhtemelen bu, gönderimi kontrol etmek için Haskell'in sınıf sınıflarını tercih etmemden kaynaklanıyor. Bu bir gönderme sınırlamasıdır ve Java'nın bir özelliğidir, ancak çoğu dilde ve hatta çoğu OO dilbilgisinde değildir.

OOP hakkında birçok çevrimiçi tartışmaya tanık oldum ve katıldım. OOP savunucuları genellikle uygun prosedür kodunun nasıl yazıldığını bilmezler. Çok modüler olan prosedür kodunu yazmak mümkündür. Kod ve verileri ayırmak ve işlevlerin yalnızca kendi veri depolarına yazabilmelerini sağlamak mümkündür. Kalıtım kavramını usul kodu kullanarak uygulamak mümkündür. Daha da önemlisi, prosedür kodu daha ince, daha hızlı ve hata ayıklaması kolaydır.

Katı adlandırma kurallarına sahip tek dosya modülleri kurarsanız, prosedür kodu OO'dan daha kolay yazılır ve bakımı yapılır; aynı veya daha fazla ve daha hızlı şekilde yapılır. Unutmayın ki, uygulamanız çalıştığında, komut dosyanızda kaç tane sınıf özelliği olursa olsun, her zaman prosedüreldir.

Öyleyse, gerçekten Nesne Yönelimli olmayan ve çoklu devralma gibi şeyleri taklit etmek için kesmek isteyen PHP gibi diller sorununa sahipsiniz. Dilin yönünü etkileyen büyük çekimler PHP'yi başlangıçta hedeflediği şey için fazla büyük olan tutarsız kurallar ekine dönüştürdü. Geliştiricilere, prosedürel bir şablonlama dili olarak tasarlanan şeyler için devasa tapınak dersleri yazarken, yardım edemem ama gülümsemem.

Doğru yazılmış bir OO kodunu kötü yazılmış bir prosedür koduyla karşılaştırırsanız, her zaman yanlış sonuca varacaksınız. Çok az sayıda proje Nesneye Yönelik bir tasarım gerektirir. IBM iseniz ve birden fazla geliştirici tarafından yıllarca sürdürülmesi gereken büyük bir projeyi yönetiyorsanız, Object Oriented'e gidin. Bir müşteri için küçük bir blog veya alışveriş sitesi yazıyorsanız, iki kez düşünün.

Orijinal soruyu cevaplamak için OOP zordur çünkü gerçek hayattaki programlama ikilemlerini olması gerekenden 100 kat daha karmaşık olan çözümlere başvurmadan çözmez. Birçok programlama problemine en güçlü çözümlerden biri, küresel verilerin makul kullanımıdır. Yine de yeni dalga üniversite mezunları size büyük bir hayır-hayır olduğunu söyleyecektir. Dünya çapında mevcut olan veriler, sadece sakar bir programlama tavşanıysanız tehlikelidir. Sıkı bir kurallar diziniz varsa ve uygun adlandırma kuralları varsa, tüm verilerinizi global olarak elde etmekten kurtulabilirsiniz.

Herhangi bir Nesne Yönelimli programcının, maksimum 16 K hafıza için bir satranç oyunu uygulamasının montajcıya nasıl yazılacağını bilmesi zorunludur. Daha sonra yağın nasıl kesileceğini, tembelliğin nasıl azaltılacağını ve ustaca çözümler üretmeyi öğreneceklerdi.