Nesne yönelimli programlamanın avantajları [kapalı]

Not : Bu soru, birkaç ay önce yazdığım bir blog gönderisinden düzenlenmiş bir alıntıdır . Bloga bir link yerleştirdikten sonra Programcılar hakkında bir yorumda bulun. Birisi burada bir soru göndermemi istedi, böylece cevaplayabilsinler. Bu gönderi en popüler olanı çünkü insanlar Google’a "nesne odaklı programlama yapmıyorum" yazıyor . Burada veya Wordpress'teki bir yorumda cevap vermekten çekinmeyin.

Nesneye yönelik programlama nedir? Kimse bana tatmin edici bir cevap vermedi. Sanırım etrafta dolaşan, “nesne” ve “nesne yönelimli” diyerek, burnu havadayken iyi bir tanım alamayacağınızı hissediyorum. Nesneye yönelik programlama dışında hiçbir şey yapmayan birinden de iyi bir tanım elde edemezsiniz. Hem prosedürel hem de nesne yönelimli programlamayı anlayan hiç kimse bana nesne yönelimli bir programın gerçekte ne yaptığı konusunda tutarlı bir fikir vermedi.

Birisi lütfen bana nesne yönelimli programlamanın avantajları hakkında fikirlerini verebilir mi?

Yazılımı, bilgisayarın içinde bulunan bir makine veya montaj hattı olarak düşünün. Bazı hammaddeler ve bileşenler makineye beslenir ve bunları nihai ürün olarak işlemek için bir dizi prosedür izler. Prosedürler, belirli bir sırada belirli bir parametre setine (örneğin zaman, sıcaklık, mesafe vb.) Bazı hammadde veya bileşen üzerinde belirli bir işlemi gerçekleştirmek üzere ayarlanmıştır. Gerçekleştirilecek işlemin detayları yanlışsa veya makinenin sensörleri doğru şekilde kalibre edilmemişse veya bazı hammaddeler veya bileşenler beklenen kalite standartlarında değilse, işlemin sonucunu değiştirebilir ve ürün ortaya çıkmaz beklenildiği gibi.

Böyle bir makine çalışması ve kabul edilebilir girdiler konusunda çok katıdır. Makineler tasarımcıların zekasını ve mevcut çalışma ortamını sorgulamıyor. Yönettiği sürece prosedürleri takip etmeye devam edecektir. Hammaddelerde veya bileşenlerde yapılan bir değişiklik, daha sonraki işlemlerde ne olduğu üzerinde çarpıcı bir etkiye sahip olsa bile, makine yine de işlemlerini yerine getirir. İstenen sonucu telafi etmek ve üretmek için prosedürlerde hangi değişikliklerin yapılması gerektiğini görmek için sürecin gözden geçirilmesi gerekir. Ürünün tasarımında veya yapılandırmasında bir değişiklik yapılması, gerçekleştirilen işlemlerde veya siparişlerinde önemli bir değişiklik gerektirebilir. Üretimden sorumlu olanlar, bunlar arasındaki istenmeyen etkileri azaltmak için izolasyon işlemlerinin mümkün olduğunca çabuk önemini öğrenmiş olsalar da, Bileşenlerin işlemden geçirildiği haliyle şartların bir sürü varsayımı yapılır; nihai ürün kullanıcının bazı farklı çalışma ortamlarında bulunmadığı sürece tespit edilemeyecek varsayımlar.

Prosedürel programlama böyle bir şey.

Nesne yöneliminin sağladığı şey, bileşenlerin koşullarının varsayımlarını ortadan kaldırmanın bir yoludur; bu nedenle, bu bileşen üzerinde gerçekleştirilecek işlemler ve nihai ürüne nasıl dahil edileceği. Başka bir deyişle, OOP, belirli bir bileşenle ilgilenmek için işlem ayrıntılarını almak ve bunu yapmak için daha küçük bir makineye vermek gibidir. İşlemden sorumlu olan daha büyük makine, hangi işlemin yapılmasını beklediğini gösteren bileşene özgü makineye bildirir, ancak adımlar için ayrıntıları işleme tabi olan makineye bırakır.

