g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Yazar Nan Zhiwen

Düzenle Xiaozhi

"Temiz kod basit ve anlaşılırdır. Temiz kod güzel bir düz yazı gibidir. Temiz kod asla tasarımcının niyetini gizlemez ve temiz soyutlama ve basit kontrol ifadeleriyle doludur." Kod nasıl daha temiz hale getirilir? Cevap yeniden düzenleme!

Önüne yaz

Mevcut yazılım sistemi geliştirme zorluğu temelde karmaşıklığı ve ölçeğinde yatmaktadır ve kullanıcı gereksinimleri, kullanıcı yazılım gereksinimlerini karşılamak için sistem kodlamasından önce tüm tasarımları tamamlamak için Winston Royce şelale modelinin beklediği gibi artık değildir. Bilgi patlaması teknolojisinin hızla değiştiği bu çağda, talepler sürekli değişiyor.Sonra 2001 yılında ABD'nin Utah eyaletindeki Snowbird kayak merkezinde toplanan endüstrideki 17 büyük inek "Çevik" (Çevik) önerisinde bulundu. ) Yazılım geliştirme değerleri ve onların çabaları ile sektörde popüler olmaya başladı.

"Kod Temizliği" kitabında, bir tür yazılım kalitesi, sürdürülebilir gelişimin sadece proje mimari tasarımı değil, kod kalitesiyle de yakından ilgili olduğu öne sürülmektedir.Kodun temizliği, kalite ile doğru orantılıdır.Temiz bir kod kalitelidir. Güvenilirdir ve ekip geliştirme, bakım sonrası ve yeniden düzenleme için iyi bir temel oluşturmuştur.

Ardından yazar, tamamen boş bir teoriye dayalı kod temizliğinden bahsetmek yerine, gerçek geliştirme sürecinde kod optimizasyonunun pratik ayrıntılarına nasıl dikkat ettiğimizi tartışmak için önceki yeniden düzenleme pratik deneyimimi birleştirecek.

Kodun nasıl optimize edileceğini özellikle tartışmadan önce, ilk olarak "kötü kod kokusu" ile neyin kastedildiğini ve "temiz ve mükemmel kod" ile ne kastedildiğini tartışmalı ve açıklamalıyız. Çünkü tüm optimizasyonun kökü, bizim olağan geliştirme sürecimizden ve geliştiricilerin kendileri tarafından üretilen "kötü kod kokusundan" gelir.

Kötü kod kokusu

"Bebek bezi kötü kokuyorsa, değiştirin." - Çocuk yetiştirme felsefesi üzerine büyükanne Beck diyor. Benzer şekilde, kod kötü kokuyorsa, mükemmel temiz kod yapmak için onu yeniden düzenlememiz gerekir.

Kodun kötü kokusundan bahsederken, Duplicated Code en büyük darbeyi taşır. Yazılım sistemlerinde tekrar kötüdür. Endişelerin ve nesneye yönelik tasarım ilkelerinin tanıdık ayrımı, tekrarı azaltmak ve yeniden kullanımı iyileştirmek içindir. Kendinizi tekrar etmeyin (KURU). KURU ilkesiyle ilgili olarak, olağan geliştirme sürecinde kesinlikle buna uymalıyız.

İkincisi, başka kötü kokular da var: çok uzun işlev (Uzun Yöntem), çok büyük sınıf (Büyük Sınıf), çok uzun parametre listesi (Uzun Parametre Listesi), yedek sınıf (Tembel Sınıf), gereksiz işlev (Tembel İşlev) işe yaramaz Kullanılmayan İşlev Parametresi, Karmaşıklık 10'un üzerinde, Özellik Kıskançlığı, Anahtarın Kötüye Kullanımı, Aşırı Geniş Tasarım, Okunamaz Veya zayıf okunabilir değişken adları ve işlev adları (okunmamış değişken veya işlev adları), Farklı Arayüzlere sahip Alternatif Sınıflar, aşırı bağlı mesaj zincirleri (Mesaj Zincirleri), kafa karıştırıcı geçici alanlar (Geçici Alan), aşırı Çok Fazla Yorum gibi kötü kokular.

Düzenli kod

Düzenli kod nedir? Farklı insanlar farklı görüşleri farklı açılardan açıklayacaktır. Ve benim favorim Grady Booch ("Object-Oriented Analysis and Design" kitabının yazarı) şunları söyledi:

"Temiz kod basit ve anlaşılırdır. Temiz kod güzel bir düz yazı gibidir. Temiz kod asla tasarımcının niyetlerini gizlemez ve temiz soyutlama ve basit kontrol ifadeleriyle doludur."

Temiz kod, basit (basit ama çok basit olmayan) bir tasarımdır. Kodu okuyan kişiler, anlaşılmaz olmak yerine burada neler olup bittiğini açıkça anlayabilirler. Temiz kod, insanları okumak gibi hissettirir. Nesir - sanatın çökelmesi, yazar onu dikkatlice yarattı.

