Soyutlamalara bağlı olmanın önemli dezavantajları var mı?

9

Bu vikiyi Kararlı Soyutlamalar Prensibi (SAP) üzerine okuyordum .

SAP, bir paket ne kadar kararlı olursa o kadar soyut olacağını belirtiyor. Bu, bir paket daha az kararlıysa (değişme olasılığı daha yüksekse) daha somut olması gerektiği anlamına gelir. Gerçekten anlamadığım şey, durumun neden böyle olması gerektiğidir. Elbette istikrardan bağımsız olarak her durumda soyutlamalara ve somut uygulamanın gizlenmesine bağlı olmalıyız?

— SteveCallender
kaynak

Sağladığı soyutlamaları kullanarak değil , her şeyi tam olarak alıştığınızdan daha düşük bir düzeyde ayrıntılı olarak yaparak rahat bir bileşeni kullanmayı deneyin . Bu, soyutlamanın avantajları ve dezavantajları hakkında oldukça iyi bir izlenim verecektir.

— Kilian Foth

2

Bağlantılı makaleyi ve / veya makalenin dayandığı kitabı okudunuz mu?

— Jörg W Mittag

1

+1 İyi bir soru, özellikle istikrar ve soyutlama arasındaki ilişkinin hemen sezgisel olduğunu düşünmüyorum. Bu makalenin Sayfa 11'i yardımcı olur, soyut vaka örneği mantıklıdır, ancak belki biri somut davaya daha açık bir örnek yazabilir. Beklemeye alma talebi.

— Mike

Bu soyutlamalar için hangi problem alanıyla ilgileniyorsunuz? C2'de belirtildiği gibi: "Gerçek dünya alanlarını modellerken - müşteriler, çalışanlar, faturalar, malzeme listeleri, ürünler, SKU'lar, ödeme tabloları, vb. - sabit soyutlamaları bulmak zor olabilir. yığınlar, kuyruklar, işlevler, ağaçlar, süreçler, iş parçacıkları, grafiksel gereçler, raporlar, formlar vb. dünyası - kararlı olma olasılığı daha yüksektir. " ve "Bazı alanlarda, kararlı soyutlamaların yapılması zordur." SAP ile hangi sorunu çözmeye çalıştığınızı bilmeden size iyi bir cevap vermek zor.

@ JörgWMittag ve Mike - Evet makaleyi okudum. Sadece "kararsız paketlerin neden somut olması gerektiğine" dair bir açıklama olmadığını hissediyorum. Bahsi geçen makalenin 13. sayfasında bir grafik gösteriyor, ancak grafikte neden (1,1) kaçınılması gerektiği konusunda çok ayrıntılı bir şekilde açıklamaya devam etmiyor? Temelde dengesizliğin daha az afferent bağımlılık anlamına geldiği ve soyutlamanın kullanılmasına gerek olmadığı fikri var mı? Eğer öyleyse ... stabilite gereksinim değiştiğinde değişiyorsa soyutlamayı yine de kullanmak iyi bir uygulama değil ..

— SteveCallender

7

Paketlerinizi bir API olarak düşünün, kağıttan örnek almak , soyut API'nizle ve onunla Readerbirlikte tanımları alın .string Reader.Read()Writervoid Writer.Write(string)

Daha sonra Copybir yöntem Copier.Copy(Reader, Writer)ve uygulama Writer.Write(Reader.Read())ve belki de bazı sağlık kontrolleri ile bir sınıf oluşturabilirsiniz .

Şimdi, beton uygulamaları yapmak, örneğin FileReader, FileWriter, KeyboardReaderve DownloadThingsFromTheInternetReader.

Uygulamanızı değiştirmek isterseniz ne olur FileReader? Sorun değil, sadece sınıfı değiştirin ve yeniden derleyin.

Soyutlamanızın tanımını değiştirmek isterseniz ne olur Reader? Hata, sadece o değiştiremezsiniz, ama aynı zamanda değiştirmek zorunda kalacak Copier, FileReader, KeyboardReaderve DownloadThingsFromTheInternetReader.

Bu, Kararlı Soyutlama İlkesinin arkasındaki mantıktır: Betonlamalarınızı soyutlamalardan daha az kararlı hale getirin.

— posa
kaynak

1

Söylediğin her şeye katılıyorum, ama inanıyorum ki yazarlar kararlılığın tanımı ve seninki farklı. Stabiliteyi değişime ihtiyaç olarak görürsünüz, yazar "stabilite bir modülün değişme olasılığının bir ölçüsü değildir; bunun yerine bir modülü değiştirme zorluğunun bir ölçüsüdür" diyor. Öyleyse sorum, daha kolay değiştirilebilen paketlerin soyuttan ziyade daha somut olması neden daha faydalı?

