Üçüncü taraf kodu nedir?

15

Bu sorudan ilham alındı Üçüncü taraf kitaplıkları kullanma - her zaman bir sargı mı kullanıyorsunuz? İnsanların gerçekte üçüncü taraf kütüphaneleri olarak neyi düşündüklerini bilmek istedim.

PHP'den örnek:
Zend framework kullanarak bir uygulama oluşturuyorsam, Zend framework kütüphanelerine üçüncü taraf kodu gibi davranmalı mıyım?

C # Örneği:
Bir masaüstü uygulaması oluşturuyorsam, tüm .Net sınıflarına üçüncü taraf kodu olarak mı davranmalıyım?

Java'dan bir örnek:
JDK'daki tüm kitaplıklara üçüncü taraf kitaplıkları gibi davranmalı mıyım?

Bazı insanlar bir kütüphane istikrarlıysa ve sık sık değişmezse, o zaman bir kütüphaneyi sarmaya gerek olmadığını söyler. Ancak nasıl bir üçüncü taraf kodu sarmadan bağlı bir sınıfı sınamak göremiyorum.

— Songo
kaynak

8

Aşağı seçmen lütfen nedenini açıklayabilir mi?

— Songo

Üçüncü taraf yazılımlarını duydum, ancak üçüncü taraf kodunu duymadım. Çoğu üçüncü taraf size kaynak kodlarını vermez.

— Tulains Córdova

18

Örneklerinizin tümü üçüncü taraf kodudur, ancak bunlar için sarmalayıcılar yazmamalısınız. İstikrarlı ve iyi planlanmış API'ları olan büyük, olgun projelerdir.

Paketleyicilere duyulan ihtiyaç, kodunuzla kütüphane arasında bir soyutlama katmanı sağlamaktır. Bu soyutlamaya yalnızca, bir kütüphanenin yaptığınız belirli şey için iyi API'ler sağlamadığını keşfettiğinizde ihtiyacınız olur. Ardından, kendi kodunuzu basitleştirmek için sarıcı oluşturabilir ve API çağrılarının garip olduğu gerçeğini gizleyebilirsiniz.

Bağımlılık enjeksiyonu kullanırsanız kodunuz test edilebilir. Birim testlerinizde kütüphane bağımlılığını sahte bir nesneyle değiştirerek test edilen kodunuzu izole etmenizi sağlar.

— M. Dudley
kaynak

Bir sargı veya cephenin ne zaman gerekli olacağını açıklamak için +1.

— Joshua Drake

Cevabınız için teşekkürler, ancak birim testiyle ilgili son paragrafla ilgili olarak , bir kütüphane çerçevesine doğrudan bağımlı olan bir sınıfı test etmeye çalıştığım bu soruya bir göz atabilir misiniz ?

— Songo

@Songo: Test stratejiniz, test edilen nesnenize ilettiğiniz bir Zend_Mailalay oluşturmak olmalıdır Logger. PHP ördek yazmayı desteklemiyor mu? Öyleyse, sahte bir nesne oluşturmak önemsiz olmamalı mı? Gerçekten PHP bilmiyorum, ama tipik olarak nasıl yapıldığını görmek için PHP alay kütüphanelerinden örneklere bakabilirsiniz. Ördek yazmayı desteklemeyen dillerde, o zaman Zend_Mailbir arayüze geçmeniz ve ardından arayüzü uygulayan ve Zend_Mailtüm çağrılarını devralan veya sadece delege eden ince bir sarıcı oluşturmanız gerektiğini düşünüyorum .

— M. Dudley

@emddudley evet, ama soruna ördek yazmayı desteklemeyen diğer dillerde daha genel bir çözüm arıyordum. Aslında sarma çözümünüz Zend_Mailbenim ilk düşüncemdi, ama orijinal yazımda görebileceğiniz gibi, onu uygulayan bir arabirim ve sarıcı kullandım. Ancak, sarıcı tek amacı, ben onun arayüzü alay böylece. Ördek yazmayı desteklemeyen dillerde yaygın mıdır? Sonsuz sargı inşası demek istiyorum?

— Songo

