OOP'nin amacı nedir?

Anladığım kadarıyla, OOP eğitimi, dilleri ve araçları için harcanan sayısız milyon veya milyara rağmen, OOP, geliştirici üretkenliğini veya yazılım güvenilirliğini artırmadı veya geliştirme maliyetlerini düşürmedi. Çok az kişi OOP'yi herhangi bir katı anlamda kullanır (çok az kişi LSP gibi ilkelere bağlı kalır veya anlar); İnsanların problem alanlarını modellemeye yönelik yaklaşımlarında çok az bir tekdüzelik veya tutarlılık var gibi görünüyor. Çoğu zaman, sınıf sadece sözdizimsel şekeri için kullanılır; bir kayıt türünün işlevlerini kendi küçük ad alanlarına yerleştirir.

Çok çeşitli uygulamalar için büyük miktarda kod yazdım. Gerçek ikame edilebilir alt tiplemenin uygulamada değerli bir rol oynadığı yerler olmasına rağmen, bunlar oldukça istisnai olmuştur. Genel olarak, "yeniden kullanımdan" söz etmek için çok fazla söz verilse de, gerçek şu ki, bir kod parçası tam olarak istediğiniz şeyi yapmadıkça, çok az maliyet-etkin "yeniden kullanım" vardır. Bu uzatılabilir olmak sınıflar tasarlamak son derece zordur doğru şekilde ve uzatma maliyet "yeniden kullanım" sadece değerli olmadığını normalde bu kadar büyük yani.

Pek çok bakımdan bu beni şaşırtmadı. Gerçek dünya "OO" değildir ve OO'da örtük olan fikir - bazı sınıf taksonomileriyle bazı şeyleri modelleyebileceğimiz - bana çok temelde kusurlu görünüyor (Bir masaya oturabilirim, bir ağaç kütüğü, bir araba kaputu , birinin kucağı - ama bunlardan biri sandalye değildir). Daha soyut alanlara geçsek bile, OO modellemesi genellikle zordur, mantığa aykırıdır ve sonuçta faydasızdır (klasik daire / elips veya kare / dikdörtgen örneklerini düşünün).

Öyleyse burada neyi özlüyorum? OOP'nin değeri nerede ve yazılımı daha iyi hale getirmek için neden tüm zaman ve para başarısız oldu?

Nesne yöneliminin, insanların dünya hakkında düşünmeleri için daha doğal bir yol olduğunu gösteren hiçbir ampirik kanıt yok. Programlama psikolojisi alanında, OO'nun bir şekilde diğer yaklaşımlardan daha uygun olmadığını gösteren bazı çalışmalar var.

Nesne yönelimli temsiller, evrensel olarak daha kullanışlı veya daha az kullanılabilir görünmemektedir.

Yalnızca OO yöntemlerini benimsemek ve geliştiricilerin bu tür yöntemleri kullanmasını zorunlu kılmak yeterli değildir, çünkü bu, geliştirici üretkenliği ve geliştirilen sistemlerin kalitesi üzerinde olumsuz bir etkiye sahip olabilir.

Bu, Communications of the ACM Ekim 2000'den "OO Temsillerinin Kullanılabilirliği Üzerine" adlı makaleden alınmıştır. Makaleler, esas olarak OO'yu süreç odaklı yaklaşımla karşılaştırmaktadır. OO yöntemiyle çalışan insanların nasıl "düşündüğüne" dair çok sayıda çalışma vardır (Int. J. of Human-Computer Studies 2001, sayı 54 veya Human-Computer Interaction 1995, cilt 10, OO çalışmaları üzerine bütün bir temaya sahiptir), ve okuduklarıma göre, OO yaklaşımını daha geleneksel bir prosedür yaklaşımından daha uygun kılan bir tür doğallığı gösterecek hiçbir şey yok.

Gerçek dünya "OO" değildir ve OO'da örtük olan fikir - bazı sınıf taksonomileriyle bazı şeyleri modelleyebileceğimiz - bana çok temelde kusurlu görünüyor

Bu doğru olsa ve diğer insanlar tarafından gözlemlenmiş olsa da (STL'nin mucidi Stepanov'u ele alalım), gerisi saçmadır. OOP kusurlu olabilir ve kesinlikle sihirli değnek değildir, ancak büyük ölçekli uygulamaları çok daha basit hale getirir çünkü bağımlılıkları azaltmanın harika bir yoludur. Tabii ki, bu yalnızca "iyi" OOP tasarımı için geçerlidir. Özensiz tasarım herhangi bir avantaj sağlamaz. Ancak iyi, ayrıştırılmış tasarım, OOP kullanılarak çok iyi modellenebilir ve diğer teknikler iyi kullanılamaz.

Çok daha iyi, daha evrensel modeller var ( Haskell'in tip modeli akla geliyor) ancak bunlar genellikle daha karmaşık ve / veya verimli bir şekilde uygulanması zordur. OOP, aşırılıklar arasında iyi bir değiş tokuştur.

OOP, yeniden kullanılabilir sınıflar oluşturmakla değil, Kullanılabilir sınıflar oluşturmakla ilgilidir.

Çoğu zaman, sınıf sadece sözdizimsel şekeri için kullanılır; bir kayıt türünün işlevlerini kendi küçük ad alanlarına yerleştirir.

Evet, bunu da çok yaygın buluyorum. Bu, Nesne Tabanlı Programlama değildir. Nesne Tabanlı Programlama ve veri merkezli programlama. OO Languages ​​ile 10 yıllık çalışmamda, insanların çoğunlukla Nesne Tabanlı Programlama yaptığını görüyorum. Her iki kelimeden de en kötüsünü aldığınız için OBP çok hızlı bozulur IMHO: 1) Kanıtlanmış yapısal programlama metodolojisine bağlı kalmadan prosedürel programlama ve 2) kanıtlanmış OOP metodolojisine bağlı kalmadan OOP.