Temiz kod, kötü koku koduyla ilişkilidir.Kötü kokulu kodu temiz koda dönüştürmek bu makalenin odak noktasıdır: kod yeniden düzenlemeyi temizlemenin yolu. Daha sonra, birkaç bakış açısıyla bununla nasıl başa çıkılacağına odaklanacağım. Yazılım, etkili ve ustaca yeniden düzenlenmiştir.

Yeniden düzenleme - Neden

Yazılım geliştirme sürecinde, geliştiriciler genellikle yanlışlıkla kötü kod kokusu üretirler.Özellikle ekip üyelerinin seviyesi düzensiz olduğunda, her bir kişinin deneyimi ve teknik yeteneği farklı aşamalarda kötü kod kokusu üretme olasılığı daha yüksektir. Gereksinimlerin yinelenmesi ve zamanın geçmesi ile kodun kötü kokusu gittikçe daha ciddi hale geliyor ve hatta ekibin geliştirme verimliliğini etkiliyor, o zaman bu problem nasıl çözülür?

Yazılım geliştirme Kodlamadan önce, tüm gereksinimleri önceden bilmemiz imkansızdır.Yazılım tasarımının kesinlikle bazı düşüncesiz ve eksik yönleri olacaktır ve proje gereksinimlerinin değişmesi ile orijinal kod tasarım yapısının artık mevcut gereksinimleri karşılamaması çok muhtemeldir.

Dahası, nadiren bir projeye baştan sona katılma ve sonunda tamamlama fırsatına sahip oluruz, temelde başkalarının kodunu devralırız, projeye baştan yeniden katılsa bile, ekibin diğer üyelerinin kodunu devralmak mümkündür. Hepimiz benzer şikayetler yaşadık. Başkalarının kodunu gördüğümüzde, saçma gibi geliyor. Tamamen yeniden yazma konusunda güçlü bir dürtü var, ancak bu dürtüyü bastırmalı ve tamamen yeniden yazmalısın. Orijinalinden daha iyi olabilir ama zaman kaybıdır.Daha önce var olmayan böcekleri ortaya çıkarmak mümkündür.Ayrıca orijinal tasarımdan daha iyi olmayabilirsiniz.Belki orijinal tasarım, göz önünde bulundurmadığınız bazı dalları veya anormal durumları hesaba katıyor. .

Yazdığımız kod bir gün başkaları tarafından ele geçirilecek. Başkalarının da şu anda olduğu gibi aynı dürtüye sahip olması çok muhtemeldir, bu nedenle geliştiriciler başkalarının kodlarına baktıklarında, bir öğrenme ve huşu içinde keşfetmeleri gerekir. Başkalarının kodunun güzelliği için, bu süreçte, yazılmış daha iyi ve mükemmel kodu seçebilir, özü alabiliriz ve cürufu kaldırabiliriz.Bu temelde, yeniden düzenleme hakkında konuşalım, o zaman yeniden düzenlemeniz iyi bir başlangıç olacaktır.

Kısacası, yapmamız gereken şey yeniden yazmak, yeniden yazmak değil, küçük bir kısmi yeniden düzenleme ile başlamalı ve sonra kademeli olarak tüm modüle genişletmeliyiz.

Yeniden düzenleme rolü

Yeniden düzenleme, yazılım geliştirme ve programlama sürecinde kesinlikle en önemli şeylerden biridir. Peki yeniden düzenleme nedir ve nasıl açıklanır. İsim: Yazılımın iç yapısında yapılan bir ayarlama olan amaç, yazılımın gözlemlenebilir davranışını değiştirmeden anlaşılırlığı artırmak ve değişiklik maliyetini düşürmektir. fiil : Yazılımın gözlemlenebilir davranışını değiştirmeden yazılımın yapısını ayarlamak için bir dizi yeniden düzenleme tekniği kullanın.

Yeniden düzenleme yalnızca mevcut tasarım yapısını iyileştirmekle kalmaz, aynı zamanda anlaşılması zor olan süreci anlamamıza da yardımcı olur. Örneğin karmaşık bir koşullu ifade için, ifadenin işlevini anlamamız uzun zaman alabilir ve sonunda onu uzun bir süre okuduktan sonra anlayabiliriz.Uzun bir süre sonra tekrar unuturuz, şimdi ona baştan bakmamız gerekir. Bu ifade, Çıkarım Yöntemi kullanılarak soyutlanır ve anlaşılması kolay bir ad verilir.Eğer işlev adı iyi adlandırılmışsa, bir dahaki sefere bu kodu tekrar gördüğümüzde, işlevin ne yaptığını bilmek için mantığa bakmamıza gerek yoktur.

