Sık sık nesnelerin kodun yeniden kullanımı açısından teslim olmadığını söyledi duydum. Katılıyor musun? Eğer inanmıyorlarsa, neden olmasın?
Sık sık nesnelerin kodun yeniden kullanımı açısından teslim olmadığını söyledi duydum. Katılıyor musun? Eğer inanmıyorlarsa, neden olmasın?
Yanıtlar:
Hayır, ille de değil.
Nesneler daha iyi anlambilim, kod / işlevsellik organizasyonu ve muhtemelen kullanım kolaylığı sağlar.
İyi tasarlanmış kütüphaneler , nesnelerin kendileri yerine kodun yeniden kullanılması vaadini sunar.
Dürüst olmak gerekirse "kod yeniden kullanımı" gerçekten kimse sonra (veya en azından sonra olmalıdır) gerçekten emin değilim. Benim felsefem "yazılım bileşenleri", yani iyi arayüzler sayesinde daha iyi bakım ve gereksiz bağlantıdan kaçınmak. "Kodun yeniden kullanımı" bazen bunun dışında kalan şeylerden biridir - gereksiz yere çoğaltılan kod, şeyleri yanlış bir şekilde düzenlediğinizin ve elbette sürdürülmesi gereken bir işarettir.
Soruyu biraz daha doğrudan cevaplamak için, kendinizi tekrar etmekten kaçınmak için oldukça iyi araçlar koleksiyonu var: miras, özellikler, delegasyon, üst düzey işlevler, vb. Bana sorarsanız, biraz fazla kullanmak eğilimindedirler. Belki de bazı "OO berbat" havasının geldiği yer budur: kalıtımın doğal bir hakkı olmadığı yerde sıkışıp kaldığını bulmak :)
Hayır, "nesneler" kod kullanımını daha kolay veya daha yaygın hale getirmedi. Kodun modüler bir programda yeniden kullanılmasını engelleyen aynı kaygılar (genel amaçlı bir API tasarlama, test etme ve belgeleme, bir kerelik bir rutin yazmaktan çok daha fazla çaba gerektirir ve tüm işlemlerin girişi hiçbirinin ustası - yeniden kullanılması amaçlanan mantık, gerçekte konulduğu kullanımlar için iyi optimize edilmemiş olabilir), kötü tasarlanmış bir nesne modelinin başka türlü yeniden kullanılabilir durumun yeniden kullanımını engelleyebileceği endişesi ile OO programlarına başvurun. kodu.
OO, birçok sorun için kullanışlı bir soyutlamadır, ancak '80s-90s yutturmacaya karşı dikkatli olun: uykunuzda waffle yapmaktan çok ticaretimizin temel sorunlarını sihirli bir şekilde çözmez.
TÜM nesnelerin yeniden kullanılmasını beklemiyorum ama birçok farklı projede yeniden kullandığımız çok fazla nesnemiz var. Ayrıca tek bir projede yeniden kullanılan nesnelerimiz de var. Aynı proje için aynı iş nesnelerini (veya veri aktarım nesnelerini) ve aynı zamanda bir Click-Once masaüstü uygulamasından, bir web uygulamasından ve bir telefon uygulamasından iş mantığı nesnelerini sık sık tüketeceğiz.
OO'nun yeniden kullanıma sunmadığını nereden duydunuz? Sebep neydi? Belki de nesnelerinin tasarımı onları bu duruma zorladı ...
Bazı Programcılar herhangi bir dilde ve stilde kopyalayıp yapıştıracaktır.
Gerçekten iyi programcılar hemen hemen her dilde kopyalama ve yapıştırma işlemlerini önleyebilir.
OO kalıplarının yeniden kullanımı teşvik etme eğiliminde olduğunu düşünüyorum. (O veri crappy ORM nedeniyle koddan ayrıldı) OO olmayan bir tarzda yazılmış Java kodu gördüm ve yeniden kullanımı gerçekten sefil - ama OO aynı programcılar tasarım daha iyi bir iş yaptı ( ve yeniden kullanın).
Ayrıca ayarlayıcılar / alıcılar, anahtar ifadeleri, anonim iç sınıflar, devasa işlevler ve benzeri gibi oo olmayan desenleri veya oo anti-patters kullandığımız durumlarda, kodun yeniden kullanıldığını ve kazan plakasının önemli ölçüde arttığını gördüm.
ps. İnsanların bir önceki paragrafta problemleri olacağını biliyorum, bu yüzden biraz açıklayacağım.
Ayarlayıcılar ve alıcılar bir nesnenin üyeleri üzerinde çalışmanıza izin verdikleri için OO sorunlarına neden olurlar (bir nesne OWN üyelerini değiştirmelidir) Bu, sınıfınızda çalışan kodu işlevselliği ayarlayıcı / alıcıya kopyalamanızı gerektiren diğer sınıflara dağıtır . Bu, Özellikler için de geçerlidir - Özelliklerin daha kolay olması, onları her durumda "İyi" yapmaz.
Anonim iç sınıflardaki kod hiç yeniden kullanılamaz ve insanlar birçok şeyin (dinleyiciler gibi) tam teşekküllü sınıflar olabileceğini ve olması gerektiğini unuturlar - bu da kapanışlar için geçerlidir! Dinleyici gibi bir şeyi uygulamak için anonim bir iç sınıf kullandıysanız, kodu bir yönteme veya kendi sınıfına ayıklamaktan ziyade uygulamanızı kopyalayıp yapıştırmanız çok daha olasıdır. Kapaklar da yeniden kullanılabilirliği artırabilir - bunları nasıl kullandığınıza bağlıdır.
Birçok durumda kullanabileceğiniz özellikler kodunuzu nasıl yapılandırdığınızı şekillendirir. OO, tüm kodunuzu ve nasıl etkileşime girdiğini görselleştirmenize yardımcı olduğunda daha da güçlüdür, ancak bu başka bir soru.
Nesnelerin, bir merdiven tırmanıcısının veya diğer fitness ekipmanlarının kilo kaybı verebileceğinden daha fazla kod yeniden kullanma yeteneği yoktur. Geliştiriciler araçları doğru şekilde kullanmaya motive edilmelidir.
Yazılım ekipleri, test edilen kodların yeniden kullanılmasına, tüm ayrıntıları başlarında tutmaya kıyasla daha yüksek bir değer verdiğinde, çok daha ayrıntılı nesneler ve yöntemler ve dolayısıyla daha fazla kodun yeniden kullanılmasını göreceksiniz.
OOP size kodu yeniden kullanmanın daha fazla yolunu sunar
gümüş mermi yok
içine ne koymak ve karşılığında ne bekleniyor!
Evet. İyi nesne yönelimli programlama, kaygıların ayrılmasını, düşük eşleşmeyi, yüksek bütünlüğü ve bilgi gizlemeyi destekler. Bunların hepsi yeniden kullanılabilir kod için kritik öneme sahiptir.
OOP'un ana faydasının yeniden kullanmaktan ziyade modülerlik ve değiştirilebilirlik olduğunu iddia ediyorum, ancak bu başka bir soru.
Evet, yaparlar, bir süper sınıftan genişletme (devralma) açıkça kodun yeniden kullanımına katkıda bulunur, herkes nasıl aksini iddia edebilir emin değilim. Sadece bir sınıf genişletmek ve süper sınıftan geri kalanı kullanırken bir yöntemi geçersiz kılabilirsiniz, bu kod yeniden kullanım yardımcı değilse o zaman ne olduğunu bilmiyorum
Eğer onlar şimdiye kadar kod yeniden kullanım vaadinde teslim var mı? Evet, eğer OOP düşünülerek yazılmış programlar tasarım kalıplarını akıllıca uygularsa. Aksi takdirde, çoğunlukla hayır. Ancak Adobe sistemlerinin, Google'ın ve benzerlerinin C ++ veya Java veya diğer OOP dilleriyle yazdığı büyük ölçekli önemsiz programların popülaritesine bakarak, OOP'un aşamalı olarak bitmeden önce uzun bir yolu olduğunu söyleyebilirim. O zaman bu soruyu sormak için çok daha uygun olacak ve yeni bir paradigma için zemin çalışması sağlamaya yardımcı olabilir.