— SteveCallender

1

@SteveCallender Bu ince farktır: Yazarın "kararlılık" tanımı çoğu insanın "kararlılık ihtiyacı" dediği şeydir. Ne kadar fazla modül bir modüle bağlıysa, o kadar "kararlı" bir modül olmalıdır.

— Residuum

6

YAGNI yüzünden .

Şu anda yalnızca tek bir şeyin uygulamanız varsa , neden ekstra ve yararsız bir katmanla uğraşasınız ki? Sadece gereksiz karmaşıklığa yol açacaktır. Daha da kötüsü, bazen ikinci bir uygulamanın geleceği güne soyutlama düşüncesi sağlarsınız ... ve bu gün asla gerçekleşmez. Ne iş kaybı!

Ben de kendisine sorulması gereken asıl sorunun "soyutlamalara bağımlı olmam gerekiyor mu?" daha ziyade "Modülerliğe ihtiyacım var mı?". Modülerliğe her zaman ihtiyaç duyulmaz, aşağıya bakın.

Çalıştığım şirkette, geliştirdiğim bazı yazılımlar, iletişim kurması gereken bazı donanım cihazlarına güçlü bir şekilde bağlı. Bu cihazlar çok özel hedeflere ulaşmak için geliştirilmiştir ve modüler dışında her şeydir. :-) ilk üretilen cihaz, fabrikanın dışına gider ve bir yere kurulduktan sonra onun firmware ve donanım can asla değişiklik hem hiç .

Dolayısıyla, yazılımın bazı bölümlerinin asla evrim geçirmeyeceğinden emin olabilirim. Bu parçaların soyutlamalara bağlı olması gerekmez, çünkü sadece bir uygulama vardır ve bu asla değişmez. Kodun bu bölümlerindeki soyutlamaların bildirilmesi sadece herkesi şaşırtacak ve daha fazla zaman alacaktır (herhangi bir değer üretmeden).

— Benekli
kaynak

1

YAGNI ile hemfikirim ama örneğini merak ediyorum. Asla tekrar Are herhangi farklı cihazlarda kod? Aynı şirketin cihazlarında bazı ortak kodların bulunmadığına inanmakta zorlanıyorum. Ayrıca, istemciler yazılımlarındaki hataları düzeltmediğinizde nasıl hoşlanırlar? Eğer, böcek asla orada söylüyorsun hiç ? 4 farklı uygulamada aynı kodla sahipseniz, ortak bir modülde değilse hatayı 4 kez düzeltmeniz gerekir.

— Fuhrmanator

1

@Fuhrmanator ortak kodu soyutlamalardan farklıdır. Ortak kod sadece bir yardımcı yöntem veya kütüphane anlamına gelebilir - soyutlama gerekmez.

— Eilon

@Fuhrmanator Tabii ki kütüphanelerde ortak kodumuz var, ama Eilon'un dediği gibi, her şey soyutlamalara bağlı değildir (ancak bazı bölümler buna bağlıdır). Asla böcek olmadığını söylemedim, yamalı olamayacaklarını söyledim (OP sorununun kapsamı dışındaki nedenlerle).

— Benekli

@ Elon benim yorum modülerlik her zaman gerekli değildir (soyut değil) idi.

— Fuhrmanator

@Spotted Düzeltme yapamama sorunu yok. Oldukça spesifik bir örnek ve çoğu yazılım için tipik değil.

— Fuhrmanator

6

Sanırım belki de Robert Martin tarafından seçilen ahır kelimesi karıştı . İşte karışıklığın başladığı yer:

Bu, bir paket daha az kararlıysa (değişme olasılığı daha yüksekse) daha somut olması gerektiği anlamına gelir.

Orijinal makaleyi okursanız , şunu görürsünüz (benimkini vurgulayın):

İstikrar kelimesinin klasik tanımı: “Kolay hareket ettirilemez.” Bu makalede kullanacağımız tanım budur. Yani, kararlılık bir modülün değişme olasılığının bir ölçüsü değildir; daha ziyade bir modülü değiştirmenin zorluğunun bir ölçüsüdür .

Açıkçası, değiştirilmesi daha zor olan modüller daha az uçucu olacaktır. Modül ne kadar zor değiştirilirse, yani ne kadar kararlı olursa, o kadar az uçucu olacaktır.

