Apa sing anti-pola? Ayo goleki sawetara conto (Bagian 2)

Apa sing anti-pola? Ayo ndeleng sawetara conto (Part 1) Dina iki kita nerusake review babagan anti-pola sing paling populer. Yen sampeyan ora kejawab bagean pisanan, iki . Dadi, pola desain minangka praktik paling apik. Ing tembung liya, iki minangka conto cara sing apik lan diuji wektu kanggo ngrampungake masalah tartamtu. Salajengipun, anti-pola punika kosok balene, ing pangertèn sing padha pola pitfalls utawa kesalahane nalika ngrampungake macem-macem masalah (pola ala). Ayo nerusake menyang anti-pola pangembangan piranti lunak sabanjure.

8. Palu emas

Pethel emas minangka anti-pola sing ditetepake kanthi yakin manawa solusi tartamtu bisa ditrapake sacara universal. Tuladha:

1. Sawise nemoni masalah lan nemokake pola kanggo solusi sing sampurna, programer nyoba nempel pola iki ing endi wae, nglamar kanggo proyek saiki lan kabeh proyek sing bakal teka, tinimbang golek solusi sing cocog kanggo kasus tartamtu.

2. Sawetara pangembang tau nggawe varian cache dhewe kanggo kahanan tartamtu (amarga ora ana sing cocog). Mengko, ing proyek sabanjure sing ora ana logika cache khusus, dheweke nggunakake varian maneh tinimbang nggunakake perpustakaan sing wis siap (contone, Ehcache). Asil ana akeh kewan omo lan incompatibilities, uga akeh wektu boroske lan syaraf goreng.

   Sapa wae bisa seneng karo anti-pola iki. Yen sampeyan pamula, sampeyan bisa uga ora ngerti babagan pola desain. Iki bisa nyebabake sampeyan nyoba ngatasi kabeh masalah kanthi cara sing wis dikuasai. Yen kita ngomong babagan profesional, mula iki diarani deformasi profesional utawa nerdview. Sampeyan duwe pola desain preferred dhewe, lan tinimbang nggunakake tengen, sampeyan nggunakake favorit, assuming sing pas apik ing past njamin asil padha ing mangsa.

   Jeblugan iki bisa ngasilake asil sing sedhih banget - saka implementasine sing ala, ora stabil, lan angel ditindakake nganti gagal proyek. Kaya ora ana pil kanggo kabeh penyakit, ora ana pola desain siji kanggo kabeh kesempatan.

9. Optimasi durung wayahe

Optimasi prematur minangka anti-pola sing jenenge ngomong dhewe. "Programer nglampahi wektu akeh mikir lan kuwatir babagan panggonan sing ora kritis ing kode lan nyoba ngoptimalake, sing mung mengaruhi debugging lan dhukungan sakteruse. Umume kita kudu lali babagan optimasi, ujare, 97% kasus. , Optimization durung wayahe iku oyod saka kabeh ala. Sing ngandika, kita kudu mbayar manungsa waé kanggo 3% isih." - Donald Knuth Contone, prematur nambah indeks menyang database. Kok dadi ala? Inggih, iku ala, indeks disimpen minangka wit binar. Akibaté, saben-saben nilai anyar ditambahake lan dibusak, wit bakal diitung maneh, lan iki nggunakake sumber daya lan wektu. Mulane, indeks kudu ditambahake mung nalika ana kabutuhan sing penting (yen sampeyan duwe data sing akeh lan pitakon mbutuhake wektu sing suwe) lan mung kanggo kolom sing paling penting (bidang sing paling sering ditakoni).

10. Spaghetti kode

Kode spaghetti minangka anti-pola sing ditetepake kanthi kode sing strukture ora apik, mbingungake, lan angel dimangerteni, ngemot kabeh jinis percabangan, kayata pengecualian bungkus, kahanan, lan puteran. Sadurunge, operator goto minangka sekutu utama anti-pola iki. Pernyataan Goto ora digunakake maneh, sing kanthi seneng ngilangi sawetara kesulitan lan masalah sing ana gandhengane.

