Yazılımımın çok fazla soyutlama ve çok fazla tasarım desenine sahip olduğunu nasıl söyleyebilirim, ya da tam tersi, daha fazlasına sahip olup olmadığını nasıl bilebilirim?

Çalıştığım geliştiriciler bu konularla ilgili farklı programlama yapıyorlar.

Bazıları her küçük işlevi soyutlar, mümkün olan yerlerde tasarım kalıplarını kullanır ve herhangi bir maliyette fazlalıktan kaçınır.

Ben dahil diğerleri daha pragmatik olmaya çalışıyorlar ve her tasarım desenine tam olarak uymayan, ancak daha az soyutlama uygulandığından anlaşılması daha hızlı olan kodlar yazmaya çalışıyorlar.

Bunun bir takas olduğunu biliyorum. Projeye ne zaman yeterli soyutlama yapıldığını nasıl söyleyebilirim ve daha fazla ihtiyacı olduğunu nasıl bilebilirim?

Örneğin, genel önbellekleme katmanı Memcache kullanılarak yazıldığında. Gerçekten ihtiyacımız mı Memcache, MemcacheAdapter, MemcacheInterface, AbstractCache, CacheFactory, CacheConnector, ... ya da bu bakımı daha kolay ve hala iyi kod bu sınıflara sadece yarısı kullanılırken nedir?

Bunu Twitter'da buldum:

( https://twitter.com/rawkode/status/875318003306565633 )

Bir yemek için kaç tane malzeme gereklidir? Bir araç inşa etmek için kaç parçaya ihtiyacınız var?

Küçük bir uygulama değişikliği, tüm kodunuzun üzerinde bir değişiklik basamaklarına yol açtığında çok az soyutlamanın olduğunu biliyorsunuzdur . Doğru soyutlamalar, kodun değiştirilmesi gereken kısmının izole edilmesine yardımcı olacaktır.

Küçük bir arayüz değişikliği, farklı seviyelerde, kodunuzun her yerinde bir değişiklik kademesine yol açtığında çok fazla soyutlamaya sahip olduğunuzu biliyorsunuzdur . Arabirimi iki sınıf arasında değiştirmek yerine, yalnızca bir özellik eklemek veya bir yöntem argümanının bir türünü değiştirmek için düzinelerce sınıfı ve arayüzü değiştirdiğinizi fark edersiniz.

Bunun yanında, bir rakam vererek soruyu cevaplamanın gerçekten bir yolu yok. Soyutlamaların sayısı projeden projeye, bir dilden diğerine ve hatta bir geliştiriciden diğerine aynı olmayacak.

Tasarım desenleriyle ilgili sorun, "çekiç tutarken her şey bir çiviye benziyor" atasözü ile özetlenebilir. Bir tasarım deseni uygulama eylemi, programınızı hiçbir şekilde iyileştirmez. Aslında, bir tasarım deseni ekliyorsanız daha karmaşık bir program yaptığınızı savunuyorum. Soru, tasarım modelini iyi kullanıp kullanmamanız ya da yapmamanızdır ve bu, "Ne zaman çok fazla soyutlamamız var?" Sorusunun özüdür.

Tek bir uygulama için bir arayüz ve soyut bir süper sınıf oluşturuyorsanız, projenize gereksiz ve gereksiz iki ek bileşen eklediniz. Arabirim sunmanın amacı, nasıl çalıştığını bilmeden programınız boyunca eşit olarak idare edebilmektir. Soyut bir süper sınıfın amacı, uygulamalar için temel davranış sağlamaktır. Yalnızca bir uygulamanız varsa, tüm karmaşıklık arayüzlerini ve mutlak sınıfların sağladığı ve avantajlarından hiçbirini alamayacaksınız .

Benzer şekilde, bir Fabrika modeli kullanıyorsanız ve yalnızca süper sınıfta bulunan işlevleri kullanmak için kendinizi bir sınıf yaratırken bulursanız, Fabrika modeli kodunuza herhangi bir avantaj getirmez. Projenize yalnızca kaçınılabilecek ek bir sınıf eklediniz.

TL; DR Benim açımdan soyutlamanın amacı kendi içinde soyut değildir. Programınızda çok pratik bir amaca hizmet eder ve bir tasarım deseni kullanmaya ya da bir arayüz oluşturmaya karar vermeden önce, kendinize sormanız gerekir, ek karmaşıklığa rağmen programın daha sağlam olmasına rağmen programın anlaşılması daha kolay mı? ek karmaşıklığa rağmen (tercihen her ikisi de). Cevabınız hayırsa veya belki ise, neden bunu yapmak istediğinizi düşünmek için birkaç dakikanızı ayırın ve eğer mümkünse kodunuza soyutlama gerekmeden, belki de daha iyi bir şekilde yapılabilir.

TP: DR;

Aşağısında çok az veya çok fazla olan, "gerekli" bir dizi soyutlama seviyesi olduğunu düşünmüyorum. Grafik tasarımda olduğu gibi, iyi OOP tasarımı görünmez olmalı ve verilmesi için alınmalıdır. Kötü tasarım her zaman bir boğaz başparmak gibi yapışır.

Uzun cevap

Büyük olasılıkla, kaç tane soyutlama seviyesi oluşturduğunuzu asla bilemeyeceksiniz.

Soyutlama seviyelerinin çoğu bize görünmez ve kabul edildik.

Bu akıl yürütme beni bu sonuca götürüyor:

Soyutlamanın temel amaçlarından biri, programcının her zaman sistemin tüm çalışmasını göz önünde bulundurma gerekliliğini kurtarmasıdır. Eğer tasarım sizi bir şey eklemek için sistem hakkında çok fazla şey bilmeye zorlarsa , o zaman muhtemelen çok az soyutlama olacaktır. Bence kötü soyutlama (zayıf tasarım, anemik tasarım veya aşırı mühendislik) bir şeyler eklemek için sizi çok fazla şey bilmeye zorlayabilir. Bir uçta, bir tanrı sınıfına veya bir grup DTO'ya dayanan bir tasarımımız var, diğer uçta ise, merhaba bir dünyaya ulaşmak için sayılamayan çemberlerden atlamanızı sağlayan OR / kalıcılık çerçevelerimiz var. Her iki durumda da seni çok fazla şey biliyorsun.

Kötü bir soyutlama Gauss ziline yapışır ve bir kez tatlı bir yeri geçtiğinizde yola çıkmaya başlar. Öte yandan, iyi bir soyutlama görünmezdir ve çok fazla bir şey olamaz çünkü orada olduğunu fark etmiyorsunuz. API katmanları, ağ protokolleri, kütüphaneler, işletim sistemi kütüphaneleri, dosya sistemleri, donanım katmanları vb. Üzerinde kaç katman bulunduğunu ve uygulamanızın kurulduğunu ve kabul edildiğini düşünün.

Soyutlamanın diğer ana amacı bölümlendirmedir, bu nedenle hatalar, çift teknenin ve ayrı tankların aksine, belirli bir alanın ötesine nüfuz etmez, gövdenin bir kısmı bir delik olduğunda bir geminin tamamen taşmasını önler. Kodda yapılacak değişiklikler görünüşte alakasız alanlarda hata yaratırsa, o zaman şans çok azdır.

Tasarım kalıpları basitçe sorunların ortak çözümleridir. Tasarım kalıplarını bilmek önemlidir, ancak bunlar sadece iyi tasarlanmış kodun belirtileridir (neden iyi kod, dördüncü tasarım kalıpları grubunun çetesinden silinebilir).

Soyutlamalar çitler gibidir. Programınızın bölgelerinin test edilebilir ve değiştirilebilir parçalara ayrılmasına yardımcı olurlar (kırılgan olmayan katı olmayan kodlar yapmak için gerekenler). Ve çok çitler:

• Boyutlarını en aza indirmek için doğal arayüz noktalarındaki soyutlamaları istiyorsunuz.

• Onları değiştirmek istemezsin.

• Bağımsız olabilecek şeyleri ayırmalarını istiyorsunuz.

• Birinin yanlış yerde olması, sahip olmamaktan daha kötü.

• Büyük sızıntıları olmamalıdır .

üstlenmeden

Şimdiye kadar bir kez bile "refactoring" kelimesini görmedim. Yani, işte başlıyoruz:

Yeni bir özelliği mümkün olduğunca doğrudan uygulamaktan çekinmeyin. Yalnızca tek, basit, sınıfınız varsa, bunun için bir arayüze, bir üst sınıfa, bir fabrikaya vs. ihtiyacınız yoktur.

Eğer sınıfı çok şişkin olacak şekilde genişlettiğinizi fark ederseniz, o zaman onu parçalara ayırmanın zamanı gelmiştir. O zaman bunu gerçekten nasıl yapman gerektiğini düşünmek çok mantıklı geliyor.

Desenler bir zihin aracıdır

Desenler veya daha özel olarak dört çetenin "Tasarım Desenleri" kitabı diğer nedenlerin yanı sıra harikadır, çünkü geliştiricilerin düşünmesi ve konuşması için bir dil oluştururlar. "Gözlemci", "fabrika" veya "cephe" ve herkes tam olarak ne anlama geldiğini biliyor .

Bu yüzden benim düşüncem, her geliştiricinin en azından orijinal kitaptaki kalıplar hakkında geçen bir bilgiye sahip olması gerektiği, basitçe OO kavramları hakkında her zaman temellerini açıklamak zorunda kalmadan konuşabilmesi gerektiğidir. Yapılması gereken her ihtimalde kalıpları gerçekten kullanmalı mıyım ? Büyük olasılıkla değil.

Kütüphaneler

Kütüphaneler büyük olasılıkla çok az yerine çok sayıda model tabanlı seçimler tarafında hata yapmak için olabilir bir alandır. Bir şeyi "şişman" bir sınıftan daha fazla desen türevli bir şeye (genellikle daha küçük ve daha küçük sınıflar anlamına gelir) değiştirmek, arayüzü radikal biçimde değiştirecektir; ve bu genellikle bir kütüphanede değiştirmek istemediğiniz bir şeydir, çünkü kütüphanenizin kullanıcısı için gerçekten ilgi çekici olan tek şey budur. İşlevselliğinizi dahili olarak nasıl ele aldığınızla daha az ilgilenmezler, ancak yeni bir API ile yeni bir sürüm çıkardığınızda programlarını sürekli değiştirmek zorunda kalırlarsa çok özen gösterirler.

Soyutlamanın amacı, öncelikle soyutlamanın tüketicisine, yani soyutlamanın müşterisine, diğer programcılara ve sıklıkla kendinize getirilen değer olmalıdır.

Soyutlamaları tüketen bir müşteri olarak, programlama işinizi yapmak için birçok farklı soyutlamayı karıştırmanız ve eşleştirmeniz gerektiğini fark ederseniz, potansiyel olarak çok fazla soyutlama olabilir.

İdeal olarak, katmanlama, bir takım düşük soyutlamaları bir araya getirmeli ve bunun, tüketicilerin soyutlamaları temel alan herhangi bir şeyle uğraşmak zorunda kalmadan kullanabilecekleri basit ve üst düzey bir soyutlama ile değiştirmelidir. Altındaki soyutlamalar ile uğraşmak zorunda kalırlarsa, katman sızdırıyor (eksik olma yoluyla). Tüketici çok fazla soyutlama ile uğraşmak zorunda kalırsa, katmanlaşma belki de eksiktir.

Tüketici programcılar için soyutlamaların değerini düşündükten sonra, DRY-in gibi uygulamaların değerlendirmesini ve değerlendirmesini yapabiliriz.

Evet, her şey bakımı kolaylaştırmakla ilgili, ancak önce kalite soyutlamaları ve katmanları sağlayarak tüketicilerimizin bakımının kötü durumunu göz önünde bulundurmalı, sonra da artıklıktan kaçınma gibi uygulama yönleri açısından kendi bakımımızı kolaylaştırmayı düşünmeliyiz.

Örneğin, genel önbellekleme katmanı Memcache kullanılarak yazıldığında. Gerçekten de Memcache, MemcacheAdapter, MemcacheInterface, AbstractCache, CacheFactory, CacheConnector, ... ya da bu sınıfların sadece yarısını kullanırken kodları korumak ve hala iyi kodlara ihtiyacımız var mı?

Müşterinin bakış açısına bakmalıyız ve eğer hayatları kolaylaştıysa, o zaman iyidir. Hayatları daha karmaşıksa o zaman kötüdür. Bununla birlikte, bu şeyleri birlikte kullanımı basit bir şeye saran eksik bir katman olabilir. Dahili olarak, bunlar uygulamanın bakımını daha iyi hale getirebilir. Bununla birlikte, şüphelendiğiniz gibi, sadece üzerinde çalışılması da mümkündür.

Soyutlama, kodun daha kolay anlaşılmasını sağlamak için tasarlanmıştır. Bir soyutlama katmanı işleri daha kafa karıştırıcı hale getirecekse, yapmayın.

Amaç, doğru sayıda soyutlama ve arabirim kullanmaktır:

• geliştirme süresini en aza indirin
• kod bakımını en üst düzeye çıkarmak

Sadece gerektiğinde soyut

1. Süper bir sınıf yazdığınızı keşfettiğinizde
2. Önemli kod yeniden kullanıma izin verdiğinde
3. Özeti çıkarmak kodun önemli ölçüde daha net ve okunması kolay hale gelmesini sağlarsa

Ne zaman soyut yapmayın

1. Bunu yapmak, kod kullanımında veya netlikte bir avantaj sağlamaz
2. Bunu yapmak kodun faydasız bir şekilde daha uzun / karmaşık olmasını sağlar

Bazı örnekler

• Programınızın tamamında yalnızca bir önbellek olacaksa, bir üst sınıfa gireceğinizi düşünmüyorsanız, özetlemeyin
• Üç farklı arabellek türünüz varsa, hepsine ortak bir arabirim soyutlama kullanın

Bunun tartışmalı bir meta-cevap olabileceğini düşünüyorum ve partiye biraz geç kaldım, ancak buradan bahsetmek çok önemli çünkü bence nereden geldiğini biliyorum.

Tasarım modellerinin kullanımındaki sorun, öğretildiklerinde şöyle bir durum sunmalarıdır:

Bu özel senaryoya sahipsiniz. Kodunuzu bu şekilde düzenleyin. İşte akıllı görünümlü, ancak biraz da olsa örnek.

Sorun şu ki, gerçek mühendislik yapmaya başladığınızda, işler bu kadar kuru ve kuru değildir. Okuduğunuz tasarım deseni, çözmeye çalıştığınız soruna tam olarak uymayacaktır. Kullandığınız kütüphanelerin, bu kalıpları açıklayan metinde belirtilen her şeyi kendi özel yöntemleriyle tamamen ihlal ettiği anlamına gelmez. Sonuç olarak, yazdığınız kod "yanlış hissettiriyor" ve buna benzer sorular soruyorsunuz.

Buna ek olarak, yazılım mühendisliği hakkında konuşurken şunları söyleyen Andrei Alexandrescu'dan alıntı yapmak isterim:

Yazılım mühendisliği, belki de diğer mühendislik disiplinlerinden daha fazla, zengin bir çeşitlilik sergiliyor: Aynı şeyi birçok doğru şekilde yapabilirsiniz ve doğru ile yanlış arasında sonsuz farklılıklar vardır.

Belki bu biraz abartıdır, ancak bence kodunuzda neden daha az kendine güvenebileceğinize dair ek bir neden açıklıyor.

Böyle zamanlarda, Insomniac'taki oyun motoru lideri Mike Acton'un peygamberlik sesi kafamda çığlık atar:

VERİLERİNİZİ BİLİN

Programınızın girdileri ve istenen çıktılar hakkında konuşuyor. Ve sonra Efsanevi Adam Ayından bu Fred Brooks'un cevheri var:

Bana akış şemalarını göster ve masalarını gizle, ben de gizemli olmaya devam edeceğim. Bana masalarını göster ve genellikle akış çizelgelerine ihtiyacım olmayacak; açık olacaklar.

Öyleyse, yerinde olsam, tipik giriş davama dayanarak sorunumu ve istenen doğru çıktıyı elde edip etmediğini düşünürdüm. Ve bunun gibi sorular sorun:

• Programımın çıktı verileri doğru mu?
• En yaygın giriş davam için verimli / hızlı üretiliyor mu?
• Kodum, hem ben hem de takım arkadaşlarım için yerel olarak gerekçelendirecek kadar kolay mı? Değilse, daha basit hale getirebilir miyim?

Bunu yaptığınızda, "kaç tane soyutlama veya tasarım desenine ihtiyaç duyulduğu" sorusu cevaplamak çok daha kolay hale gelir. Kaç tane soyutlama katmanına ihtiyacınız var? Bu hedeflere ulaşmak için gereken kadar, daha fazla değil. “Peki ya tasarım kalıpları? Hiç kullanmadım!” Peki, yukarıdaki hedeflere bir model doğrudan uygulanmadan gerçekleştirilirse, sorun değil. Çalışmasını sağlayın ve bir sonraki soruna geçin. Verilerinizden başlayın, koddan değil.

Yazılım Mimarisi Dilleri Keşfetiyor

Her yazılım katmanında, sizin (veya iş arkadaşlarınızın) bir sonraki daha yüksek katman çözümünü ifade etmek istediğiniz dili yaratırsınız (bu nedenle, yazımdaki bazı doğal dil analoglarını kullanacağım). Kullanıcılarınız yıllarca bu dili okumayı veya yazmayı öğrenerek geçirmek istemiyor.

Bu görüş mimari meselelere karar verirken bana yardımcı oluyor.

Okunabilirlik

Bu dil kolayca anlaşılmalıdır (bir sonraki katman kodunu okunaklı hale getirerek). Kod, yazıldığından çok daha sık okunur.

Bir kavram bir kelime ile ifade edilmelidir - bir sınıf ya da arayüz kavramı açıklamalıdır. (Slavonik diller tipik olarak bir İngilizce fiil için iki farklı kelimeye sahiptir, bu yüzden iki kez kelime öğrenmek zorundasınız. Tüm doğal diller çoklu kavramlar için tek kelimeler kullanır).

Ortaya çıkardığınız kavramlar sürpriz içermemelidir. Bu esas olarak get ve set-method vb. Kuralları isimlendirmek ve tasarım kalıpları yardımcı olabilir çünkü standart bir çözüm kalıbı sağlıyorlar ve okuyucu "Tamam, nesneleri bir fabrikadan alıyorum" u görüyor ve bunun ne anlama geldiğini biliyor. Fakat basit bir şekilde somut bir sınıfı somutlaştırmak işi yaparsa bunu tercih ederim.

Kullanılabilirlik

Dilin kullanımı kolay olmalıdır ("doğru cümleleri" formüle etmeyi kolaylaştırır).

Tüm bu MemCache sınıfları / arayüzleri bir sonraki katmana görünür hale gelirse, kullanıcı için bu kelimelerin hangisinin bir önbellek kavramı için ne zaman ve nerede kullanılacağını anlayana kadar dik bir öğrenme eğrisi oluşturur.

Yalnızca gerekli sınıfları / yöntemleri ortaya çıkarmak, kullanıcılarınızın ihtiyaç duyduğu şeyi bulmasını kolaylaştırır (bkz. Antoine de Saint-Exupery'deki DocBrowns alıntı). Uygulama sınıfı yerine bir arabirim göstermek, bunu daha kolay hale getirebilir.

Yerleşik bir tasarım modelinin uygulanabileceği bir işlevsellik ortaya koyarsanız, bu tasarım modelini takip etmek farklı bir şey icat etmekten daha iyidir. Kullanıcı, bir tasarım modelini takip eden API'leri tamamen farklı konseptlerden daha kolay anlayacaktır (İtalyanca biliyorsanız, İspanyolca size Çince'den daha kolay olacaktır).

özet

Kullanımı kolaylaştırırsa soyutlamalar yapın (ve hem soyutlamayı hem de uygulamayı korumanın temel yüküdür).

Eğer kodunuzun önemsiz bir alt görevi varsa, "beklenen şekilde" çözün, yani farklı bir tekerleği yeniden icat etmek yerine uygun tasarım modelini izleyin.

Dikkate alınması gereken önemli şey, işletme mantığınızı gerçekten işleyen kodun ne kadarının bu önbellekleme ile ilgili sınıflar hakkında bilmesi gerektiğidir. İdeal olarak kodunuz yalnızca oluşturmak istediği önbellek nesnesine ve belki de bir kurucu yöntem yeterli değilse bu nesneyi oluşturacak bir fabrikaya önem vermelidir.

Kullanılan kalıpların sayısı veya kalıtım derecesi, her bir seviye diğer geliştiricilere haklı olduğu sürece çok önemli değildir. Bu, her bir ilave seviyenin haklılaştırılması zor olduğundan, gayrı resmi bir limit yaratmaktadır. Daha önemli kısım, işlevsel veya iş gereksinimlerindeki değişikliklerden kaç soyutlama seviyesinin etkilendiğidir. Tek bir gereksinim için yalnızca bir seviyede değişiklik yapabilirseniz, o zaman çok fazla soyutlanmış değilsiniz veya kötü şekilde soyutlanmamışsınız, eğer birden fazla ilgisiz değişiklik için aynı seviyeyi değiştirirseniz, muhtemelen soyutlanmış ve endişeleri ayrı tutmanız gerekir.

İlk olarak, Twitter teklifi sahtedir. Yeni geliştiricilerin bir model yapması gerekiyor, soyutlamalar genellikle "resim çekmelerine" yardımcı olur. Tabii soyutlamalar elbette mantıklı.

İkincisi, probleminiz çok fazla veya çok az soyutlama değil, görünüşe göre bu şeyler hakkında kimsenin karar veremeyeceği açık. Hiç kimse kodun sahibi değil, tek bir plan / tasarım / felsefe uygulanmıyor, sıradaki bir adam o an için uygun görünen her şeyi yapabilir. Hangi stile gidersen git, biri olmalı.