Soyutlama düzeyleri nasıl belirlenir

Bugün "Temiz kod" adlı bir kitap okuyordum ve bir paragrafa rastladım, yazar bir işlev başına soyutlama seviyelerinden bahsediyordu, bazı kodları düşük / orta / yüksek soyutlama seviyesi olarak sınıflandırdı.

Benim sorum, soyutlama seviyesini belirleme kriterleri nedir?

Paragrafı kitaptan alıntı yapıyorum:

Fonksiyonlarımızın “bir şeyi” yaptığından emin olmak için, fonksiyonumuzdaki ifadelerin aynı soyutlama seviyesinde olduğundan emin olmalıyız. 3-1 numaralı listenin bu kuralı nasıl ihlal ettiğini görmek kolaydır. Burada, getHtml () gibi çok yüksek bir soyutlama düzeyinde olan kavramlar vardır; orta derecede bir soyutlama düzeyinde olan diğerleri, örneğin: String pagePathName = PathParser.render (pagePath); ve yine de oldukça düşük olan diğerleri:

Yazar, soyutlamalar (hiyerarşik girinti madeni) hakkında konuşan kısmın "Yukarıdan Aşağıya Okuma Kodu" alt bölümünde şöyle olduğunu açıklar:

[...] Programı , her biri mevcut soyutlama seviyesini tanımlayan ve sonraki TO paragraflarını bir sonraki aşamada referanslayan bir TO paragrafı seti gibi okuyabilmeyi istiyoruz .

• Kurulumları ve gözyaşlarını dahil etmek için kurulumları, ardından test sayfası içeriğini ve ardından gözyaşlarını da dahil ediyoruz.
  
  • Kurulumları dahil etmek için, eğer bu bir süitse, süitlik kurulumunu dahil ettik, sonra da normal kurulumu dahil ediyoruz.
    • Suite kurulumunu eklemek için, "SuiteSetUp" sayfası için ana hiyerarşiyi araştırır ve o sayfanın yoluna bir include ifadesi ekleriz.
      • Ebeveynini aramak için ...

Bununla devam edecek kod şöyle olurdu:

public void CreateTestPage()
{
    IncludeSetups();
    IncludeTestPageContent();
    IncludeTeardowns();
}

public void IncludeSetups()
{
    if(this.IsSuite())
    {
        IncludeSuiteSetup();
    }

    IncludeRegularSetup();
}

public void IncludeSuiteSetup()
{
    var parentPage = FindParentSuitePage();

    // add include statement with the path of the parentPage
}

Ve bunun gibi. İşlev hiyerarşisinde daha derine indiğinizde, soyutlama seviyelerini değiştirmelisiniz. Yukarıdaki örnekte IncludeSetups, IncludeTestPageContentve IncludeTeardownshepsi aynı soyutlama düzeyindedir.

Kitapta verilen örnekte, yazar büyük fonksiyonun çok özel olan ve sadece bir şeyi yapan daha küçük fonksiyonlara bölünmesi gerektiğini öne sürüyor. Doğru yapılırsa, yeniden yapılandırılmış işlev buradaki örneklere benzer görünecektir. (Yenilenmiş versiyon, kitaptaki 3-7. Listede verilmiştir.)

Bence bu soruyu anlamalısın, soyutlamanın ne olduğunu anlamalısın. (Resmi bir tanım bulamadığım için çok tembelim, bu yüzden ölmek üzere olduğumdan eminim, ama işte gidiyor ...) Karmaşık bir konuya girdiğinizde veya ayrıntılarını çoğaldığında ve sakladığınızda bir soyutlama olur. Bu nesnenin özünü hala tanımlayan işlevselliği ortaya koyarken.

Kitabın sana verdiği örneğin bir ev olduğuna inanıyorum. Eve çok detaylı bir şekilde bakarsanız, panolardan, çivilerden, pencerelerden, kapılardan oluştuğunu görürsünüz ... Ama bir fotoğrafın yanındaki evin çizim karikatürü hala eksik olsa bile, bir evdir. bu ayrıntıların çoğu.

