Alaycı bir çerçeve aramıyorsanız, ultra yaygın ve kolay bulunabildikleri için , dikkat çekmeye değer birkaç şey var:
- "Her zaman" yapmanız gereken "asla" hiçbir şey yoktur.
Bir üçüncü taraf kütüphanesini hazırlamak her zaman en iyisi değildir. Uygulamanız özünde bir kitaplığa bağımlıysa veya kelimenin tam anlamıyla bir veya iki çekirdek kitaplığın etrafında oluşturulmuşsa, zamanınızı harcamayın. Kitaplıklar değişirse, uygulamanız yine de değişmelidir .
- Entegrasyon testlerini kullanmakta sorun yoktur.
Bu, özellikle kararlı, uygulamanızın özünde olan veya kolayca alay edilemeyen sınırlar için geçerlidir. Bu şartlar yerine getirilirse, sarma ve alaycı olacaktır karmaşık ve sıkıcı olabilir. Bu durumda, ikisinden de kaçınırdım: sarmayın ve alay etmeyin; entegrasyon testlerini yazmanız yeterlidir. (Otomatik test bir hedefse.)
- Araçlar ve çerçeve mantıksal karmaşıklığı ortadan kaldıramaz.
Prensip olarak, bir alet sadece kazan plakasını kesebilir. Ancak, karmaşık bir arabirim almak ve basitleştirmek için otomatikleştirilebilir bir algoritma yoktur - X arabirimini alarak ve ihtiyaçlarınıza göre uyarlamak yerine . (Sadece bu algoritmayı biliyorsunuz !) Şüphesiz , ince sarmalayıcılar oluşturabilen araçlar olsa da , bunların zaten her yerde bulunmadığını öneririm, çünkü sonunda, sadece akıllı ve dolayısıyla manuel olarak kodlamanız gerekiyor, bir sargının arkasında gizlenmiş olsa bile arabirime karşı .
Bununla birlikte, doğrudan bir sınıfa başvurmaktan kaçınmak için birçok dilde kullanabileceğiniz taktikler vardır . Ve bazı durumlarda, gerçekte mevcut olmayan bir arayüz veya ince bir ambalajı "satabilirsiniz" . Örneğin, C # 'da iki rotadan birine giderdim:
- Fabrika ve örtük yazma kullanın .
Bu küçük kombo ile karmaşık bir sınıfı tamamen sarma çabasından kaçınabilirsiniz:
// "factory"
class PdfDocumentFactory {
public static ExternalPDFLibraryDocument Build() {
return new ExternalPDFLibraryDocument();
}
}
// code that uses the factory.
class CoreBusinessEntity {
public void DoImportantThings() {
var doc = PdfDocumentFactory.Build();
// ... i have no idea what your lib does, so, I'm making stuff but.
// but, you can do whatever you want here without explicitly
// referring to the library's actual types.
doc.addHeader("Wee");
doc.getAllText().makeBiggerBy(4).makeBold().makeItalic();
return doc.exportBinaryStreamOrSomething();
}
}
Bu nesneleri daha "işlevsel" bir yaklaşımla veya bir sözlüğe (ya da her neyse ) depolayarak üye olarak saklamaktan kaçınabiliyorsanız , bu yaklaşım, temel iş varlıklarınızın tam olarak bilmesine gerek kalmadan derleme zamanı tür denetleme avantajına sahiptir. hangi sınıfla çalışıyorlar.
Gerekli olan tek şey, derleme zamanında fabrikanız tarafından döndürülen sınıfın aslında üzerinde iş nesnenizin kullandığı yöntemlere sahip olmasıdır.
- Dinamik yazmayı kullanın .
Bu, örtük yazmayı kullanmakla aynıdır , ancak başka bir takas içerir: Derleme türü denetimleri kaybedersiniz ve sınıf üyeleri olarak anonim olarak dış bağımlılıklar ekleme ve bağımlılıklarınızı enjekte etme yeteneği kazanırsınız .
class CoreBusinessEntity {
dynamic Doc;
public void InjectDoc(dynamic Doc) {
Doc = doc;
}
public void DoImortantThings() {
Doc.addHeader("Wee");
Doc.getAllText().makeBiggerBy(4).makeBold().makeItalic();
return Doc.exportBinaryStreamOrSomething();
}
}
Bu taktiklerin her ikisinde de, ExternalPDFLibraryDocumentdaha önce de belirttiğim gibi, alay etme zamanı geldiğinde , yapmanız gereken bir işiniz var - ama yine de yapmanız gereken iş . Ve bu yapı ile, 100'lü ince küçük sargı sınıflarını sık sık tanımlamaktan kaçındınız. Sadece ettik kullanılan - ona doğrudan bakmadan kütüphane çoğunlukla.
Tüm bunlarla birlikte, açıkça bir üçüncü taraf kütüphanesini tamamlamayı düşündüğüm üç büyük neden var - bunların hiçbiri bir araç veya çerçeve kullanmayı ima etmiyor:
- Belirli bir kitaplık uygulamanın kendisine özgü değildir .
- Sarmadan takas etmek çok pahalı olurdu .
- API'nin kendisini sevmiyorum.
Ben bu alanların üçünde de bazı seviye endişe yoksa, sen yok herhangi yapmak önemli Toparlamanın çaba. Ayrıca, her üç alanda da endişeleriniz varsa, otomatik olarak oluşturulan ince bir sargı gerçekten yardımcı olmaz.
Bir kütüphaneyi tamamlamaya karar verdiyseniz, zamanınızın en verimli ve etkili kullanımı, uygulamanızı istediğiniz arayüze göre oluşturmaktır ; mevcut bir API'ya karşı değil.
Başka bir deyişle, klasik tavsiyeye dikkat edin: Yapabileceğiniz her kararı erteleyin. Önce uygulamanızın "çekirdeğini" oluşturun. Sonunda ne istediğinizi yapacak ve sonuçta henüz mevcut olmayan "çevresel şeyler" tarafından yerine getirilecek arabirimlere karşı kodlayın . Boşlukları gerektiği gibi köprü haline getirin.
Bu çaba olmayabilir hissetmek zaman kaydedilen gibi; ancak bir sargıya ihtiyacınız olduğunu düşünüyorsanız, bunu güvenli bir şekilde yapmanın en etkili yoludur .
Bu şekilde düşün.
Sarılmış olsa bile , kodunuzun karanlık bir köşesinde bu kütüphaneye kod yazmanız gerekir . Test sırasında kütüphaneye alay ederseniz, sarılmış olsa bile kaçınılmaz manuel çaba var . Ama, bu doğrudan o kütüphaneyi kabul etmek gerekir anlamına gelmez adıyla uygulamanızın toplu boyunca.
TLDR
Kitaplık kaydırılmaya değerse, 3. taraf kitaplığınıza yaygın, doğrudan referansları önlemek için taktik kullanın, ancak ince sarmalayıcılar oluşturmak için kısayol kullanmayın. Önce iş mantığınızı oluşturun, arayüzleriniz hakkında bilinçli olun ve gerektiğinde adaptörlerinizi organik olarak ortaya çıkarın .
Ve eğer söz konusu olursa, entegrasyon testlerinden korkmayın. Biraz daha bulanıklar, ancak yine de çalışma kodunun kanıtını sunuyorlar ve gerilemeleri uzak tutmak için kolayca yapılabilirler.