public boolean someDifficultMethod(List<String> XMLAttrList) {
           ...
   int prefix = stringPool.getPrefixForQName(elementType);
   int elementURI;
   try {
       if (prefix == -1) {
        ...
           if (elementURI != -1) {
               stringPool.setURIForQName(...);
           }
       } else {
        ...
           if (elementURI == -1) {
           ...
           }
       }
   } catch (Exception e) {
       return false;
   }
   if (attrIndex != -1) {
       int index = attrList.getFirstAttr(attrIndex);
       while (index != -1) {
           int attName = attrList.getAttrName(index);
           if (!stringPool.equalNames(...)){
           ...
               if (attPrefix != namespacesPrefix) {
                   if (attPrefix == -1) {
                    ...
                   } else {
                       if (uri == -1) {
                       ...
                       }
                       stringPool.setURIForQName(attName, uri);
                   ...
                   }
                   if (elementDepth >= 0) {
                   ...
                   }
                   elementDepth++;
                   if (elementDepth == fElementTypeStack.length) {
                   ...
                   }
               ...
                   return contentSpecType == fCHILDRENSymbol;
               }
           }
       }
   }
}

Iku katon ala, ora iku? Sayange, iki minangka anti-pola sing paling umum :( Malah wong sing nulis kode kasebut ora bakal bisa ngerti ing mangsa ngarep. Pangembang liyane sing ndeleng kode kasebut bakal mikir, "Inggih, yen bisa, oke - luwih apik ora kanggo ndemek ". Asring, cara wiwitane prasaja lan banget transparan, nanging minangka syarat anyar ditambahake, cara iki mboko sithik saddled karo statements liyane lan liyane kondisional, ngowahi iku menyang monstrosity kaya iki. Yen cara kuwi. katon, sampeyan kudu refactor salah siji rampung utawa ing paling bagean paling mbingungake.. Biasane, nalika jadwal project, wektu diparengake kanggo refactoring, contone, 30% saka wektu sprint kanggo refactoring lan tes. Mesthi, iki nganggep sing ora ana rush (nanging kapan kedadeyan kasebut).kene .

11. nomer Piandel

Angka sihir minangka anti-pola ing ngendi kabeh jinis konstanta digunakake ing program tanpa panjelasan babagan tujuan utawa maknane. Tegese, umume ora dijenengi utawa ing kasus sing ekstrem, ora ana komentar sing nerangake apa komentar kasebut utawa kenapa. Kaya kode spageti, iki minangka salah sawijining pola anti-pola sing paling umum. Sapa sing ora nulis kode kasebut bisa uga ora ngerti babagan nomer sihir utawa cara kerjane (lan ing wektune, penulis dhewe ora bakal bisa nerangake). Akibaté, ngganti utawa mbusak nomer njalari kode magis mandheg bisa digunakake bebarengan. Contone, 36 lan 73. Kanggo nglawan pola anti iki, aku nyaranake review kode. Kode sampeyan kudu dideleng dening pangembang sing ora melu ing bagean kode sing cocog. Mripate bakal seger lan bakal duwe pitakon: apa iki lan kenapa sampeyan nindakake? Lan mesthi, sampeyan kudu nggunakake jeneng panjelasan utawa ninggalake komentar.

12. Copy-and-paste programming

Copy-and-paste program minangka anti-pola ing ngendi kode wong liya disalin lan ditempelake tanpa dipikir, bisa uga nyebabake efek samping sing ora dikarepake. Contone, nyalin lan nempel metode kanthi petungan matematika utawa algoritma rumit sing durung dingerteni. Bisa uga kanggo kasus tartamtu, nanging ing sawetara kahanan liyane bisa nyebabake masalah. Upaminipun aku kudu cara kanggo nemtokake jumlah maksimum ing Uploaded. Nggoleki Internet, aku nemokake solusi iki:

public static int max(int[] array) {
   int max = 0;
   for(int i = 0; i < array.length; i++) {
       if (Math.abs(array[i]) > max){
           max = array[i];
       }
   }
   return max;
}

We njaluk Uploaded karo nomer 3, 6, 1, 4, lan 2, lan cara ngasilake 6. Great, ayo kang tetep! Nanging mengko kita entuk array sing dumadi saka 2.5, -7, 2, lan 3, banjur asile -7. Lan asil iki ora apik. Masalah ing kene yaiku Math.abs () ngasilake nilai absolut. Ora ngerti babagan iki nyebabake bencana, nanging mung ing kahanan tartamtu. Tanpa pangerten sing jero babagan solusi kasebut, ana akeh kasus sing ora bisa diverifikasi. Kode sing disalin bisa uga ngluwihi struktur internal aplikasi, kanthi gaya lan ing tingkat arsitektur sing luwih dhasar. Kode kasebut bakal luwih angel diwaca lan dijaga. Lan mesthi, kita kudu ora lali yen langsung nyalin kode wong liya minangka plagiarisme khusus.

13. Reinventing setir

Reinventing setir iku sawijining anti-pola, uga kadhangkala dikenal minangka reinventing setir kothak. Intine, cithakan iki minangka kebalikan saka pola anti-copy-and-paste sing dianggep ing ndhuwur. Ing anti-pola iki, pangembang ngetrapake solusi dhewe kanggo masalah sing wis ana solusi. Kadhangkala solusi sing wis ana iki luwih apik tinimbang sing diciptakake programmer. Paling asring, iki mung nyebabake wektu sing ilang lan produktivitas sing luwih murah: programer bisa uga ora nemokake solusi utawa bisa nemokake solusi sing adoh saka sing paling apik. Ngandika, kita ora bisa ngilangi kemungkinan nggawe solusi mandiri, amarga nindakake iku minangka cara langsung kanggo nyalin lan nempel pemrograman. Programmer kudu dipandu dening tugas pemrograman khusus sing muncul kanggo ngrampungake kanthi cekap, kanthi nggunakake solusi sing wis siap utawa nggawe solusi khusus. Kerep banget, alesan kanggo nggunakake anti-pola iki mung cepet-cepet. Asil ana analisis cethek (nelusuri) solusi sing wis siap. Reinventing wheel kothak iku cilik ngendi anti-pola ing wawasan wis kasil negatif. Yaiku, proyek kasebut mbutuhake solusi khusus, lan pangembang nggawe, nanging ala. Ing wektu sing padha, pilihan sing apik wis ana lan wong liya nggunakake kanthi sukses. Ing ngisor baris: jumlah ageng wektu ilang. Kaping pisanan, kita nggawe sing ora bisa digunakake. Banjur kita nyoba kanggo refactor, lan pungkasanipun kita ngganti karo soko sing wis ana. Conto yaiku ngleksanakake cache khusus sampeyan nalika akeh implementasine wis ana. Ora ketompo carane bakat minangka programmer, sampeyan kudu ngelingi sing reinventing kothak wheel paling ora sampah wektu. Lan, kaya sing sampeyan ngerteni, wektu minangka sumber daya sing paling berharga.

14. Yo-yo masalah

Masalah yo-yo minangka anti-pola sing struktur aplikasi kasebut rumit banget amarga fragmentasi sing akeh banget (contone, rantai warisan sing dibagi banget). "Masalah yo-yo" muncul nalika sampeyan kudu ngerti program sing hierarki warisane dawa lan rumit, nggawe panggilan metode sing jero. Akibaté, programer kudu navigasi antarane macem-macem kelas lan cara kanggo mriksa prilaku program. Jeneng anti-pola iki asale saka jeneng dolanan. Minangka conto, ayo goleki rantai warisan ing ngisor iki: Kita duwe antarmuka Teknologi:

public interface Technology {
   void turnOn();
}

Antarmuka Transport nduweni warisan:

public interface Transport extends Technology {
   boolean fillUp();
}

Banjur kita duwe antarmuka liyane, GroundTransport:

public interface GroundTransportation extends Transport {
   void startMove();
   void brake();
}

Lan saka ing kono, kita entuk kelas Mobil abstrak:

public abstract class Car implements GroundTransportation {
   @Override
   public boolean fillUp() {
       /* some implementation */
       return true;
   }
   @Override
   public void turnOn() {
       /* some implementation */
   }
   public boolean openTheDoor() {
       /* some implementation */
       return true;
   }
   public abstract void fixCar();
}

Sabanjure yaiku kelas Volkswagen abstrak:

public abstract class Volkswagen extends Car {
   @Override
   public void startMove() {
       /* some implementation */
   }
   @Override
   public void brake() {
       /* some implementation */
   }
}

Lan pungkasanipun, model tartamtu:

public class VolkswagenAmarok extends Volkswagen {
   @Override
   public void fixCar(){
       /* some implementation */
   }
}

Rantai iki meksa kita mburu jawaban kanggo pitakonan kaya:

1. Carane akeh cara VolkswagenAmarokduwe?

2. Jinis apa sing kudu dilebokake tinimbang tandha pitakon kanggo entuk abstraksi maksimal:

   
   ? someObj = new VolkswagenAmarok();
          someObj.brake();
   

Pancen angel kanggo mangsuli pitakon kaya ngono kanthi cepet — kita kudu mriksa lan neliti, lan gampang bingung. Lan kepiye yen hirarki luwih gedhe, luwih dawa, lan luwih rumit, kanthi macem-macem kakehan lan override? Struktur sing bakal kita duwe bakal ora jelas amarga fragmentasi sing berlebihan. Solusi sing paling apik yaiku nyuda divisi sing ora perlu. Ing kasus kita, kita bakal ninggalake Teknologi → Mobil → VolkswagenAmarok.

15. Kerumitan sengaja

Kompleksitas sing ora perlu minangka anti-pola ing ngendi komplikasi sing ora perlu dienalake menyang solusi. "Sembarang wong bodho bisa nulis kode sing bisa dingerteni komputer. Programer sing apik nulis kode sing bisa dingerteni manungsa." - Martin Fowler Dadi apa kerumitan? Bisa ditetepake minangka tingkat kesulitan sing ditindakake saben operasi ing program kasebut. Minangka aturan, kerumitan bisa dipérang dadi rong jinis. Kompleksitas pisanan yaiku jumlah fungsi sing diduweni sistem. Bisa dikurangi mung siji cara - kanthi ngilangi sawetara fungsi. Cara sing wis ana kudu dipantau. Sawijining cara kudu dicopot yen ora digunakake maneh utawa isih digunakake nanging tanpa nggawa nilai. Apa maneh, sampeyan kudu netepake carane kabeh cara ing aplikasi digunakake, supaya ngerti ngendi investasi bakal migunani (akeh nggunakake maneh kode) lan apa sampeyan bisa ngomong ora kanggo. Jinis kerumitan kapindho yaiku kerumitan sing ora perlu. Sampeyan bisa nambani mung liwat pendekatan profesional. Tinimbang nindakake soko "kelangan" (pangembang enom ora mung sing rentan kanggo penyakit iki), sampeyan kudu mikir babagan carane nindakake kanthi gampang, amarga solusi sing paling apik tansah prasaja. Contone, umpamane kita duwe tabel sing gegandhengan karo deskripsi sawetara entitas, kayata pangguna: Dadi, kita duwe id pangguna, id basa sing digawe deskripsi, lan deskripsi dhewe. Kajaba iku, kita duwe deskriptor tambahan kanggo mobil, file, rencana, lan tabel pelanggan. Banjur apa sing bakal katon kaya nglebokake nilai anyar menyang tabel kasebut?

public void createDescriptionForElement(ServiceType type, Long languageId, Long serviceId, String description)throws Exception {
   switch (type){
       case CAR:
           jdbcTemplate.update(CREATE_RELATION_WITH_CAR, languageId, serviceId, description);
       case USER:
           jdbcTemplate.update(CREATE_RELATION_WITH_USER, languageId, serviceId, description);
       case FILE:
           jdbcTemplate.update(CREATE_RELATION_WITH_FILE, languageId, serviceId, description);
       case PLAN:
           jdbcTemplate.update(CREATE_RELATION_WITH_PLAN, languageId, serviceId, description);
       case CUSTOMER:
           jdbcTemplate.update(CREATE_RELATION_WITH_CUSTOMER, languageId, serviceId, description);
       default:
           throw new Exception();
   }
}

Lan miturut, kita duwe enum iki:

public enum ServiceType {
   CAR(),
   USER(),
   FILE(),
   PLAN(),
   CUSTOMER()
}

Kabeh katon prasaja lan apik ... Nanging kepiye cara liya? Pancen, dheweke uga bakal duwe pirang-pirang switchpernyataan lan pirang-pirang pitakon database sing meh padha, sing bakal dadi rumit lan bloat kelas kita. Kepiye carane kabeh iki luwih gampang? Ayo upgrade enum kita:

@Getter
@AllArgsConstructor
public enum ServiceType {
   CAR("cars_descriptions", "car_id"),
   USER("users_descriptions", "user_id"),
   FILE("files_descriptions", "file_id"),
   PLAN("plans_descriptions", "plan_id"),
   CUSTOMER("customers_descriptions", "customer_id");
   private String tableName;
   private String columnName;
}

Saiki saben jinis duwe jeneng kolom asli tabel. Akibaté, cara kanggo nggawe deskripsi dadi:

private static final String CREATE_RELATION_WITH_SERVICE = "INSERT INTO %s(language_id, %s, description) VALUES (?, ?, ?)";
public void createDescriptionForElement(ServiceType type, Long languageId, Long serviceId, String description) {
   jdbcTemplate.update(String.format(CREATE_RELATION_WITH_SERVICE, type.getTableName(), type.getColumnName()), languageId, serviceId, description);
   }

Trep, prasaja, lan kompak, apa ora? Indikasi pangembang sing apik ora malah sepira kerepe dheweke nggunakake pola, nanging sepira kerepe dheweke ngindhari anti-pola. Bodho iku mungsuh sing paling awon, amarga sampeyan kudu ngerti mungsuh saka pandeleng. Inggih, mung iku sing dakkarepake kanggo dina iki. Matur nuwun, kabeh! :)