Zimlech dacks treffen ech Entwéckler déi net vun de SOLID Prinzipien héieren hunn (mir . — Transl.) oder objektorientéiert Programméierung (OOP), oder hu vun hinnen héieren, awer benotzt se net an der Praxis. Dësen Artikel beschreift d'Virdeeler vun OOP Prinzipien, déi den Entwéckler a senger alldeeglecher Aarbecht hëllefen. E puer vun hinnen si gutt bekannt, anerer net sou vill, sou datt den Artikel nëtzlech ass fir Ufänger an erfuerene Programméierer.
Mir erënneren Iech: fir all Habr Lieser - eng Remise vun 10 Rubel wann Dir Iech an all Skillbox Cours aschreift mat dem Habr Promo Code.
Skillbox recommandéiert: Online pädagogesch Cours .
DRY (Widderhuelen Iech net)
E relativ einfache Prinzip, d'Essenz vun deem ass kloer aus dem Numm: "Widderhuelen Iech net." Fir e Programméierer heescht dat de Besoin fir duplizéiert Code ze vermeiden, wéi och d'Méiglechkeet fir Abstraktioun an hirer Aarbecht ze benotzen.
Wann et zwee widderhuelend Sektiounen am Code sinn, sollten se an eng Method kombinéiert ginn. Wann en hardcoded Wäert méi wéi eemol benotzt gëtt, ass et derwäert et an eng ëffentlech Konstant ëmzewandelen.
Dëst ass néideg fir de Code ze vereinfachen an et méi einfach ze erhalen, wat d'Haaptziel vun OOP ass. Dir sollt d'Gewerkschaft och net iwwerbenotzen, well dee selwechte Code wäert d'Verifizéierung net mat der OrderId an dem SSN passéieren.
Encapsulating Ännerungen
Déi meescht Firmen hir Softwareprodukter entwéckelen sech permanent. Dëst bedeit datt Ännerungen am Code musse gemaach ginn, et muss ënnerstëtzt ginn. Dir kënnt Äert Liewen méi einfach maachen andeems Dir Verkapselung benotzt. Dëst erlaabt Iech Är existent Codebasis méi effizient ze testen an z'erhalen. .
Wann Dir op Java schreift, dann .
Open / zouene Prinzip
Dëse Prinzip kann einfach erënnert ginn andeems Dir déi folgend Ausso liest: "Software Entitéiten (Klassen, Moduler, Funktiounen, asw.) Sollen op fir d'Verlängerung opmaachen, awer zou fir d'Ännerung." An der Praxis heescht dat, datt se hir Verhalen änneren kënnen ouni de Quellcode z'änneren.
De Prinzip ass wichteg wann Ännerungen am Quellcode Coderevisioun, Eenheetstestung an aner Prozeduren erfuerderen. Code deen dem oppenen / zouene Prinzip follegt ännert sech net wann se verlängert ginn, sou datt et vill manner Probleemer domat gëtt.
Hei ass e Beispill vu Code deen dëse Prinzip verletzt.
Wann Dir eppes dran änneren musst, da wäert et vill Zäit daueren, well all Sektiounen vum Code, déi eng Verbindung mat dem gewënschten Fragment hunn, musse geännert ginn.
Iwwregens, Offenheet-Zoumaache ass ee vun de Prinzipien vu SOLID.
Eenzeg Verantwortungsprinzip (SRP)
En anere Prinzip aus dem SOLID Set. Et seet datt "et ass nëmmen eng Ursaach déi eng Verännerung an der Klass verursaacht." D'Klass léist nëmmen ee Problem. Et kann e puer Methoden hunn, awer jidderee vun hinnen gëtt nëmme benotzt fir e gemeinsame Problem ze léisen. All Methoden an Eegeschafte sollen nëmmen dëst déngen.
De Wäert vun dësem Prinzip ass datt et d'Kupplung tëscht der individueller Softwarekomponent an dem Code loosen. Wann Dir méi wéi eng Funktionalitéit zu enger Klass bäidréit, féiert et eng Relatioun tëscht deenen zwou Funktiounen. Also, wann Dir ee vun hinnen ännert, ass et eng grouss Chance fir déi zweet ze ruinéieren, déi mat der éischter verbonnen ass. An dat heescht d'Erhéijung vun Testzyklen fir all Probleemer am Viraus z'identifizéieren.
Ofhängegkeet Inversion Prinzip (DIP)
Uewen ass e Code Beispill wou AppManager hänkt vum EventLogWriter of, deen am Tour enk mat AppManager gekoppelt ass. Wann Dir en anere Wee braucht fir eng Notifikatioun ze weisen, sief et Push, SMS oder E-Mail, musst Dir d'AppManager Klass änneren.
De Problem kann mat DIP geléist ginn. Also, amplaz AppManager, froe mir en EventLogWriter, dee mam Kader agefouert gëtt.
DIP mécht et méiglech eenzel Moduler einfach mat aneren ze ersetzen andeems Dir den Ofhängegkeetsmodul ännert. Dëst mécht et méiglech ee Modul z'änneren ouni déi aner ze beaflossen.
Zesummesetzung amplaz Ierfschaft
Et ginn zwou Haapt Weeër fir Code ze benotzen: Ierfschaft a Kompositioun, déi zwee hir eegen Virdeeler an Nodeeler hunn. Normalerweis gëtt déi zweet bevorzugt well et méi flexibel ass.
Zesummesetzung gëtt Iech d'Fäegkeet d'Behuele vun enger Klass während der Runtime z'änneren andeems se seng Eegeschafte setzen. Wann Dir Interfaces implementéiert, gëtt Polymorphismus benotzt, wat eng méi flexibel Implementatioun gëtt.
Och Effektiv Java vum Joshua Bloch beréit d'Kompositioun iwwer d'Ierfschaft ze wielen.
Barbara Liskov Substitution Principle (LSP)
En anere Prinzip aus dem SOLID Toolkit. Et seet datt Ënnertypen fir den Supertyp ersatzbar musse sinn. Dat ass, Methoden a Funktiounen, déi mat enger Superklass funktionnéieren, solle fäeg sinn ouni Probleemer mat sengen Ënnerklassen ze schaffen.
LSP ass mat dem eenzege Verantwortungsprinzip an dem gemeinsame Verantwortungsprinzip verbonnen. Wann eng Klass méi Funktionalitéit bitt wéi eng Ënnerklass, da wäert déi lescht net e puer vun der Funktionalitéit ënnerstëtzen, wat dëse Prinzip verletzt.
Hei ass e Stéck Code deen den LSP widdersprécht.
D'Gebitt (Rectangle r) Method berechent d'Gebitt vun engem Rechteck. De Programm crasht nom Ausféierung vum Square well Square hei kee Rechteck ass. Geméiss dem LSP Prinzip solle Funktiounen déi Referenzen op Basisklassen benotzen, Objekter vun ofgeleet Klassen ouni zousätzlech Instruktioune benotzen.
Dëse Prinzip, deen eng spezifesch Definitioun vun engem Ënnertyp ass, gouf vum Barbara Liskov an enger 1987 Konferenz Keynote mam Titel "Dataabstraktioun an Hierarchie" proposéiert, also säin Numm.
Interface Trennungsprinzip (ISP)
En anere SOLID Prinzip. Deemno soll en Interface deen net benotzt gëtt net ëmgesat ginn. No dësem Prinzip hëlleft de System flexibel ze bleiwen a gëeegent fir refactoring wann Ännerungen un der Operatioun Logik gemaach ginn.
Meeschtens geschitt dës Situatioun wann d'Interface gläichzäiteg verschidde Funktiounen enthält, an de Client brauch nëmmen ee vun hinnen.
Zënter datt en Interface schreiwen ass eng schwiereg Aufgab, et z'änneren nodeems d'Aarbecht fäerdeg ass ouni eppes ze briechen ass eng Erausfuerderung.
De Virdeel vum ISP-Prinzip am Java ass datt all Methode fir d'éischt implementéiert musse ginn, an nëmmen da kënne se vu Klassen benotzt ginn. Dofir mécht de Prinzip et méiglech d'Zuel vun de Methoden ze reduzéieren.
Programméiere fir d'Interface, net d'Ëmsetzung
Alles hei ass kloer vum Numm. D'Applikatioun vun dësem Prinzip féiert zu der Schafung vu flexiblen Code, dee mat all neier Ëmsetzung vun der Interface funktionnéiert.
Dir sollt den Interface Typ fir Variablen benotzen, zréck Typen, oder d'Method Argument Typ. E Beispill benotzt SuperClass anstatt SubClass.
Dat ass:
Lëscht Zuelen = getNumbers();
Awer net:
ArrayList Zuelen = getNumbers();
Hei ass eng praktesch Ëmsetzung vun deem wat uewen diskutéiert gëtt.
Delegatiounsprinzip
E gemeinsamt Beispill ass d'Equiliber () an hashCode () Methoden am Java. Wann et néideg ass zwee Objekter ze vergläichen, gëtt dës Aktioun un déi entspriechend Klass delegéiert anstatt de Client.
De Virdeel vum Prinzip ass datt et keng Duplikatioun vum Code gëtt an et ass relativ einfach Verhalen z'änneren. Et gëllt och fir Event Delegatioun.
All dës Prinzipien erlaben Iech méi flexibel, schéin an zouverlässeg Code mat héich Kohäsioun an niddereg Kopplung ze schreiwen. Natierlech ass d'Theorie gutt, awer fir en Entwéckler fir dat erfuerene Wëssen tatsächlech ze benotzen, ass Praxis néideg. Wann Dir OOP Prinzipien beherrscht hutt, ass Ären nächste Schrëtt vläicht Designmuster ze léieren fir allgemeng Softwareentwécklungsproblemer ze léisen.
Skillbox recommandéiert:
- Praktesch Cours .
- Applizéiert online Course .
- Zwee-Joer praktesch Cours .
Source: will.com