Bu işlevin tüm anlaşılmaz kısımlarını uygun şekilde yeniden düzenlersek, her küçük mantığı küçük bir işlevde soyutlarsak ve anlaşılması kolay bir ad verirsek, koda baktığımızda yorum gibi görünebilir. Daha önce olduğu gibi kodun uygulanmasına bakarak bu kodun ne yaptığını tahmin etmeye gerek yok, bu görüşü her zaman ısrarla ve savundum: iyi kod yorumlardan daha iyidir Sonuçta, yorumlar zamanında veya en son güncellenmeyebilir. Ek açıklamalar, diğer insanlar için daha fazla kafa karışıklığına neden olma eğilimindedir.

Buna ek olarak, yeniden düzenleme, kod ve iş mantığı işlevlerini anlamamızı artırmamızı sağlar, böylece hataları bulmamıza yardımcı olur; yeniden düzenleme, programlama hızını iyileştirmemize yardımcı olabilir, yani yeniden düzenleme, program yapısı tasarımını iyileştirir ve yeniden düzenlemenin ölçeklenebilirliği nedeniyle Yeni özellikler daha hızlı ve daha kolay hale gelir.

Yeniden düzenleme-zamanlama

Yeniden yapılanmanın anlamını ve rolünü anladıktan sonra, yeniden inşa etmeye ne zaman başlayacağız? Yazar her zaman bu görüşte ısrar etti: Yeniden düzenleme, tüm yazılım geliştirme süreci boyunca çalışan sürekli ve sistematik bir projedir. Yeniden düzenleme için zaman seçmemize gerek yoktur. Yeniden düzenleme her zaman ve her yerde, yani üç kez yapılmalıdır. Kural: Sadece üç şey var, üç şey yeniden inşa. Bu kriterin anlamı şudur: Bir işlevi ilk kez uyguladığınızda, bunu yapsanız bile, ikinci kez benzer bir işlev tasarımı yaparsanız, tiksinti duyarsınız, ancak bunu yaparsınız ve üçüncü kez benzer bir işlevi elde edip aynı şeyi yaparsınız. , O zaman yeniden düzenleme yapmalısınız. Üç kriter nispeten soyuttur, bu nedenle genellikle bu üç fırsatta gerçekleştirilebilen özel yazılım geliştirme sürecimize karşılık gelir:

(1) Yeni özellikler eklerken özellikle kolay değilse, yeniden düzenleme, özelliklerin ve yeni özelliklerin eklenmesini kolaylaştırabilir. Yeni bir özellik eklerken, önce bu özellik için gereken kodu temizliyoruz. Kayaların arasından damlayarak kodu kademeli olarak temizlemek için bir dakikanızı ayırın. Zaman geçtikçe kodumuz daha temiz, daha hızlı ve daha hızlı hale gelecektir.

(2) Hataları değiştirirken yeniden düzenleme yapın. Örneğin, hataları bulma ve bulma sürecinde, kendi kodunuzun veya başka birinin kodunun, zayıf ölçeklenebilirlik ve sağlamlık gibi tasarım kusurlarından kaynaklandığını görürsünüz. Yeniden düzenleme yapmak için daha iyi zaman. Belki şu anda, birçok öğrencinin soruları var, geliştirme aşamasında acele etmem gerektiğini ve yeniden düzenleme yapmak için zamanım olmadığını veya yamalandıktan sonra hatayı çözemeyeceğimi ve yeniden düzenlemeye ihtiyacım olmadığını düşünüyor. Yazarın önceki yıllardaki deneyimlerine dayanarak, sonuç şudur: Eğer onunla karşılaşırsanız, onu çözmelisiniz, yani bir problemle her karşılaştığınızda, onu atlamak yerine hemen çözeceksiniz. Şu anda kullanımda olan kodu iyileştirin ve henüz karşılaşılmamış sorunları göz ardı edin. Önünüzdeki mevcut yolda, tüm engelleri kaldırın, ileride kesinlikle bu şekilde tekrar gideceksiniz.Bir dahaki sefere buraya geldiğinizde, yolda hiçbir engel olmadığını göreceksiniz.

Yazılım geliştirme böyledir. Belki de bu sorunu çözmek için biraz daha zaman ayırmanız gerekir. Ancak uzun vadede size daha fazla zaman kazandıracaktır. Yani yeniden yapılanma aşamalı bir süreçtir, bir süre sonra, önceki tüm teknik borçların kademeli olarak ortadan kalkacağını ve tüm boşlukların birbiri ardına doldurulacağını göreceksiniz. Bu aşamalı kod yeniden düzenlemenin faydaları ortaya çıkmaya başlıyor ve programlama hızı açıkça artacak.