Doğru yapılan OOP güzel bir şeydir. Çok zor problemlerin çözülmesini kolaylaştırır ve deneyimsiz olanlar için (orada kendini beğenmiş gibi görünmeye çalışmayanlar) neredeyse sihir gibi görünebilir. Bununla birlikte, OOP, programlama metodolojilerinin araç kutusundaki araçlardan sadece bir tanesidir. Bütün metodolojinin sonu değil. Sadece büyük iş uygulamalarına çok iyi uyuyor.

OOP dillerinde çalışan çoğu geliştirici, günlük olarak kullandıkları çerçevelerde ve türlerde doğru yapılan OOP örneklerini kullanıyor, ancak bunun farkında değiller. İşte bazı çok basit örnekler: ADO.NET, Hibernate / NHibernate, Logging Frameworks, çeşitli dil toplama türleri, ASP.NET yığını, JSP yığını vb. Bunların tümü, kod tabanlarında büyük ölçüde OOP'ye dayanan şeylerdir.

Yeniden kullanım OOP'nin hedefi veya bu konuda başka bir paradigma olmamalıdır.

Yeniden kullanım, iyi bir tasarımın ve uygun soyutlama seviyesinin bir yan etkisidir. Kod, yararlı bir şey yaparak yeniden kullanımı başarır, ancak onu esnek hale getirecek kadar çok şey yapmaz. Kodun OO olup olmadığı önemli değildir - neyin işe yaradığını ve kendimiz yapmak için önemsiz olmadığını yeniden kullanırız. Bu pragmatizmdir.

OO'nun miras yoluyla yeniden kullanılmanın yeni bir yolu olduğu düşüncesi temelde kusurludur. Dikkat ettiğiniz gibi, LSP ihlalleri çoktur. Bunun yerine, OO, bir problem alanının karmaşıklığını yönetmenin bir yöntemi olarak düşünülmüştür. Amaç, bir sistemin zaman içinde sürdürülebilirliğidir. Bunu başarmanın birincil aracı, genel arayüzün özel bir uygulamadan ayrılmasıdır. Bu, kod incelemesi yerine derleyici tarafından uygulanan "Bu yalnızca ... kullanılarak değiştirilmelidir" gibi kurallara sahip olmamızı sağlar.

Bunu kullanmak, eminim kabul edersiniz, son derece karmaşık sistemler oluşturmamıza ve sürdürmemize izin verir. Bunun pek çok değeri vardır ve diğer paradigmalarda bunu yapmak kolay değildir.

Dindarlıktan bahsediyorsun ama modern OOP'nin aşırı acımasız bir resmini çizdiğini söyleyebilirim. Gerçekten sahip olduğunu iddia ediyorum benzeri, maliyetleri düşürülmüş büyük yazılım projeleri yönetilebilir yapılan ve. Bu, yazılım dağınıklığının temel sorununu çözdüğü anlamına gelmez ve ortalama geliştiricinin bir OOP uzmanı olduğu anlamına gelmez. Ancak, işlevin nesne bileşenlerine modülerleştirilmesi, dünyadaki spagetti kodunun miktarını kesinlikle düşürdü.

Güzelce yeniden kullanılabilir ve asla hesaplanamayacak kadar zaman ve para tasarrufu sağlayan aklıma gelen onlarca kütüphane aklıma geldi.

Ancak, OOP'nin zaman kaybı olduğu ölçüde, bunun, dile özgü bir OOP eşlemesini öğrenmenin dik öğrenme eğrisi ile birleşen programcı eğitiminin eksikliğinden kaynaklandığını söyleyebilirim. Bazı insanlar OOP "alır" ve diğerleri asla almaz.

Opak bağlam nesnelerinin kullanımının (Win32'de HANDLE'lar, C'de FILE * s, iki iyi bilinen örnek olarak - cehennem, KOLLAR çekirdek modu bariyerinin diğer tarafında yaşadığını ve gerçekten anlamadığını düşünüyorum) bundan çok daha fazla kapsüllenmiş) prosedür kodunda da bulunur; Bunun OOP'ye özgü bir şey olduğunu görmekte zorlanıyorum.

HANDLEs (ve WinAPI geri kalanı) olduğu OOP! C OOP'yi çok iyi desteklemiyor, bu yüzden özel bir sözdizimi yok, ancak bu aynı kavramları kullanmadığı anlamına gelmez. WinAPI, kelimenin her anlamıyla nesne yönelimli bir çerçevedir.

Bakın, bu, OOP veya alternatif teknikleri içeren her bir tartışmanın sorunu: hiç kimse tanım konusunda net değil, herkes başka bir şey hakkında konuşuyor ve bu nedenle bir fikir birliğine varılamıyor. Bana zaman kaybı gibi geliyor.

Bu bir programlama paradigması .. Biz ölümlülerin bir sorunu daha küçük, uygulanabilir parçalara ayırmamızı kolaylaştırmak için tasarlandı ..

Yararlı bulmuyorsanız .. Kullanmayın, eğitim için para ödemeyin ve mutlu olun.

Öte yandan ben onu faydalı buluyorum, bu yüzden :)