Nesne yöneliminin, nesne yönelimli olmayan yazılımlara göre avantajları:

• bileşene özgü davranış - belirli bir bileşenin nasıl ele alınacağına ilişkin ayrıntıların daha küçük bileşene özgü makinenin sorumluluğunda olması, bileşenin ne zaman ele alındığını garanti eder;
• polimorfik ifadeler - bileşene özgü makineler kendi bileşenlerine göre uyarlanmış işlemler gerçekleştirdiğinden, farklı makinelere gönderilen aynı mesaj farklı davranabilir;
• tür soyutlama - genellikle makinelerinin yaptığı işlemler için aynı kelimeyi kullanması için birkaç farklı tipte bileşen için bir anlam ifade eder;
• endişelerin ayrılması - bileşenlere özgü detayları makinelerine bırakmak, işlem makinesinin yalnızca işleminin daha genel, daha büyük endişelerini ve yönetimi için gereken verileri ele alması gerektiği anlamına gelir; Ayrıca, diğer bileşenlerdeki değişikliklerden etkilenme olasılığı daha düşüktür;
• uyarlanabilirlik - kendi uzmanlık alanlarına odaklanan bileşenler, yalnızca kullandıkları bileşenleri değiştirerek veya başka bir işlem makinesine sağlayarak öngörülemeyen kullanıma uyarlanabilir;
• kodun yeniden kullanımı - dar odaklı ve daha fazla uyarlanabilirliğe sahip bileşenler, geliştirme maliyetlerini daha sık kullanmaya tabi tutularak artırabilir.

Blogunuzdan, hem zorunlu hem de işlevsel programlamaya aşina olduğunuz ve nesne yönelimli programlamaya dahil olan temel kavramlara aşina olduğunuz anlaşılıyor, ancak ne ile ilgili olarak "tıklatan" hiç anlamadınız kullanışlı kılar. Bu bilgi açısından açıklamaya çalışacağım ve umarım sizin için yararlı olacağını umuyorum.

Özünde OOP, zorunlu etki alanını modelleyen "akıllı" veri yapıları oluşturarak yüksek karmaşıklık derecelerini daha iyi yönetmek için zorunlu paradigmayı kullanmanın bir yoludur. (Nesne yönelimli bir prosedür dışı standart) programında, iki temel şey vardır: değişkenler ve onlarla ne yapılacağını bilen kod. Kod, kullanıcıdan ve diğer çeşitli kaynaklardan girdi alır, değişkenlerde saklar, üzerinde çalışır ve kullanıcıya ya da çeşitli başka yerlere giden çıktı verilerini üretir.

Nesneye yönelik programlama, bu temel kalıbı alarak ve daha küçük ölçekte tekrarlayarak programınızı basitleştirmenin bir yoludur. Tıpkı bir program gibi, onunla ne yapılacağını bilen kod içeren büyük bir veri topluluğudur, her nesne, onunla ne yapılacağını bilen küçük bir veri parçasıdır.

Sorunlu alanı daha küçük parçalara bölerek ve olabildiğince fazla verinin doğrudan onunla ne yapılacağını bilen koda bağlı olduğundan emin olarak, işlemin bir bütün olarak ve alt konularla ilgili olarak düşünmesini çok daha kolaylaştırırsınız. süreci oluşturan konular.

Verileri nesne sınıflarına göre gruplayarak, bu verilerle ilgili kodu merkezileştirerek ilgili kodu hem bulmayı hem de hata ayıklamayı kolaylaştırabilirsiniz. Verileri erişim belirleyicilerinin arkasına sararak ve yalnızca yöntemlerle (veya diliniz destekliyorsa özellikler) kullanarak erişerek, veri bozulma olasılığını veya değişmeyenlerin ihlal edilme ihtimalini büyük ölçüde azaltırsınız.

Ve kalıtım ve polimorfizm kullanarak, önceden var olan sınıfları yeniden kullanabilir, orijinalleri değiştirmek zorunda kalmadan veya her şeyi sıfırdan yeniden yazmak zorunda kalmadan kendi özel gereksinimlerinize göre özelleştirebilirsiniz. ( Asla yapmanız gereken bir şey değil , eğer kaçınabiliyorsanız.) Sadece temel nesnenizi anladığınızdan veya katil kangurularla sonuçlandığınızdan emin olun .