(3) Kod Gözden Geçirme sırasında yeniden düzenleme. Birçok şirket Ar-Ge ekibi düzenli Kod İncelemesine sahip olacaktır. Bu tür faaliyetlerin birçok faydası vardır. Örneğin, geliştirme ekibi arasında bilginin yayılmasına ve teknolojinin paylaşılmasına yardımcı olur ve daha deneyimli Geliştiriciler, deneyimi olmayan kişilere bilgi aktarır ve daha fazla kişinin, modüller arası yinelemeli geliştirme elde etmek için yazılımın diğer iş modüllerine daha aşina olmasına yardımcı olur. Kod İnceleme, daha fazla kişiye kendileri için daha mükemmel önerilerde bulunma fırsatı verebilir. Aynı zamanda, yeniden düzenleme, diğer kişilerin kodunu gözden geçirmeye yardımcı olabilir, çünkü yeniden düzenleme yapmadan önce, bazı öneriler ve iyi fikirler öne sürmek için belirli bir düzeyde anlayış ve aşinalık elde etmek için kodu okumanız ve yeniden düzenleme yoluyla kendi iyiliğinizi hızla elde edip edemeyeceğinizi düşünmeniz gerekir. Fikirler ve nihayetinde yeniden düzenleme ve uygulama yoluyla daha fazla tatmin elde edersiniz. Önceki deneyimime göre, kodu gözden geçirme çalışmasını verimli ve etkili kılmak için, bir gözden geçiren ve orijinal bir yazarın işbirliği yapmasını, gözden geçirenin değişiklikleri önermesini ve ardından ikisinin bu değişikliklerin yeniden düzenleme yoluyla kolayca başarılıp başarılamayacağına birlikte karar vermesini öneririm. Değişiklik maliyeti nispeten düşükse, gözden geçirme işlemi sırasında değişikliği birlikte başlatın.

Göreceli olarak büyük ve karmaşık bir tasarım inceleme gözden geçirme çalışmasıysa, orijinal yazarın, gözden geçirenlere tasarımın belirli uygulama ayrıntılarını göstermek için UML sınıf sıra diyagramları, zaman dizisi diyagramları ve akış şemaları kullanması önerilir.Tüm Kod İncelemesinde, gözden geçirenler kendi önerilerini yapabilir. Veya görüşleri değiştirin. Bu senaryoda, gözden geçirenler genellikle ekipteki kıdemli mühendisler, mimarlar ve teknik uzmanlardan oluşur.

Kod Gözden Geçirme biçimi ile ilgili olarak, Ekstrem Programlamada "çift programlama" biçimini de alabilir. Bu form, iki kişinin birlikte oturup kodu gözden geçirmesini alabilir, IOS ve Android geliştiricileri gibi iki platformu birlikte gözden geçirebilir veya deneyimli ve daha az deneyimli personelin birlikte gözden geçirmesi gerekebilir.

Yeniden düzenlemenin üç zamanlaması ilke ile anlaşılmalıdır, yani ne zaman yeniden düzenlenmemesi gerektiği, örneğin, bazen mevcut kod uygulaması çok kafa karıştırıcı olabilir, onu yeniden düzenlemek yenisini yazmaktan daha iyidir; Ek olarak, projeniz girdiyse Günün sonunda, bu zamanda yeniden düzenlemeden de kaçınılmalı ve zamanlama, yazılımın istikrarını olabildiğince korumaya dayanmalıdır.

Yeniden düzenlemenin ne yaptığını, yeniden düzenlemenin rolünü, neden yeniden düzenlemeyi ve yeniden düzenlemenin zamanlamasını anladıktan sonra, yeniden düzenlemeye ilişkin bir ön anlayışa sahibiz. Ardından, yazar, kod kalitesini optimize etmek için yeniden düzenleme tekniklerinin nasıl kullanılacağını açıklamaya odaklanacaktır. Temiz Kod.

Yeniden düzenleme becerileri işlevi yeniden düzenleme

Yeniden yapılandırmanın kaynağı, işlevin yeniden yapılandırılmasıyla başlar İşlev yeniden yapılandırma becerilerinde uzmanlaşmak, yeniden yapılandırma sürecinde önemli bir adımdır. Ardından, işlev yeniden yapılandırmasının pratik becerilerini tartışacağız.

• İşlev Adını Yeniden Adlandır: Temiz Kod, tanımlanan değişkenlerin ve işlev adlarının okunabilir olmasını gerektirir.Değişken ve işlevin adından ne yaptığını bilebilirsiniz, bu nedenle iyi, okunabilir bir işlev adı çok önemlidir. Daha karmaşık iş mantığını anlamak için özellikle yararlıdır.

• Parametreyi Kaldır: Bir fonksiyon artık bir parametreye ihtiyaç duymadığında, kesin olarak kaldırılmalıdır.Parametreleri bilinmeyen bir talep için ayırmayın.Çok fazla parametre kullanıcılar için parametre sorunlarına neden olur.

• Sorgu işlevini ve değiştirme işlevini ayırın: Bir işlev nesne değerini döndürürse ve nesne durumunu değiştirirse. Şu anda, biri sorgulamadan, diğeri değişiklikten sorumlu olmak üzere iki farklı işlev oluşturulmalıdır. Sorgu işlevi yan etkileri olmayan bir değer döndürürse, sorgu işlevini sınırsız kez çağırabilirsiniz. Sonuçlar, karmaşık hesaplamalar için de önbelleğe alınabilir.