Düz prosedürel programlamaya göre, OOP'nin ilk temel ilkesi, bilgi gizleme ve kapsülleme kavramıdır. Bu fikir , arayüzü uygulamadan ayıran sınıf kavramına götürür . Bunlar son derece önemli kavramlardır ve program tasarımı hakkında farklı ve daha iyi (bence) düşünmek için bir çerçeve yerleştirmenin temelini oluşturur. Bu özelliklere karşı gerçekten tartışamazsınız - değiş tokuş yapılmaz ve her zaman şeyleri modüle etmenin daha temiz bir yoludur.

Kalıtım ve polimorfizm dahil olmak üzere OOP'nin diğer yönleri de önemlidir, ancak diğerlerinin de söylediği gibi, bunlar genellikle aşırı kullanılır. Örneğin: Bazen insanlar kalıtımı ve / veya çok biçimliliği kullanırlar çünkü yapabilirler, sahip olmaları gerektiği için değil. Güçlü kavramlardır ve çok kullanışlıdırlar, ancak akıllıca kullanılmaları gerekir ve OOP'nin otomatik olarak kazanan avantajları değildir.

Yeniden kullanıma göre. Yeniden kullanımın OOP için aşırı satıldığını kabul ediyorum. İyi tanımlanmış nesnelerin, tipik olarak daha ilkel / genel sınıfların olası bir yan etkisidir ve kapsülleme ve bilgi gizleme kavramlarının doğrudan bir sonucudur. Yeniden kullanılması potansiyel olarak daha kolaydır çünkü iyi tanımlanmış sınıfların arayüzleri sadece daha nettir ve bir şekilde kendi kendini belgelemektedir.

OOP ile ilgili sorun, aşırı satılmış olmasıdır.

Alan Kay'ın başlangıçta tasarladığı gibi, önceki ham verilere ve tüm küresel rutinlere sahip olma uygulamasına harika bir alternatifti.

Sonra bazı yönetim-danışman türleri ona takılıp onu yazılımın mesihi olarak sattı ve lemming benzeri, akademi ve endüstri onun peşinden gitti.

Şimdi, işlevsel programlama gibi diğer iyi fikirlerin aşırı satılmasının ardından lemming gibi yuvarlanıyorlar.

Öyleyse neyi farklı yapardım? Bol ve bunun üzerine bir kitap yazdım. (Baskısı yok - Bir kuruş alamıyorum ama yine de kopya alabilirsiniz.) Amazon

Yapıcı cevabım, programlamaya gerçek dünyadaki şeyleri modellemenin bir yolu olarak değil, gereksinimleri kodlamanın bir yolu olarak bakmaktır.

Bu çok farklıdır ve bilgi teorisine dayanır (herkesin anlayabileceği bir seviyede). Programlamaya, dilleri tanımlama süreci olarak bakılabileceğini ve bunu yapma becerisinin iyi programlama için gerekli olduğunu söylüyor.