Her zaman yazarın kararlı kelimeyi seçmesi ile mücadele ettim, çünkü (senin gibi) istikrarın "olabilirlik" yönünü, yani değişme olasılığını düşünmeye eğilimliyim . Zorluk , bu modülün değiştirilmesinin diğer modüllerin çoğunu bozacağını ve kodu düzeltmek için çok fazla iş olacağını ima eder.

Martin ayrıca bana daha fazla anlam ifade eden bağımsız ve sorumlu sözcükleri kullanıyor . Eğitim seminerinde, büyüyen çocukların ebeveynleri ve nasıl "sorumlu" olmaları gerektiği konusunda bir metafor kullandı, çünkü çocukları onlara bağlı. Boşanma, işsizlik, hapsetme vb., Ebeveynlerdeki değişimin çocuklar üzerindeki olumsuz etkisinin gerçek dünyadaki harika örnekleridir. Bu nedenle, ebeveynler çocuklarının yararına "istikrarlı" olmalıdır. Bu arada, çocukların / ebeveynlerin bu metaforu mutlaka OOP'taki miras ile ilgili değildir!

Yani, "sorumlu" ruhunu izleyerek değişmesi zor (veya değişmemeli ) için alternatif anlamlar buldum :

Yükümlü - bu yüzden diğer sınıflar bu sınıfa bağlı anlam olmamalıdır değiştirin.
Bakın - aynı yerde.
Kısıtlı - bu sınıfın yükümlülükleri, tesisin değişmesini sınırlar.

Yani, bu tanımları ifadeye ekleyerek

paket ne kadar kararlı olursa o kadar soyut olmalıdır

daha zor bir paket daha soyut olması gerektiği
daha seyrekbir paket ne kadar , o kadar soyut olmalıdır
paket ne kadar kısıtlıysa o kadar soyut olmalıdır

Kafa karıştırıcı kelimeleri kararlı / kararsız vurgulayarak Kararlı Soyutlamalar İlkesi'nden (SAP) bahsedelim:

Maksimum kararlı paketler maksimum soyut olmalıdır. Kararsız paketler beton olmalıdır. Bir paketin soyutluğu, kararlılığıyla orantılı olmalıdır .

Bu kafa karıştırıcı kelimeler olmadan açıklığa kavuşturmak:

Sistemin diğer kısımlarına azami ölçüde tutulan paketler azami soyut olmalıdır. Zorlanmadan değişebilen paketler somut olmalıdır. Bir paketin soyutluğu, değiştirilmesinin ne kadar zor olacağıyla orantılı olmalıdır .

TL; DR

Sorunuzun başlığı şunu soruyor:

Soyutlamalara bağlı olmanın önemli dezavantajları var mı?

Bence soyutlamaları düzgün bir şekilde oluşturursanız (örneğin, çok fazla kod onlara bağlı olduğu için var olurlar), o zaman önemli bir dezavantaj yoktur.

— Fuhrmanator
kaynak

0

Bu, bir paket daha az kararlıysa (değişme olasılığı daha yüksekse) daha somut olması gerektiği anlamına gelir. Gerçekten anlamadığım şey, neden böyle olması gerektiğidir.

Soyutlamalar yazılımda değiştirilmesi zor olan şeylerdir çünkü her şey onlara bağlıdır. Paketiniz sık sık değişecekse ve soyutlamalar sağlıyorsa, ona bağımlı olan insanlar bir şeyi değiştirdiğinizde kodlarının büyük bir kısmını yeniden yazmak zorunda kalacaklar. Ancak kararsız paketiniz bazı somut uygulamalar sağlıyorsa, değişikliklerden sonra çok daha az kodun yeniden yazılması gerekecektir.

Dolayısıyla, paketiniz sık sık değişecekse, soyutlamaları değil, betonları daha iyi sağlamalıdır. Aksi halde ... onu kim kullanacak? ;)

— Vladislav Rastrusny
kaynak

0

Martin'in kararlılık metriğini ve "kararlılık" ile ne anlama geldiğini unutmayın:

Instability = Ce / (Ca+Ce)

Veya:

Instability = Outgoing / (Incoming+Outgoing)

Yani, tüm bağımlılıkları giden bir paket tamamen kararsız olarak kabul edilir: başka şeyler kullanır, ancak hiçbir şey kullanmaz. Bu durumda, sadece o şeyin somut olması mantıklıdır. Ayrıca, başka hiçbir şey kullanmadığı için değiştirilmesi en kolay kod türü olacaktır ve bu nedenle kod değiştirilirse başka hiçbir şey kırılamaz.