• İşlevlerin parametre taşımasına izin verin: Birkaç işlev benzer iş yaparsa, yalnızca birkaç farklı değer biraz farklı davranışlara yol açar.Bu işlevleri birleştirin ve farklı değerleri ifade etmek için parametreleri kullanın.

• Parametreleri açık işlevlerle değiştirin: Mantığı tamamen parametrenin değerine bağlı olan ve farklı davranışlar alan bir işlev vardır Parametrenin her olası değeri için ayrı bir işlev oluşturulur.

• Nesne bütünlüğünü koruyun: Bir nesneden birkaç değer almanız ve bunları bir işlevin birden çok parametresi olarak iletmeniz gerekiyorsa, özellikle 5 veya daha fazla parametre gibi daha fazla parametre geçirmeniz gerektiğinde, bunu doğrudan ayarlamanız önerilir. Nesneler, parametrelerin sayısını azaltabilen ve nesneler arasındaki güveni artırabilen işlev parametreleri olarak doğrudan aktarılır ve bu şekilde, aranan uç nesnenin diğer özelliklerine ihtiyaç duyduğunda, işlev parametrelerini manuel olarak değiştirmesi gerekmez.

• Parametreleri işlevlerle değiştirin: Nesne bir işlevi çağırır ve sonucu bir parametre olarak başka bir işleve iletir ve bu işlevin kendisi de önceki işlevi çağırabilir. Yalnızca bu işlevi doğrudan çağırın. Parametreyi azaltmak için doğrudan parametreyi kaldırabilirsiniz. Numara.

• Parametre nesnelerini tanıtın: bazı parametreler her zaman aynı anda görünür Bu parametreleri değiştirmek için yeni bir nesne oluşturmak sadece parametre sayısını azaltmakla kalmaz, aynı zamanda sınıfın parametre genişletilebilirliğini artırmak için yeni oluşturulan parametre sınıfına taşınabilen bazı parametreler de olabilir.

• Ayar yöntemini kaldırın: Nesne oluşturulduğunda sınıfta bir alan atanması gerekiyorsa, daha sonra değiştirilmeyecektir.Bu senaryoda, bir ayar yöntemi eklemeye gerek yoktur.

• Gizli işlev: Başka sınıflar tarafından hiç kullanılmamış veya orijinal olarak kullanılmış bir işlev varsa, ancak sınıf dinamik olarak arayüzler veya gereksinimlerdeki değişiklikleri eklediğinden, daha sonra kullanılmayacaktır, bu durumda etkiyi azaltmak için bu işlevi gizlemeniz gerekir. alan.

• Yapıcıları fabrika işlevleriyle değiştirin: Nesneleri basit inşa eylemlerinden daha fazlasını oluşturmak istiyorsanız, en bariz motivasyon, alt sınıfları türetirken tür kodlarına dayalı farklı alt sınıflar oluşturmak veya sınıfın örnek sayısını kontrol etmektir.

Yeniden düzenleme teknikleri-koşullu ifadeler

• Koşullu ifadenin ayrıştırılması: Karmaşık bir koşullu ifade varsa, if / else ifadesinin paragraf mantığı bir işleve çıkarılır.

• Koşullu ifadelerin birleştirilmesi: hepsi aynı test sonucunu alan bir dizi koşullu test. Bu test ifadeleri tek bir fonksiyonda birleştirilebilir ve birleştirilmiş ifade bağımsız bir fonksiyona dönüştürülebilir. Bu koşullu testler birbirinden bağımsız ve ilgisiz ise Evet, birleştirmeyin.

• Tekrarlanan koşullu parçaların birleştirilmesi: Koşullu ifadenin her dalında aynı kod parçası bulunur ve bu kod ifadenin dışına taşınır.

• Kontrol işaretini kaldırın: Tek çıkış prensibini takip etmeniz gerekmez ve döngüden çıkıp çıkmayacağınıza veya fonksiyonun geri kalanını atlayıp atlamayacağınıza karar vermek için kontrol işaretini kullanmanıza gerek yoktur, sadece kırın veya geri dönün.

• İç içe geçmiş koşullu ifadeleri koruyucu cümlelerle değiştirin: Koşullu ifadelerin genellikle iki tezahürü vardır, biri: tüm dallar normal davranışa aittir; iki: yalnızca biri normal davranıştır ve diğerleri nadirdir. Bir durumda if / else koşullu ifadesi kullanılmalıdır; ikinci durumda, belirli bir koşul yaygın değilse, koşul ayrı ayrı kontrol edilmeli ve koşul doğru olduğunda hemen işlevden dönmelidir. Böyle ayrı bir kontrol genellikle denir Weiwei cümlesi.

• Koşullu ifadeleri çok biçimlilikle değiştirin: Nesne türlerinin farklı seçimlerine göre farklı davranışları seçen bir koşullu ifade varsa, koşullu ifadenin her dalını bir alt sınıftaki bir geçersiz kılma işlevine koyun ve orijinal işlevi bildirin Soyut bir işlevdir.