Bana göre, bunlar nesne yönelimli programlamanın temel ilkeleridir: karmaşıklık yönetimi, kod merkezileştirme ve nesne sınıfları, kalıtım ve polimorfizm yaratma yoluyla gelişmiş sorun-alan modellemesi ve kapsülleme ve güç kullanımı ve kontrolden ödün vermeden arttırılmış güvenlik. özellikleri. Umarım bu, bu kadar çok programcının neden faydalı bulduğunu anlamanıza yardımcı olur.

EDIT: Joel'in yorumdaki sorusuna cevap olarak,

Esas olarak zorunlu bir programdan farklı olan bir "nesne yönelimli program" ın (ana hatlarıyla belirttiğiniz bu fantezi tanımların dışında) neler içerdiğini açıklayabilir misiniz? "Topun yuvarlanmasına nasıl karar veriyorsunuz?"

Burada küçük bir sorumluluk reddi. “Nesne yönelimli bir program” modelim temelde eski Delphi ekibi üyeleri tarafından oluşturulduğundan beri C # /. NET modeline çok benzeyen Delphi modelidir. Burada söylediklerim diğer OO dillerinde geçerli olmayabilir veya geçerli olmayabilir.

Nesneye yönelik bir program, tüm mantığın nesnelerin etrafında yapılandırıldığı programdır. Tabii ki bu bir yerde önyüklenmeli. Tipik Delphi programınız, adlandırılmış bir singleton nesnesi oluşturan başlatma kodunu içerir Application. Programın başlangıcında, çağırır Application.Initialize, daha sonra Application.CreateFormbaştan belleğe yüklemek istediğiniz her form için bir çağrı yapar ve ardından Application.Run,ana formu ekranda görüntüler ve herhangi bir çekirdeği oluşturan giriş / olay döngüsünü başlatır. etkileşimli bilgisayar programları.

Uygulama ve formlarınız işletim sisteminden gelen olayları araştırır ve nesnenizdeki yöntem çağrılarına dönüştürür. Çok yaygın olan bir şey, olay işleyicilerin veya .NET-speak'te "delegelerin" kullanılmasıdır. Bir nesnede, "X ve Y yapın, ancak bu belirli olay işleyicisinin atanıp atanmadığını kontrol edin ve varsa arayın." Diyen bir yöntemi vardır. Bir olay işleyicisi, bir nesnenin davranışını genişletmek için kullanılan, yönteme referans ve nesne örneğine referans içeren çok basit bir kapatma olan bir yöntem işaretçisidir. Örneğin, formumda bir düğme nesnesi varsa, davranışını, düğmesi tıklandığında başka bir nesnenin bir yöntemi yürütmesine neden olan bir OnClick olay işleyicisi ekleyerek özelleştiririm.

Böylece, nesne yönelimli bir programda, işlerin çoğu, belirli sorumluluklara sahip nesneleri tanımlamak ve bunları yöntem işaretçileri aracılığıyla veya bir nesnenin doğrudan başka bir nesnenin ortak arabiriminde tanımlanmış bir yöntemi çağırarak birbirine bağlamak suretiyle gerçekleştirilir. (Ve şimdi kapsüllemeye geri döndük.) Bu, üniversitede OOP derslerine başlamadan önce hiçbir geri dönüş kavramı olmadığı fikrimi.

Bence OOP, esasen benim yaptığım gibi yapmak isteyebileceğiniz bir şeye verilen bir isim.

Bebek programcısı olduğumda, Fortran'da bile, bir alt programa işaret eden bir şey vardı. Bir işaretçiyi bir alt programa başka bir alt programa argüman olarak iletmek gerçekten yararlıdır.

O zaman gerçekten yararlı olacak bir sonraki şey, bir işaretçiyi bir veri yapısının kaydının içindeki bir alt rutine depolamak olacaktır. Bu şekilde, rekorun kendi üzerinde nasıl işlem yapacağını "bildiğini" söyleyebilirsiniz.