@Songo: Bence çok dile ve kütüphaneye özgü ve platformunuzun desteklediği her şeyi yapmak zorundasınız. Bazen sarmalayıcılarla sıkışmış olabilirsiniz. Bağımlılık enjeksiyonu ve nesne alaycı oldukça yeni gelişmelerdir (2004?), Bu nedenle tüm diller ve kütüphaneler bunları çok iyi desteklememektedir. Aradığınız "genel çözüm" sadece bir zihniyettir: kodunuzu gevşek bağlantı ve etkili birim testi için nasıl yapılandırabilirsiniz?

— M. Dudley

6

Bir kitaplığı tamamlamanın amacı, aşağıdakileri etkinleştirmek için kendi kodunuzun bu kitaplığa bağımlılığını kırmaktır:

Birim testi - Kodunuzu test edebilmeniz gerekir. Bir kitaplık, testiniz için gereken sınıfları taklit etmenize veya yanıtları zorlamanıza izin vermiyorsa, o kitaplığı sarmanız gerekir. Bu bariz bir sorundur ve muhtemelen merak ettiğiniz durum değildir.
Uygulamaları değiştirme - Kod yazarı olarak, yolunuza çıkması muhtemel değişiklikleri ve bu değişikliklerin hazırlanma maliyetinin ne kadar yüksek olduğuna kıyasla ne kadar maliyeti olduğunu anlamanız gerekir. .NET'ten JVM'ye geçiş yapabilir misiniz? Bu zor ve olası değil; ancak, gelecekte UI teknolojilerini veya XML motorlarını değiştirme olasılığınız çok yüksektir.

Üçüncü taraf kitaplıklarının ve çerçevelerinin yalıtılması, değişikliklerin yalıtılmasının sadece bir alt kümesidir.

— Ben
kaynak

Birim testi hakkında çok iyi bir nokta. Uygulamayı birim olarak test edebilmek için her zaman sarın demiyorum, ancak gerektiğinde bağımlılıkları ayırmak için iyi bir stratejidir.

— Sergio Acosta

2

Standart kütüphane üyelerine üçüncü taraf kodu olarak davranmazdım - sonuçta standarttır ve kullandığınız platformda kullanılabilir ve işlevsel olduğu varsayılabilir.

Zend gibi bir şey gelince, sanırım biri onu sarmaz - farklı bir çerçeve aldıysanız muhtemelen programı yeniden yazmanız gerekir. Dürüst olmak gerekirse, ciddi bir dış yapılandırma bağımlılığı olmayan çok fazla şey sarmazdım ya da bu parçayı değiştirilebilir yapmayı gerçekten planlamasaydım.

— Wyatt Barnett
kaynak

2

Belirli bir programlama dili tarafından sağlanan kütüphaneleri dilin bir parçası olarak görüyorum.

Bundan başka, üçüncü tarafları, diğer herhangi bir varlık tarafından sağlanan tüm kütüphaneleri, programlama dilinin kendisinden bir uzantı veya ayrı bir araç olarak düşünürüm.

Örneğin, Zend'i üçüncü bir taraf olarak görüyorum. Uygulamamı temel iş mantığım Zend'e bağlı olmayacak şekilde de yapardım.

Wikipedia üçüncü taraf bileşenini şu şekilde tanımlar :

Bilgisayar programlamasında, üçüncü taraf bir yazılım bileşeni, geliştirme platformunun orijinal satıcısı dışındaki bir kuruluş tarafından serbestçe dağıtılacak veya satılacak şekilde geliştirilmiş yeniden kullanılabilir bir yazılım bileşenidir.

— Patkos Csaba
kaynak

1

En katı anlamda, verdiğiniz her örnek üçüncü taraf kodudur. Ancak, üçüncü taraf kodlarının tümü sarılmamalıdır. Tüm üçüncü taraflar kütüphaneleri paketlenmelidir. Çerçeveler, tanım gereği, kodunuzun bir parçası ve parseli oldukları için sarılamaz. Bu nedenle günlük kütüphanenizi sararsınız, ancak .NET çerçevesini veya Zend çerçevesini kaydırmazsınız. Kodunuzu gerçekten .NET'ten ayıramazsınız - iç içe geçmiştir. Tabii ki, iyi çerçeveler programlamak için arabirimlere sahip olacak ve sorunu bir dereceye kadar atlamanıza izin verecektir.

Ayrıca bakınız: /programming/148747/what-is-the-difference-between-a-framework-and-a-library

— Michael
kaynak