• Nesneleri tanıtın: Bazı işlemleri gerçekleştirirken, bir nesnenin olup olmadığını kontrol etmeniz, özel bir nesne oluşturabilir, ilgili işlevin orijinal kontrol koşulu zamanlandığında yürütülecek eylemi gerçekleştirmesine izin verebilirsiniz, nesneye ek olarak, özel durumlar için özel bir nesne de olabilir, Bu tür nesneler genellikle Singleton'dur.

• İddialara giriş: program durumunun bir hipotezi

• Koşullu ifadeyi MAP ile değiştirin: Koşullu ifadeyi HashMap'in Anahtar-Değer anahtar / değer çifti aracılığıyla optimize edin, koşullu ifadenin değerlendirme koşulu anahtar değer olarak kullanılır ve değer değeri, koşullu ifadenin dönüş değerini depolar.

• Koşullu ifadeleri yansıtma yoluyla değiştirme: dinamik yansıma ilkesi aracılığıyla

Yeniden düzenleme becerileri vakası

Önceki bölümlerin içeriği esas olarak teorik içeriktir.Ardından, belirli bir yeniden yapılandırma durumuna bakalım.

Koşullu ifade ise harita kaldır

Bu tekniğin uygulama yöntemi önceki bölümde anlatılmıştır. Aşağıdaki kodda gösterildiği gibi doğrudan kod durumuna bakalım:

Orijinal koşullu ifade kodu aşağıdaki Şekil 1'de gösterilmektedir:

public static int getServiceCode (String str) {int code = 0; if (str.equals ("Age")) {code = 1;} else if (str.equals ("Address")) {code = 2;} else eğer (str.equals ("Ad")) {kod = 3;} else if (str.equals ("Hayır")) {kod = 4;} dönüş kodu;}

Yeniden düzenlenen kod aşağıdaki gibidir:

public static void initialMap {map.put ("Age", 1); map.put ("Address", 2); map.put ("Name", 3); map.put ("No", 4);}

Yukarıdaki kod, koşullu ifadeyi doğrudan Harita yapısı aracılığıyla ayrıştırır Anahtar koşullu değişkendir ve Değer, koşullu ifadenin dönüş değeridir. Değer çok uygun, açıkça yüksek verimlilik O (1) zaman karmaşıklık değeridir. Bu yeniden yapılandırma tekniği, nispeten basit koşullu ifade senaryoları için uygundur.Aşağıdaki, dönüş değeri olmayan daha karmaşık bir koşullu ifade senaryosudur.Bununla nasıl başa çıkılacağını görelim.

Yansıma giderme şube yapısı

Orijinal koşullu ifade kodu aşağıdaki Şekil 1'de gösterilmektedir:

Şekil 1 Koşullu ifadenin gösterilmesi

Şekil 2 Harita ve yansıtma yoluyla yeniden yapılanmanın gösterilmesi

Yukarıdaki Şekil 2'de gösterildiği gibi, koşullu ifade, Harita ve yansıma tarafından ayrıştırılır ve koşullu ifade dalının mantığı, alt sınıftaki geçersiz kılma işlevine çıkarılır ve soyut arabirim handleBusinessData'yı içeren ortak soyut sınıf çıkarılır ve alt sınıf miras alır. Anlayın.

Çok biçimlilik koşullu ifadelerin yerini alır

Şekil 3 Yeniden düzenlenmiş durum sonuç diyagramı

Şekil 4 Yeniden düzenlenmiş durum-polimorfizm nasıl kullanılır

Şekil 5 Yeniden düzenlenmiş kod yapısı diyagramı

Şekil 6 Yeniden düzenleme-soyut sınıf, koşullu ifadelerin ayrıştırılmasını sağlamak için basit fabrika modeli fikirleri

Yukarıdaki Şekil 6'da gösterildiği gibi, orijinal koşullu ifadede iki koşullu ifade dalı vardır (dal mantığı):

• Çince check-in şahıs operasyonu HotelCNPasserngerOperaton sınıfı

• İngilizce check-in işlemi HotelEnPassengerOperation sınıfı

Temel soyut sınıf: AbstractPassengerOperation birlikte çıkarılır ve iki dal alt sınıfı, soyut sınıfı miras alır.

Koşullu ifadeyi ayrıştırmak için yazar, bunu başarmak için polimorfik yeniden yapılandırma tekniklerini kullanır.İki özel uygulama yöntemi vardır.İlk uygulama yöntemi, polimorfizmi elde etmek için soyut sınıfları kullanmaktır.Kod yapısı, Şekil 5 yolcu klasörü, UML'de gösterilmektedir. Sınıf diyagramı yukarıdaki Şekil 6'da gösterilmektedir. İkinci uygulama yöntemi, polimorfizmi uygulamak için arayüzler kullanmaktır Kod yapısı, Şekil 5'te yolcu2 klasöründe gösterilmektedir ve UML sınıf diyagramı, yukarıdaki Şekil 7'de gösterilmektedir.