Bu arada, bir veya daha fazla şey tarafından kullanılan bir paketle tam bir "istikrar" senaryosuna sahip olduğunuzda, ancak yazılım tarafından kullanılan merkezi bir paket gibi kendi başına bir şey kullanmıyorsa, Martin bu şeyin olması gerektiğini söylüyor Öz. Bu, temel olarak bağımlılıkların hem düşük hem de yüksek düzey kod için soyutlamalara eşit olarak akması gerektiğini belirten Bağımlılık Ters Çevirme Prensibi olan SOLI (D) DIP kısmı tarafından da güçlendirilmiştir.

Yani, bağımlılıklar eşit olarak "istikrara" doğru akmalı ve daha kesin olarak, bağımlılıklar giden bağımlılıklardan daha fazla bağımlılığa sahip paketlere doğru akmalı ve ayrıca bağımlılıklar soyutlamalara doğru akmalıdır. Bunun arkasındaki mantığın özü, soyutlamaların, bir alt tipi diğerine ikame etmek için nefes alma alanı sağlaması ve arabirimi uygulayan beton parçaların, soyut arabirime gelen bağımlılıkları bozmadan değişmesi için esneklik sunmasıdır.

Soyutlamalara bağlı olmanın önemli dezavantajları var mı?

Aslında, en azından benim alanım için Martin ile aynı fikirde değilim ve burada, "değişme nedenleri eksik" olduğu gibi, yeni bir "istikrar" tanımı getirmem gerekiyor. Bu durumda, bağımlılıkların istikrara doğru akması gerektiğini söyleyebilirim, ancak soyut arayüzler soyut arayüzler kararsızsa (Martin'in tekrar tekrar değişmeye eğilimli olduğu gibi, "kararsız" tanımımla) yardımcı olmaz. Geliştiriciler soyutlamaları düzeltemezse ve istemciler sürekli olarak yazılımı eksik veya etkisiz modelleme girişimlerini gerçekleştirecek şekilde fikirlerini değiştirirlerse, artık sistemi basamaklı bağımlılık kırıcı değişikliklere karşı korumak için soyut arabirimlerin gelişmiş esnekliğinden faydalanmıyoruz. . Kişisel durumumda, AAA oyunlarında bulunanlar gibi ECS motorları buldum,en somut : ham verilere doğru, ancak bu tür veriler son derece kararlıdır ("olduğu gibi," hiçbir zaman değiştirilmesi gerekmemektedir "). Gelecekteki değişikliklerin gerektirdiği bir şeyin, SE kararlarına rehberlik ederken efferent'in toplam kuplajlara oranından daha yararlı bir metrik olma olasılığını sıklıkla buldum.

Bu yüzden, DIP'yi biraz değiştirirdim ve sadece, bu bileşenlerin soyut arabirimler mi yoksa ham veri mi olduğuna bakılmaksızın, "bağımlılıklar daha fazla değişiklik gerektirme olasılığı en düşük bileşenlere doğru akmalıdır" diyorum. Benim için önemli olan, doğrudan tasarım kırma değişiklikleri gerektirme olasılığıdır. Soyutlamalar, yalnızca bir şey soyut olarak bu olasılığı azaltırsa, bu istikrar bağlamında faydalıdır.

Yazılımın ihtiyaçlarını önceden tahmin eden ve istikrarlı (değişmeyen) soyutlamalar tasarlayan iyi mühendisler ve müşteriler için geçerli olabilecek birçok bağlam için, bu soyutlamalar onlara somut uygulamaları değiştirmek için ihtiyaç duydukları tüm solunum odasını sunar. Ancak bazı alanlarda, soyutlamalar kararsız olabilir ve yetersiz olmaya eğilimli olabilirken, motor için gerekli verilerin önceden tahmin edilmesi ve kararlı hale getirilmesi çok daha kolay olabilir. Dolayısıyla, bu durumlarda, bağımlılıkların soyutlamalardan ziyade verilere doğru akması için sürdürülebilirlik açısından (sistemi değiştirme ve genişletme kolaylığı) aslında daha yararlı olabilir. Bir ECS'de en kararsız parçalar (en sık değiştirilen parçalarda olduğu gibi) tipik olarak sistemlerde (PhysicsSystemörneğin), en kararlı parçalar (en azından değiştirilmesi muhtemel olan), sadece MotionComponenttüm sistemlerin kullandığı ham verilerden ( örn.) oluşan bileşenlerdir .