Bunu Fortran'a inşa ettiler mi emin değilim, ama C ve soyundan gelmesi kolay.

Bu yüzden altında, bazı insanlar korkutucu konuşmalarla dolu dev bir gruplara dönmüş olsalar bile, kendinize yapmaya istekli olabileceğiniz basit ve kullanışlı bir fikirdir.

Çeşitli OO sistemleri var ve herkesin hemfikir olacağı bir tanım bulmak zor. Java'nın OO'sunun Common Lisp Object System ile nasıl benzer olduğunu göstermeye çalışmak yerine, adım adım daha geleneksel bir şeyle başlayacağım.

Dağınık veri olarak varolan çok sayıda nesneniz olduğunu varsayalım. Örneğin, noktalar bir X, bir Y ve bir Z dizisindeki öğeler olabilir. Bir noktanın kendisini ele almak için, tüm verileri bir C gibi bir şeye bir araya getirmek mantıklıdır struct.

Şimdi, herhangi bir veri nesnesi için, verileri bir araya getirdik. Bununla birlikte, prosedürel bir programda kod dağılmıştır. Diyelim ki geometrik şekillerle uğraşıyoruz. Şekil çizmek için büyük bir işlev vardır ve tüm şekilleri bilmesi gerekir. Alan bulmak için büyük, çevre için başka bir fonksiyon var. Bir dairenin kodu çoklu fonksiyonlara dağılmıştır ve başka bir şekil ekleyebilmek için hangi fonksiyonları değiştireceğimizi bilmemiz gerekir. Nesne yönelimli bir sistemde, işlevleri classveriyle aynı şeyde ( ) toplarız. Bu nedenle, tüm çevre kodlarına bakmak istiyorsak, Circletanımda var ve bir tane eklemek istiyorsak, Quartercirclesadece sınıfını yazıyoruz ve kodu aldık.

Bundan bir fayda, sınıf değişmezlerini, sınıfın her üyesi için doğru olan şeyleri koruyabilmemizdir. Sınıfın dışındaki kodları doğrudan sınıf veri üyeleriyle karıştırmakla sınırlandırarak, sınıf verilerini tek bir yerde değiştirebilecek tüm kodları elde ettik ve vidalı bir şey yapmadığını doğrulayabiliriz (tek bacaklı bir üçgen olması gibi) diğer ikisinden daha uzun süre birleştirilir). Bu, sınıfın her üyesinin bazı özelliklerine güvenebileceğimiz anlamına gelir ve her kullanımda bir nesnenin aklı başında olup olmadığını kontrol etmek zorunda kalmazız.

Asıl fayda ise kalıtım ve polimorfizmdir. Tüm bu çeşitli şekilleri, adlandırılan bir sınıfın alt sınıfları olarak tanımlayarak Shape, kodumuzu Shapes manipüle edebiliriz ve bu, manipülasyonlar tarafından ne istenirse onu yapmak için alt nesnelerin şekli işidir. Bu, yeni şekiller eklerken veya eskilerin davranışlarını iyileştirirken eski test edilmiş koda dokunmamıza gerek olmadığını gösterir. Otomatik olarak doğrudan yeni koddan faydalanabilecek eski bir koda sahibiz. Kontrol kodunu mümkün olan tüm farklı şekillerin farkında yapmak ve mümkün olan tüm farklı şekillerin farkında olan işlevleri sürdürmek yerine, sadece Shapealt sınıfları korurken şekilleri ve özelliklerini ele alıyoruz . Bu kontrol kodunu basitleştirir.

Burada birkaç avantajımız var. Sınıf değişmezlerine sahip olduğumuz için, daha geniş veri nesneleri için yerleşik türlerle ilgili olarak neden olabiliriz, yani karmaşık kavramları genellikle daha basit olanlara bölebiliriz. Çevre kodu büyük ölçüde içerdiğinden Circle, yerellik artmıştır. Farklı yerlerde birçok farklı fonksiyona dağılmış bir daire kavramı olmadığı için, rutinler arasında daha az eşleşiriz ve onları senkronize tutmak konusunda endişelenmek zorunda kalmayız. Sınıflar aslında türler olduğundan, sınıflarımızın uyumsuz kullanımını yakalamak için mevcut tür sistemden faydalanabiliriz.