Şekil 7 Koşullu ifadelerin ayrıştırılmasını gerçekleştirmek için Yeniden Düzenleme Arayüzü Durum Modu

Yukarıdaki Şekil 7'de gösterildiği gibi, orijinal koşullu ifadede iki koşullu ifade dalı vardır (dal mantığı). Dal mantığı HotelCNPassengerState ve HotelENPassengerState alt sınıflarına yerleştirilir ve PassengerState arabirim sınıfı tek tip olarak çıkarılır. Tüm alt sınıfların uygulaması gereken iki temel arayüz. Şekil 7'den, duruma göre modun kullanıldığı görülebilir.

Yukarıdaki yeniden düzenlemeden sonra, hangi etkiyi başardık:

• Mantığı temizle

• Ana mantık kodu satırlarının sayısı azaltıldı

• İş mantığı, daha iyi paketleme ve ayırma, belirli iş ayrıntılarına dikkat etmeye gerek yok

• Çok biçimlilik, soyutlama, durum modu, fabrika modu ve inşa modu gibi farklı fikirler ve yöntemler benimsenir ve bir işlevi yeniden yapılandırmak için, teşvik edilmeye ve ödünç almaya değer birçok farklı yeniden yapılandırma tekniği kullanılır;

Sonuna yaz

Yeniden düzenleme nispeten büyük ve derinlemesine bir konu ve konudur. Bu sefer yazar, mükemmel temiz kod yazmak için etkili yeniden düzenleme tekniklerinin nasıl kullanılacağını tartışır. Kodu temizlemenin yolu, tüm geliştirme süreci boyunca her zaman yeniden düzenleme yapmaktır. , Önceki tüm teknik borcun ödenmesi için sürekli ve sürekli kademeli yeniden yapılanma.

Yeniden düzenleme teknik bir faaliyettir. Çok kıdemli bir kişinin teknik çözümün genel yapısını ve ürün kalitesini kontrol etmesi gerekir, böylece yeniden düzenleme daha etkili olabilir ve yeni sorunlar ortaya çıkarmaz. Bununla birlikte, nihayetinde yeniden düzenlemeyi benimsememiz ne anlama gelirse gelsin, nihayetinde Hepimizin mümkün olduğunca Solid tasarımın ilgili ilkelerine uyması gerekiyor:

• Sınıfın tek sorumluluğu: Sınıfın tek bir şey yapması gerektiğini yansıtır.İyi bir yazılım tasarımında, sistem çok sayıda kısa sınıftan oluşur ve birkaç tanrı sınıfı yerine, aralarında işbirliği içinde tamamlanması gerekir. Sınıfın birden fazla sorumluluğu varsa, bu sorumluluklar arasında birleşme meydana gelecektir. Bir sorumluluğu değiştirmek, sınıfın diğer insanlara hizmet etme işlevini etkileyebilir ve engelleyebilir. Bu tür bir bağlantı, hassas bir tasarıma yol açacaktır ve modifikasyon sırasında birçok bilinmeyen sorun ortaya çıkabilir.

• Açma ve kapatma ilkesi: tanımı, sınıf, modül ve işlev gibi bir yazılım varlığının uzantıya açık olması, ancak değişiklik için kapalı olması gerektiği anlamına gelir.Özellikle, değişiklikleri elde etmek için orijinal kodu değiştirmek yerine, değişiklikleri uzantılar yoluyla uygulamanız gerekir. Bu ilke, yüz nesnesi tasarımının en temel ilkesidir. Yol gösterici ideoloji, (1) değişmeden kalması veya nadiren değiştirilmesi gereken nispeten kararlı bir arayüz soyutlamaktır; (2) paket değişiklikleri; ancak, yazılım geliştirme sürecinde, başlangıçta açılış ve kapanış ilkelerini tam olarak takip etmek zor olabilir. Daha fazla durumda, sürekli yinelemeli yeniden düzenleme sürecinde iyileştirmeler yapılır ve öngörülebilir değişiklik aralığı dahilinde tasarım yapılır.

• Richter ikamesi ilkesi: alt sınıflar, ana sınıfın işlevlerini genişletebilir, ancak ana sınıfın orijinal işlevlerini değiştiremez. Basitçe ifade etmek gerekirse, temel sınıf kodunun kullanıldığı tüm yerlerde, bir alt sınıf nesnesiyle değiştirildiğinde hala normal şekilde çalışabiliyorsa, bu ilke yerine getirilir, aksi takdirde kalıtım ilişkisinde bir sorun vardır ve ikisi arasındaki kalıtım ilişkisi kaldırılmalıdır.Bu ilke kullanılabilir. Nesne miras ilişkimizin makul olup olmadığını belirleyin. Genellikle, tasarlarken, kalıtım yerine kompozisyona öncelik vereceğiz, çünkü kalıtım kodu düşürüp kodun yeniden kullanılabilirliğini artırsa da, ana sınıf ve alt sınıf, kapsüllemeyi yok eden güçlü bir bağlantıya sahip olacaktır.