Alana özgü diller (DSL'ler) kavramını yükseltir. DRY ile kesinlikle aynı fikirde (kendinizi tekrar etmeyin). Kod oluşturmaya büyük bir başparmak veriyor. Modern uygulamalar için tipik olandan çok daha az veri yapısına sahip yazılımla sonuçlanır.

İleriye giden yolun yaratıcılıkta yattığı ve iyi kabul gören fikirlerin bile sorgulanması gerektiği fikrini yeniden canlandırmaya çalışıyor.

KOLLAR (ve WinAPI'nin geri kalanı) OOP'dur!

Öyle mi? Kalıtımsal değiller, kesinlikle ikame edilemezler, iyi tanımlanmış sınıflardan yoksundurlar ... Bence "OOP" un çok altında kalıyorlar.

WinAPI kullanarak hiç pencere oluşturdunuz mu? O halde, bir class ( RegisterClass) tanımladığınızı , bunun bir örneğini ( CreateWindow) oluşturduğunuzu, sanal yöntemleri ( WndProc) ve temel sınıf yöntemlerini ( DefWindowProc) çağırdığınızı vb. Bilmelisiniz. WinAPI, isimlendirmeyi SmallTalk OOP'tan alır ve metodları “mesajlar” olarak adlandırır (Pencere Mesajları).

Kulplar miras alınamayabilir ama finalJava'da var. Sınıfları yok, sınıf için bir yer tutucular: "tutamaç" kelimesi bu anlama geliyor. MFC veya .NET WinForms gibi mimarilere bakıldığında, sözdizimi dışında hiçbir şeyin WinAPI'den çok farklı olmadığı hemen anlaşılır.

Evet OOP tüm sorunlarımızı çözmedi, bunun için üzgünüz. Ancak tüm bu sorunları çözecek SOA üzerinde çalışıyoruz.

OOP, GUI "parçacıkları" gibi dahili bilgisayar yapılarını programlamaya çok uygundur, burada örneğin SelectList ve TextBox, "taşıma" ve "yeniden boyutlandırma" gibi ortak yöntemlere sahip olan Öğe alt türleri olabilir.

Sorun şu ki,% 90'ımız Fatura, Çalışan, İş, Sipariş gibi iş konseptleriyle çalıştığımız iş dünyasında çalışıyoruz. Bunlar kendilerini OOP'ye pek iyi ödünç vermezler çünkü "nesneler" daha belirsizdir, işin yeniden yapılandırılmasına göre değişebilir vb.

En kötü durum, OO'nun hevesle veritabanlarına uygulandığı, SQL veritabanlarına yapılan korkunç OO "geliştirmeleri" de dahil - bunlar daha yeni oldukları için işleri yapmak için doğru yol olmaları gerektiğini düşünen veritabanı noob'ları dışında haklı olarak göz ardı edilir.

İçinde bulunduğum projelerin kodunu ve tasarımını gözden geçirme deneyimime göre, geliştiricilerin çoğu akıllarında nesne yönelimli modeli doğru şekilde kavramsallaştırmadıkları için OOP'nin değeri tam olarak anlaşılmadı. Bu nedenle, OO tasarımı ile programlama yapmazlar, çoğu zaman yukarıdan aşağıya yordamsal kod yazmaya devam ederek sınıfları oldukça düz bir tasarım haline getirir . (buna "tasarım" bile diyebiliyorsanız)

İş gereksinimlerine uygun bir miras hiyerarşisi tasarlamak şöyle dursun, meslektaşların soyut bir sınıfın veya arayüzün ne olduğunu ne kadar az bildiğini gözlemlemek oldukça korkutucu.

Bununla birlikte, iyi bir OO tasarımı mevcut olduğunda, kodu okumak ve kodun doğal olarak sezgisel bileşenlere / sınıflara yerleştirildiğini görmek büyük bir zevktir. Bir şirkette çeşitli departmanları ve personel işlerini tasarlamak gibi sistem mimarisini ve tasarımını her zaman algıladım - hepsi, organizasyonu / sistemi ileriye taşımak için gereken sinerjiyi yayarak, işlerin büyük şemasında belirli bir işi başarmak için oradalar.

Bu, elbette, maalesef oldukça nadirdir . Dünyadaki güzel tasarlanmış fiziksel nesnelerin korkunç tasarımlara oranı gibi, aynı şey yazılım mühendisliği ve tasarımı için de hemen hemen söylenebilir. İyi araçlara sahip olmak, mutlaka iyi uygulamalar ve sonuçlar sağlamaz.

Belki bir kaput, kucak ya da ağaç bir sandalye değildir, ama hepsi TUTULABİLİR.

Bence bu gerçek dünya nesneleri nesneler

Siz yapıyorsunuz?

Bir faturanın hangi yöntemleri vardır? Bekle. Kendini ödeyemez, kendini gönderemez, kendisini satıcının fiilen teslim ettiği ürünlerle karşılaştıramaz. Hiç bir yöntemi yoktur; tamamen hareketsiz ve işlevsel değil. Bu bir kayıt türüdür (tercih ederseniz bir yapı), bir nesne değil.

Aynı şekilde bahsettiğiniz diğer şeyler.

Bir şeyin gerçek olması, onu kelimenin OO anlamında bir nesne yapmaz. OO nesneleri, kendiliğinden hareket edebilen tuhaf bir durum ve davranış birleşimidir. Bu, gerçek dünyada bol miktarda bulunan bir şey değil.

Yaklaşık son 9 yıldır OO kodu yazıyorum. Mesajlaşmayı kullanmaktan başka, başka bir yaklaşım hayal etmek benim için zor. CodingTheWheel'in söylediği ile tamamen uyumlu gördüğüm ana fayda: modülerleştirme. OO doğal olarak uygulamalarımı temiz arayüzlere ve net sorumluluklara sahip modüler bileşenlerden oluşturmaya yönlendiriyor (yani gevşek bir şekilde bağlı, yüksek düzeyde uyumlu kod ve açık bir kaygı ayrımı ile).

Bence OO'nun çöktüğü yer, insanların derinlemesine iç içe geçmiş sınıf hiyerarşileri yaratmasıdır. Bu karmaşıklığa yol açabilir. Bununla birlikte, ortak finctionality'yi bir temel sınıfa ayırmak ve ardından diğer alt sınıflarda bunu yeniden kullanmak son derece zarif bir şey, IMHO!

İlk olarak, gözlemler biraz özensiz. Yazılım üretkenliği hakkında herhangi bir rakamım yok ve yükselmediğine inanmak için iyi bir nedenim yok. Dahası, OO'yu kötüye kullanan pek çok insan olduğu için, OO fıstık ezmesinden beri en büyük şey OO olsa bile, OO'nun iyi kullanımı mutlaka bir üretkenlik artışına neden olmaz. Sonuçta, beceriksiz bir beyin cerrahı muhtemelen hiç olmamasından daha kötüdür, ancak yetkin bir kişi paha biçilmez olabilir.

Bununla birlikte, OO, prosedürel kodun veriler üzerinde işlemesini sağlamaktan ziyade prosedür kodunu verilere eklemenin, bir şeyleri düzenlemenin farklı bir yoludur. OO yaklaşımının daha doğal olduğu durumlar olduğu için, bu kendi başına en azından küçük bir kazanç olmalıdır. Sonuçta kimsenin C ++ 'da yordamsal bir API yazmasını engelleyen hiçbir şey yoktur ve bu nedenle bunun yerine nesneler sağlama seçeneği dili daha çok yönlü hale getirir.

Ayrıca, OO'nun çok iyi yaptığı bir şey var: eski kodun yeni kodu hiçbir değişiklik olmaksızın otomatik olarak çağırmasına izin veriyor. İşlemleri prosedürel olarak yöneten bir kodum varsa ve benzer, ancak daha öncekine benzer olmayan yeni bir tür şey eklersem, prosedür kodunu değiştirmem gerekir. Bir OO sisteminde, işlevselliği miras alırım, sevdiğim şeyi değiştiririm ve yeni kod polimorfizm nedeniyle otomatik olarak kullanılır. Bu, değişikliklerin yerelliğini artırır ve bu İyi bir Şeydir.

Olumsuz yanı, iyi bir OO'nun ücretsiz olmamasıdır: Doğru bir şekilde öğrenmek için zaman ve çaba gerekir. Büyük bir moda sözcük olduğu için, sırf bunu yapmak uğruna kötü bir şekilde yapan birçok insan ve ürün var. İyi bir sınıf arabirimi tasarlamak, iyi bir yordamsal API'den daha kolay değildir ve her türlü yapımı kolay hata vardır (derin sınıf hiyerarşileri gibi).

Bunu genel olarak daha iyi değil, farklı bir araç olarak düşünün. Bir tornavidaya ek olarak bir çekiç diyelim. Belki de sonunda, vidayı çakmak için hangi anahtarı kullanacağımızı bildiğimiz için yazılım mühendisliği uygulamasından çıkacağız.

@Sean

Bununla birlikte, ortak finctionality'yi bir temel sınıfa ayırmak ve ardından diğer alt sınıflarda bunu yeniden kullanmak son derece zarif bir şey, IMHO!

Ancak "prosedürel" geliştiriciler bunu zaten onlarca yıldır yapıyorlar. Sözdizimi ve terminoloji farklı olabilir, ancak etki aynıdır. OOP için "temel sınıfta ortak işlevselliği yeniden kullanmaktan" daha fazlası vardır ve bunu OOP olarak tanımlamanın zor olduğunu söyleyecek kadar ileri gidebilirim; Aynı işlevi farklı kod bitlerinden çağırmak, alt prosedürün kendisi kadar eski bir tekniktir.

@Konrad

OOP kusurlu olabilir ve kesinlikle sihirli değnek değildir, ancak büyük ölçekli uygulamaları çok daha basit hale getirir çünkü bağımlılıkları azaltmanın harika bir yoludur.

Dogma budur. Bu bağlamda OOP'yi eskisinin prosedürel programlamasından önemli ölçüde daha iyi yapan şeyin ne olduğunu görmüyorum. Ne zaman bir prosedür çağrısı yapsam, kendimi uygulamanın özelliklerinden izole ediyorum.

Bana göre, OOP sözdiziminin kendisinde çok fazla değer var. Gerçek şeyleri veya veri yapılarını temsil etmeye çalışan nesnelerin kullanılması, aynı veriyle aynı şeyi yapmak için bir grup farklı düz (veya "kayan") işlev kullanmaya çalışmaktan genellikle çok daha kullanışlıdır. Okumayı, yazmayı ve uzun vadede sürdürmeyi daha mantıklı kılan, iyi OOP'ye sahip şeylere belirli bir doğal "akış" vardır.

Bir Faturanın kendi kendini gerçekleştirebileceği işlevlere sahip gerçekten bir "nesne" olmaması önemli değildir - nesne örneği, gerçekte ne tür verilerin olduğunu bilmek zorunda kalmadan, yalnızca veriler üzerinde işlevler gerçekleştirmek için var olabilir. "İnvoice.toJson ()" işlevi, "fatura" nın ne tür bir veri olduğunu bilmek zorunda kalmadan başarıyla çağrılabilir - bir veritabanından, XML'den, CSV'den veya hatta başka bir JSON nesnesinden gelse de sonuç Json olacaktır. . Prosedürel işlevlerle, birdenbire verileriniz hakkında daha fazla bilgi sahibi olmanız ve sonunda "xmlToJson ()", "csvToJson ()", "dbToJson ()" vb. Gibi işlevlerle karşılaşmanız gerekir. Altta yatan veri türünü değiştirirseniz BÜYÜK baş ağrısı.

OOP'nin amacı, gerçek uygulamayı soyutlayarak gizlemektir. Bu hedefe ulaşmak için, genel bir arayüz oluşturmalısınız. Ortak arayüzü oluştururken işinizi kolaylaştırmak ve işleri KURU tutmak için, soyut sınıflar, kalıtım, çok biçimlilik ve tasarım kalıpları gibi kavramları kullanmalısınız.

Bu yüzden bana göre, OOP'nin asıl amacı, gelecekteki kod bakımını ve değişikliklerini kolaylaştırmaktır. Ancak bunun da ötesinde, prosedürel kodun asla yapamayacağı şekillerde doğru yapıldığında işleri gerçekten çok basitleştirebilir. "Gerçek dünya" ile eşleşip eşleşmemesi önemli değil - kodla programlama zaten gerçek dünya nesneleriyle etkileşime girmiyor. OOP sadece işimi kolaylaştıran ve hızlandıran bir araçtır - bunu her gün yapacağım.

@CodingTheWheel

Ancak, OOP'nin zaman kaybı olduğu ölçüde, bunun, dile özgü bir OOP eşlemesini öğrenmenin dik öğrenme eğrisi ile birleşen programcı eğitiminin eksikliğinden kaynaklandığını söyleyebilirim. Bazı insanlar OOP "alır" ve diğerleri asla almaz.

Yine de bunun gerçekten şaşırtıcı olup olmadığını bilmiyorum. Teknik olarak sağlam yaklaşımların (LSP bariz olan) kullanımını zorlaştırdığını düşünüyorum , ancak bu tür yaklaşımları kullanmazsak, kodu kırılgan ve uzayamaz hale getirir (çünkü artık bunun hakkında akıl yürütemeyiz). Ve Bence OOP'nin bizi, insanların bunu anlamamasını şaşırtıcı olmayan bir hale getirdiği mantık dışı sonuçlar.

Daha da önemlisi, yazılım zaten temelde normal insanlar için güvenilir ve doğru bir şekilde yazmak için çok zor olduğundan, sürekli olarak kötü öğretilen ve öğrenmesi zor görünen bir tekniği gerçekten övmeli miyiz? Faydalar netse, zorluklara rağmen sebat etmeye değer olabilir, ancak durum böyle görünmüyor.

@Jeff

Düz prosedürel programlamaya göre, OOP'nin ilk temel ilkesi, bilgi gizleme ve kapsülleme kavramıdır. Bu fikir, arayüzü uygulamadan ayıran sınıf kavramına götürür.

Hangisi daha gizli uygulamaya sahiptir: C ++ 'ın iostreams'i veya C'nin FILE *' leri?

Opak bağlam nesnelerinin kullanımının (Win32'de HANDLE'lar, C'de FILE * s, iki iyi bilinen örnek olarak - cehennem, KOLLAR çekirdek modu bariyerinin diğer tarafında yaşadığını ve gerçekten anlamadığını düşünüyorum) bundan çok daha fazla kapsüllenmiş) prosedür kodunda da bulunur; Bunun OOP'ye özgü bir şey olduğunu görmekte zorlanıyorum.

Sanırım bu, faydaları görmekte zorlandığımın bir parçası olabilir: açıkça iyi olan parçalar OOP'ye özgü değildir, oysa OOP'ye özgü parçalar açıkça iyi değildir! (Bu onların mutlaka kötü oldukları anlamına gelmez, daha çok yaygın olarak uygulanabilir ve sürekli olarak faydalı olduklarına dair kanıtları görmedim).

Okuduğum tek geliştirici blogda, o Joel-On-Software-Founder-of-SO adam tarafından, uzun zaman önce OO'nun üretkenlik artışına yol açmadığını okudum. Otomatik hafıza yönetimi yapar. Güzel. Verileri kim reddedebilir?

Ben hala OO'nun OO olmayanlar için fonksiyonlarla programlamanın her şeyi sıralı programlamak için olduğuna inanıyorum.

(Ve bilmeliyim ki, GWBasic ile başladığım gibi.) İşlevleri kullanmak için kodu yeniden düzenlediğinizde, içinde bulunduğunuz yöntem variable2654haline gelir variable3. Ya da daha iyisi, anlayabileceğiniz bir adı var ve işlev kısa ise , denir value ve tam kavrayış için bu yeterlidir.

İşlevsiz kod, yöntemlerle kod haline geldiğinde, kilometrelerce kod silersiniz.

Olmak için kodu yeniden zaman gerçekten OO, b, c, q, ve Zolmak this, this, thisve this. Ve thisanahtar kelimeyi kullanmaya inanmadığım için kilometrelerce kod siliyorsunuz. Aslında, kullansanız bile bunu yaparsınız this.

OO'nun doğal bir metafor olduğunu düşünmüyorum.

Dilin de doğal bir metafor olduğunu düşünmüyorum, Fowler'ın "kokularının" "bu kodun tadı kötü" demekten daha iyi olduğunu da düşünmüyorum. Bununla birlikte, OO'nun doğal metaforlarla ilgili olmadığını düşünüyorum ve nesnelerin size doğru fırladığını düşünen insanlar temelde noktayı kaçırıyorlar. Nesne evrenini tanımlarsınız ve daha iyi nesne evrenleri, daha kısa, daha kolay anlaşılır, daha iyi çalışan veya bunların tümü (ve unuttuğum bazı kriterler) kodla sonuçlanır. Müşterilerin / alanın doğal nesnelerini programlama nesneleri olarak kullanan insanların evreni yeniden tanımlama gücünü kaçırdıklarını düşünüyorum.

Örneğin, bir havayolu rezervasyon sistemi yaptığınızda, rezervasyon dediğiniz şey yasal / ticari bir rezervasyona hiç karşılık gelmeyebilir.

Temel kavramlardan bazıları gerçekten harika araçlardır

Bence çoğu insan "çekiç varken, hepsi çivi" olayı tümüyle abartıyor. Madeni paranın / aynanın diğer tarafının da aynı derecede doğru olduğunu düşünüyorum: polimorfizm / kalıtım gibi bir aletiniz olduğunda, eldiven / çorap / kontakt lens gibi uygun olduğu kullanımları bulmaya başlarsınız. OO'nun araçları çok güçlüdür. Tek kalıtım, bence, insanların başka yere taşınmaması için kesinlikle gerekli, kendi çoklu miras yazılımıma karşı koyamıyor.

OOP'nin amacı nedir?

Kesinlikle büyük bir kod tabanını idare etmenin harika bir yolu olduğunu düşünüyorum. Bence kodunuzu düzenlemenize ve yeniden düzenlemenize olanak tanır ve bunu yapmak için size bir dil sunar (çalıştığınız programlama dilinin ötesinde) ve kodu oldukça doğal ve anlaşılması kolay bir şekilde modüler hale getirir.

OOP, geliştiricilerin çoğu tarafından yanlış anlaşılmaya mahkumdur

Bunun nedeni, yaşam gibi göz açıcı bir süreç olmasıdır: OO'yu deneyimle giderek daha çok anlarsınız ve daha akıllı hale geldikçe belirli kalıplardan kaçınmaya ve başkalarını kullanmaya başlarsınız. En iyi örneklerden biri, kontrol etmediğiniz sınıflar için kalıtımı kullanmayı bırakmanız ve bunun yerine Cephe modelini tercih etmenizdir .

Mini makaleniz / sorunuzla ilgili olarak

Haklı olduğunu söylemek istedim. Yeniden kullanılabilirlik, çoğunlukla boş bir hayaldir. İşte Anders Hejilsberg'den bu konuyla ilgili (harika) bir alıntı buradan :

Yeni başlayan programcılardan bir takvim denetimi yazmalarını isterseniz, genellikle kendi kendilerine şöyle düşünürler: "Ah, dünyanın en iyi takvim denetimini yazacağım! Takvim türüne göre polimorfik olacak. Göstericileri olacak, ve mungers ve bu, o ve diğerleri. " İki ay içinde bir takvim uygulaması göndermeleri gerekiyor. Tüm bu altyapıyı kontrol altına alıyorlar ve ardından üzerine berbat bir takvim uygulaması yazmak için iki gün harcıyorlar. "Uygulamanın bir sonraki sürümünde çok daha fazlasını yapacağım" diye düşünecekler.

Soyut tasarımlarının tüm bu diğer somutlaştırmalarını aslında nasıl uygulayacaklarını düşünmeye başladıklarında, tasarımlarının tamamen yanlış olduğu ortaya çıkıyor. Ve şimdi kendilerini bir köşeye boyadılar ve her şeyi dışarı atmak zorundalar. Bunu defalarca gördüm. Minimalist olmaya güçlü bir inancım var. Genel problemi gerçekten çözmeyecekseniz, belirli bir problemi çözmek için bir çerçeve oluşturmaya çalışmayın, çünkü bu çerçevenin nasıl görünmesi gerektiğini bilmiyorsunuz.

WinAPI kullanarak hiç pencere oluşturdunuz mu?

Hatırlamayı umursadığımdan daha fazla kez.

O zaman bir sınıf (RegisterClass) tanımladığınızı, bunun bir örneğini oluşturduğunuzu (CreateWindow), sanal yöntemleri (WndProc) ve temel sınıf yöntemlerini (DefWindowProc) vb. Çağırdığınızı bilmelisiniz. WinAPI, isimlendirmeyi SmallTalk OOP'tan alır ve metodları “mesajlar” olarak adlandırır (Pencere Mesajları).

O zaman kendi başına hiçbir mesaj göndermediğini de bilirsiniz ki bu büyük bir boşluktur. Aynı zamanda berbat bir alt sınıfa sahiptir.

Kulplar miras alınamayabilir, ancak o zaman Java'da son var. Sınıfları yok, sınıf için bir yer tutucular: "tutamaç" kelimesi bu anlama geliyor. MFC veya .NET WinForms gibi mimarilere bakıldığında, sözdizimi dışında hiçbir şeyin WinAPI'den çok farklı olmadığı hemen anlaşılır.

Ne arayüzde ne de uygulamada miras alınamazlar, minimum düzeyde ikame edilebilirler ve yordamsal kodlayıcıların sonsuza dek yaptıklarından önemli ölçüde farklı değiller.

Bu gerçekten o mu? OOP'nin en iyi bitleri sadece ... geleneksel prosedür kodu mu? Önemli olan bu mu?

InSciTek Jeff'in cevabına tamamen katılıyorum , sadece aşağıdaki düzeltmeleri ekleyeceğim:

• Bilgi gizleme ve kapsülleme: Bakım yapılabilir kodlar için kritiktir. Herhangi bir programlama dilinde dikkatli olunarak yapılabilir, OO özellikleri gerektirmez, ancak bunu yapmak kodunuzu biraz OO benzeri yapar.
• Kalıtım: Tüm bu OO'nun bir tür olduğu ve bir içeren ilişkilerinin mükemmel bir uyum sağladığı önemli bir uygulama alanı vardır: Grafik Kullanıcı Arayüzleri. OO dil desteği olmadan GUI'ler oluşturmaya çalışırsanız, yine de OO benzeri özellikler geliştirmeye başlayacaksınız ve bu, dil desteği olmadan daha zor ve hataya daha açık hale geliyor. Örneğin Glade (yakın zamanda) ve X11 Xt (tarihsel olarak).

OO özelliklerini (özellikle derinlemesine iç içe geçmiş soyut hiyerarşileri) kullanmak, hiçbir anlamı olmadığında anlamsızdır. Ancak bazı uygulama alanları için gerçekten bir nokta var.

OOP'nin en faydalı kalitesinin veri saklama / yönetme olduğuna inanıyorum. Bununla birlikte, OOP'nin kötüye kullanıldığı çok sayıda örnek var ve bence karışıklığın geldiği yer burası.

Bir şeyi bir nesneye dönüştürebiliyor olman, yapman gerektiği anlamına gelmez. Ancak, bunu yapmak kodunuzu daha düzenli / daha kolay okunur hale getirecekse, kesinlikle yapmalısınız.

OOP'nin çok yararlı olduğu harika bir pratik örnek, bir "ürün" sınıfı ve web sitemizde kullandığım nesnelerdir. Her sayfa bir ürün olduğundan ve her ürünün diğer ürünlere referansları olduğundan, sahip olduğunuz verilerin hangi ürüne atıfta bulunduğu konusunda çok kafa karıştırıcı olabilir. Bu "strURL" değişkeni, geçerli sayfaya veya ana sayfaya veya istatistik sayfasına giden bağlantı mı? Elbette aynı bilgiye başvuran her türden farklı değişken yapabilirsiniz, ancak proCurrentPage-> strURL'nin anlaşılması çok daha kolaydır (bir geliştirici için).

Ayrıca bu sayfalara fonksiyon eklemek çok daha temiz. ProCurrentPage-> CleanCache (); Ardından proDisplayItem-> RenderPromo (); Bu işlevleri arayıp mevcut verilerin mevcut olduğunu varsayarsam, kim bilir ne tür bir kötülük meydana gelirdi. Ayrıca, doğru değişkenleri bu işlevlere geçirmem gerekirse, etrafta bulunan farklı ürünler için her türlü değişkene sahip olma sorununa geri dönerim.

Bunun yerine, nesneleri kullanmak, tüm ürün verilerim ve işlevlerim güzel, temiz ve anlaşılması kolaydır.

Ancak. OOP ile ilgili en büyük sorun, birinin HER ŞEYİN OOP olması gerektiğine inandığı zamandır. Bu çok fazla sorun yaratır. Veritabanımda 88 tablo var. Sadece 6 dersim var ve belki de 10 dersim olmalı. Kesinlikle 88 derse ihtiyacım yok. Çoğu zaman bu tablolara doğrudan erişmek, onu kullandığım koşullarda mükemmel bir şekilde anlaşılabilir ve OOP, gerçekte olan şeyin temel işlevine ulaşmayı daha zor / sıkıcı hale getirir.

Yararlı ve prosedürel, pratik olduğunda en etkili kodlama yöntemi olan hibrit bir nesne modeline inanıyorum. İnsanların, diğerlerinin pahasına bir yöntemi kullanmayı savunduğu tüm bu dini savaşlara sahip olmamız utanç verici. İkisi de iyi ve ikisinin de yeri var. Çoğu zaman, her büyük projede her iki yöntemin de kullanımı vardır (Bazı küçük projelerde, ihtiyacınız olan tek şey tek bir nesne veya birkaç prosedür olabilir).

Okunabilirlik için yaptığım kadar yeniden kullanımı umursamıyorum. İkincisi, kodunuzun değiştirilmesinin daha kolay olduğu anlamına gelir. Yazılım oluşturma zanaatında bu tek başına altın değerindedir.

Ve OO, programlarınızı okunabilir hale getirmenin oldukça etkili bir yoludur. Yeniden kullanın veya yeniden kullanmayın.

"Gerçek dünya" OO "değildir"

Gerçekten mi? Benim dünyam nesnelerle dolu. Şimdi bir tane kullanıyorum. Bence yazılım “nesneleri” nin gerçek nesneleri modellemesi o kadar da kötü bir şey olmayabilir.

OO kavramsal şeyler için tasarlar (Windows gibi, gerçek dünya pencereleri değil, bilgisayar monitörümdeki ekran panelleri) genellikle arzulanan çok şey bırakır. Ancak faturalar, nakliye siparişleri, sigorta talepleri ve ne-değil gibi gerçek dünyadaki şeyler için, bu gerçek dünya şeylerinin nesneler olduğunu düşünüyorum. Masamda bir yığın var, bu yüzden gerçek olmalılar.

OOP'nin amacı, programcıya, koddaki bir soruna bir çözümü açıklamak ve makinelere ve insanlara iletmek için başka bir yol vermektir. Bunun en önemli kısmı insanlarla iletişimdir. OOP, programcının OO dilinde zorunlu kılınan kurallar aracılığıyla kodda ne anlama geldiğini açıklamasına izin verir.

Bu konudaki birçok argümanın aksine, OOP ve OO kavramları, C gibi OOP olmayan dillerdeki kodlar da dahil olmak üzere tüm kod boyunca yaygındır. Birçok gelişmiş OO olmayan programcı, OO olmayan dillerde bile nesnelerin özelliklerini yaklaşık olarak tahmin edecektir.

OO'nun dilde yerleşik olması, programcıya yalnızca başka bir ifade yolu sağlar.

Kod yazmanın en büyük kısmı makine ile iletişim değil, o kısmı kolay, en büyük kısmı insan programcılarla iletişim.