OO'nun birçok farklı tanımı var, evet. Bunların çoğunu kendi başınıza bulabileceğinize eminim. Ben şahsen Rees Re: OO'yu onları anlamanın bir yolu olarak seviyorum . Sanırım Paul Graham'dan bu yana zaten okudun. (OO ile ilgilenen herkese tavsiye ederim.) Java tanımını burada az çok kabul edeceğim {1,2,3,7,8,9}.

OO'nun faydası, özellikle de yaklaşma biçimim sorunu, birkaç bin satırlık kod ile daha büyük bir cevabı hak ediyor (kısmen sadece bir grup iddiada bulunmamak için). Ancak, işte bu varsayımsal belgenin bir özeti.

OO'nun küçük ölçekte korkunç derecede yararlı olduğunu düşünmüyorum, örneğin, birkaç yüz satır. Özellikle, iyi fonksiyonel etkileri olmayan OO dilleri, herhangi bir koleksiyon veya birçok veri türüne ihtiyaç duyan herhangi bir şeyle basit şeyler yapmayı gerçekten acı verici hale getirme eğilimindedir. Tasarım desenlerinin çoğunun devreye girdiği yer burasıdır; temel dilin düşük gücüne yardım ediyorlar .

Yaklaşık bin hatta, tüm işlemleri ve veri yapılarını ve bunların ilişkilerini takip etmek zorlaşmaya başlıyor. Bu noktada, veri yapılarını ve işlemlerini açıkça organize etmenin, modül sınırlarını çizmenin ve sorumlulukları tanımlamanın ve bunlara karşı programlamaya çalışırken bu tanımları anlamanın uygun bir yolunun bulunmasına yardımcı olur.

Java-ish OO, popülerlik yarışmasını kazanmış olan bu sorunlara yarıdan bir çözümdür. Java insanlarının, yetersiz bir dilin yarattığı küçük ölçekli problemlere uyguladığı mekanizma olduğu için, organize kalmanın bir yolundan çok, her şeye sihirli bir çözüm gibi görünmeye başlama eğilimindedir. İşlevsel programlamaya aşina olan kişiler, CLOS veya Haskell'in tip sınıfları veya C ++ 'da takılı kaldıklarında şablon metaprogramlama gibi diğer çözümleri tercih etme eğilimindedirler ya da (benim gibi, C #' da günlük olarak çalışan) OO kullanırlar, ancak bu konuda heyecanlı olan her şeyi alamazlar .

OOP, gerçek dünya kavramlarını nesneler ve aralarındaki etkileşimler açısından modellemeye çalışır. İnsanlar olarak dünyayı nesneler olarak işleme eğilimindeyiz. Dünya, belirli özelliklere sahip ve diğer nesnelerle etkileşime geçmek gibi şeyler yapabilen nesnelerle doludur. OOP, dünyayı benzer terimlerle modellemeye izin verir. Örneğin,

• Kişi bir nesnedir. Bir kişinin yaş ve cinsiyet gibi bazı özellikleri vardır. Bir insan bir şeyler yapabilir: yemek, uyumak, araba kullanmak.
• Araba aynı zamanda bir Nesnedir (farklı türde olmasına rağmen). Ayrıca marka, model ve yıl gibi özelliklere sahiptir. Bir araba bir şeyler yapabilir: hareket et.

Ancak bir otomobil kendi kendine hareket edemez, onu sürecek bir insana ihtiyacı vardır - Nesneler arasındaki etkileşim.

OOP = veri yapıları + mesaj geçişi + kalıtım, hepsi programlama modellerinde mantıksal evrimdir.

OOP (programcılar tarafından) yaklaşık 90 saniye içinde anlaşılabilir (bir bağlantı için profilime bakın). Kavramlar çok basit.

Nasıl başvurulur başka bir konudur. Sadece bir çekiç nasıl sallanacağını biliyor olmanız, bir ev tasarlamayı ve inşa etmeyi bildiğiniz anlamına gelmez. ;-)