• Arayüz izolasyon prensibi: Kullanıcılar, kullanmadıkları arayüzlere güvenmeye zorlanamaz. Basitçe ifade etmek gerekirse, müşterinin ne tür bir arayüze ihtiyacı var, ona ne tür bir arayüz sağlanıyor, diğer yedek arayüzler sağlanmamalı ve arayüz şişirilmemeli, aksi takdirde nesnenin kullanılmayan bir yöntemi değiştirildiğinde, nesne de Etkilenecek. Arayüz tasarımı minimum arayüz prensibini takip etmelidir.Aslında bu aynı zamanda yüksek uyumun bir tezahürüdür.Başka bir deyişle, tek işlevli ve yüksek uyumlu çoklu arayüzler kullanmak, tek bir büyük arayüzden daha iyidir.

• Bağımlılığı Tersine Çevirme (DIP): Yüksek seviyeli modüller, düşük seviyeli modüllere dayanmamalıdır ve her ikisi de soyutlamalarına dayanmalıdır; soyutlamalar ayrıntılara bağlı olmamalıdır; detaylar soyutlamalara bağlı olmalıdır. Aslında, bu genellikle "arayüzler için programlama" dediğimiz şeydir. Buradaki arayüz soyutlamadır. Programlamak için belirli uygulamalara güvenmek yerine arayüze güvenmeliyiz. DIP, bileşenler arasındaki üst düzey bileşenlerin düşük düzey bileşenlere bağlı olmaması gerektiğini açıklar. Bağımlılığı tersine çevirme, uygulanması yerine gerekli temel bileşen arabirimine odaklanmak için yukarıdan aşağıya bir yaklaşım kullanarak uygulama ve arabirim tersine çevirme anlamına gelir. DI modeline iyi bir örnek, IOC (Ters Kontrol) çerçevesinin uygulanmasıdır.İnşaat yöntemleri, alt yapı enjeksiyonu, işlev enjeksiyonu ve öznitelik enjeksiyonu olarak ikiye ayrılır.

Yeniden düzenleme ve optimizasyon yaptığımızda, yukarıdaki ilkeleri tam olarak dikkate almalıyız Tasarım başlangıçta mükemmel olmayabilir, ancak yeniden düzenleme işlemi sırasında sürekli olarak geliştirilebilir. Ama aslında pek çok kişi tasarım sürecini atlamış ve tasarımı düşünmek şöyle dursun, doğrudan kod yazacak bir modüle sahip olmuştur.Projede bunun birçok örneği var. Elbette basit bir modül tasarlamanıza gerek olmayabilir, ancak modül nispeten karmaşıksa, kodu yazmadan önce tasarlayabilir ve düşünebilirsiniz.Bu alışkanlığı geliştirirseniz kesinlikle okunabilirlik, kararlılık, sağlamlık ve esneklik yazabileceksiniz. , Alınmış ve ölçeklenebilir kod yararlıdır.

Bugünün Tavsiyesi

Okumak için aşağıdaki resme tıklayın

Java eski, hala yiyebilir misin?

"Bilgi" de Zhao Liying'e zorbalık yapan "Dajiang Dahe" deki orijinal kitabın en güzel öğrencisine meydan okudu.

Yüz yönden düşün

190323 Yang Yang'ın ne kadar envanteri var? Kola tavuk kanatları ve koyunları aslında Londra'daki çekimler sırasında filme alındı.

Eylül yeni tur önizlemesi: Tomb Raider, Spider-Man ve FIFA / NBA2K'nın yeni çalışmaları burada

Tang Yan Luo Jin, Yılbaşı partisinde aşkını gösterdi ve Tang Yan'a yıldızları kovalaması için eşlik eden Luo Jin, onu küçük bir prenses olarak şımarttı.

Aralık ayı sonunda drama rehberi düzenlendi!

Oracle Code Login Beijing Code Feast sizi zirveye davet ediyor Ücretsiz kayıt

Shimen'de küçük bir araba bir ağaca çarpar ve kendini tutuşturur

Ben Sai, 2018 için sözde sanatsal bir dijital kontrol listesi

40 yaşındaki Zhang Ziyi sırtüstü koşarken yere düştü, ayağa kalktı ve güldü ve bütün dertlerinin bittiğini söyledi.

Liu Haiping'in trendini takip etmeyen Xiaomi MIX 2S, Qualcomm'un Snapdragon 845 yerli cep telefonunu ilk lansman olarak alıyor, AI ses asistanı parlak bir nokta haline geliyor

"IU" "Paylaş" 190323 Ölümsüz Cuma IU Fırtına Güncellemesi Güneşli Fotoğraflar Aina, Yeni Yılı başlatacak gibi görünüyor!