Yazılım ile aynı şey. Programladığınız zaman, tıpkı kitabın tavsiye ettiği gibi, yazılımınızı katman olarak düşünmeniz gerekir. Belirli bir program, yüzden fazla katmana kolayca sahip olabilir. En altta, bir CPU üzerinde çalışan montaj talimatlarına sahip olabilirsiniz, daha yüksek bir seviyede bu talimatlar, disk G / Ç yordamları oluşturmak için birleştirilebilir, ancak daha yüksek bir seviyede, Disk I / ile çalışmanıza gerek yoktur O doğrudan, Windows işlevlerini bir dosyayı açmak / okumak / yazmak / aramak / kapatmak için kullanabilirsiniz. Bunların hepsi kendi uygulama kodunuza girmeden önce bile soyutlamalar.

Kodunuzda, soyutlama katmanları devam eder. Daha düşük seviyeli string / network / data manipülasyon yordamlarınız olabilir. Daha yüksek bir seviyede bu rutinleri kullanıcı yönetimi, kullanıcı arayüzü katmanı, veritabanı erişimi tanımlayan alt sistemlerde birleştirebilirsiniz. Yine bir başka katman, bu alt sistemler daha büyük bir kurumsal sistemin bir parçası olmak için bir araya gelen sunucu bileşenleriyle birleştirilebilir.

Bu soyutlama katmanlarının her birinin anahtarı, her birinin önceki katman (lar) tarafından maruz bırakılan ayrıntıları gizlemesi ve bir sonraki katman tarafından tüketilecek çok temiz bir arayüz sunmasıdır. Bir dosyayı açmak için, tek tek sektörlerin nasıl yazılacağını veya hangi donanımın işlemeyi keseceğini bilmeniz gerekmez. Ancak, soyutlama katmanı zincirinde hareket etmeye başlarsanız, kesinlikle Write () işlev çağrısından, sabit sürücü denetleyicisine gönderilen talimatın sonuna kadar izleyebileceksiniz.

Yazarın size yapması gereken, bir sınıfı veya işlevi tanımladığınızda, hangi katman olduğunuzu düşünün. Alt sistemleri ve kullanıcı nesnelerini yöneten bir sınıfınız varsa, aynı sınıf düşük düzeyli dize işlemi gerçekleştirmemeli veya yalnızca soket aramaları yapmak için bir sürü değişken içermelidir. Bu, soyutlama katmanlarını geçmenin ve aynı zamanda tek bir sınıf / işleve sahip olmanın ihlali olacaktır (SRP - Tek Sorumluluk İlkesi).

Benim sorum, soyutlama seviyesini belirleme kriterleri nedir?

Soyutlama seviyesinin açık olması gerekiyordu. Programlama dilinin bir parçası değil, sorun alanının bir parçasıysa soyuttur. "Çok soyut" == "gerçek değil" == "sorunlu alan" dan daha açık olmak zordur. Ve "soyut değil == somut == dilin bir parçası". Soyutlama seviyesine karar vermede önemsiz olması gerekiyordu. Hiç incelik olmaması gerekiyordu.

.append("\n")soyut değil. Sadece bir karaktere bir karakter ekler. Bu somut olurdu. Soyut değil.

String pagePathName = PathParser.render(pagePath);Strings ile ilgilidir. Somut şeyler. Kısmen somut programlama dili özellikleri. Kısmen soyut “yol” ve “ayrıştırıcı” kavramları ile çalışmak.

getHtml(); Özet. "İşaretleme" ile ilgilenir ve önemsiz, somut, dil özellikleri olmayan şeyler.

Özet == bir dil özelliği değildir.

Somut == bir dil özelliği.

Soyutlama seviyesinin basit olduğunu düşünüyorum ... eğer kod satırı yöntemin tek sorumluluğunu doğrudan uygulamazsa, başka bir soyutlama seviyesidir. Örneğin, yöntem adım SaveChangedCustomers () ise ve TÜM müşterilerin listesini parametre olarak alıyorsa, tek sorumluluk değiştirilmiş olan müşterileri listeden kurtarmaktır:

foreach(var customer in allCustomers)
{
    if (CustomerIsChanged(customer)
        customer.Save();
}

Genellikle, CustomerIsChanged () yöntemini çağırmak yerine, müşterinin foreach döngüsüne gömülü olarak değiştirilip değiştirilmediğini belirleyen mantığı bulacaksınız. Müşteri kaydının değişip değişmediğinin belirlenmesi bu yöntemin sorumluluğu DEĞİLDİR! Farklı bir soyutlama seviyesidir. Ancak, bu belirlemeyi yapma mantığı yalnızca bir kod satırı ise ne olur? Önemli değil !!! Farklı bir soyutlama seviyesidir ve bu yöntemin dışında olması gerekir.