Bir süre önce faydalı bulabileceğiniz bir blog yazısı yazdım: Prosedürel vs. OOP Açıklaması .

İlk anladığım gibi:

Nesne yönelimli programlama öncesi, Yapısal programlama yaptınız . Her şey süreç etrafında toplanmış. Kendinize sormanız gereken ilk soru "Bilgi ile ne yapmak istiyorum? "

Nesne yönelimli programlama ile veri çevresinde toplanır. Kendinize sormanız gereken ilk soru " Başa çıkmam gereken cadı bilgileri? ". Bu soyutlamayı kolaylaştırır.

Yapıları anladığınızdan ve fonksiyon işaretleyicilerini anladığınızdan ve fonksiyon işaretçilerine sahip yapıları anladığınızdan, bakış açınıza göre, nesne yönelimli programlamayı basitçe "fonksiyon göstergelerine sahip yapıların yoğun kullanımı ile programlama" olarak tanımlarım. Hala geleneksel anlamda programlama yapıyor - hepsi veri ve verilere göre hareket eden kod. Aradaki fark, bütün bu bilgilerin nasıl tanımlandığı ve onu tanımlamaya nasıl yaklaştığınızdır.

Belki de aşırı basitleştirme, geleneksel programlamanın "bazı veri yapılarına sahip kod" ve nesneye yönelik programlamanın "bazı kod içeren veri yapılarına" olmasıdır. Her ikisinde de veri yapıları var ve her ikisinde de kod var Öyleyse, nesne yönelimli programlama, öndeki veri tiplerini tanımlama ve fonksiyon kümeleri aracılığıyla nasıl iletişim kurduklarına ilişkin sözleşmeler yapmaktan başka bir şey değildir.

Gördüğünüz gibi, bunun bir çözümü hayata geçirmenin harika bir yolu olmadığı devasa bir uygulama sınıfı var. Genelde bu tür uygulamalardan oluşan bir dünyada yaşıyor gibisiniz. Blog postanızda "99 şişe bira" sorununun uygulamalarına bakmaktan bahsedersiniz ("favori programlama vitriniz"). 99 şişe bira kesinlikle bu kategorinin bir parçası. 99 şişe bira uygulamasına bakarak nesne yönelimli programlamayı anlamaya çalışmak bir ağaç evine bakarak yüksek katlı mimariyi anlamaya çalışmak gibi bir şey. Çok iyi inşa edilmiş bir ağaç evi bile size sadece çok şey öğretebilir.

TL; DR: OO programlama, geleneksel programlama gibidir; ancak veri yapılarını öndeki tanımlama çabalarınızdan daha fazla odaklanmanız ve bu veri yapılarının işlev işaretçileriyle birbirleriyle iletişim kurmasını sağlamanız dışında.

Vikipedi sayfasının temelleri almak için iyi bir yer olduğunu düşünüyorum:
http://en.wikipedia.org/wiki/Object-oriented_programming

Temel olarak fikir, OOP'nin geliştirmeye çalıştığı prosedürel programlamanın modellenen süreçlere odaklandığıdır. OOP, odaklanmanın modellediğiniz “şeyler” üzerinde olduğu bir modele geçer ve bu şeylerin süreçleri ve verileri bu şeylerin içinde bulunur.

Dolayısıyla, bir örnek olarak, bir görev listesini izlemek için bir uygulama tasarladığınızı varsayalım. Prosedürel programlamada, modeldeki en üst seviyedeki varlıklar görev oluşturma, görev kaldırma, görev bilgilerini değiştirme vb. Gibi gerçekleşen süreçlerdir. Bir OOP modelinde bunun yerine Görev oluşturmaya odaklanacaksınız ve Görev'in hangi veri ve süreçlerden sorumlu olması gerektiğini düşünün. Daha sonra Görevler hakkında not tutmak istiyorsanız, Görev veya Not gibi bir nesnenin etkileşime girmesi gereken diğer nesnelere odaklanın.

Umarım bu yardımcı olur. Sadece okumaya devam et ve koduna bak ve aniden "tıkla". Bu benim tecrübemdi.