Sufiĉe ofte mi renkontas programistojn, kiuj ne aŭdis pri la principoj de SOLID (ni . - Transl.) aŭ objekt-orientita programado (OOP), aŭ aŭdita, sed ne uzu ilin praktike. Ĉi tiu artikolo priskribas la avantaĝojn de OOP-principoj, kiuj helpas la programiston en sia ĉiutaga laboro. Kelkaj el ili estas bone konataj, aliaj ne tiom, do la artikolo estos utila kaj por komencantoj kaj jam spertaj programistoj.
Ni memorigas vin: por ĉiuj legantoj de "Habr" - rabato de 10 000 rubloj kiam oni enskribas en iu ajn Skillbox-kurso per la reklamkodo "Habr".
Skillbox rekomendas: Eduka interreta kurso .
SEKA (Ne Ripetu Vin)
Sufiĉe simpla principo, kies esenco estas klara el la nomo: "Ne ripetu vin." Por programisto, tio signifas la bezonon eviti duplikatan kodon, same kiel la kapablon uzi abstraktadon en laboro.
Se estas du ripetaj sekcioj en la kodo, ili devus esti kombinitaj en unu metodon. Se malmola kodita valoro estas uzata pli ol unufoje, indas konverti ĝin al publika konstanto.
Ĉi tio estas necesa por simpligi la kodon kaj faciligi ĝin prizorgi, kio estas la ĉefa tasko de OOP. Vi ankaŭ ne misuzu la union, ĉar la sama kodo ne preterpasos la kontrolon kun kaj OrderId kaj SSN.
Ŝanĝi Enkapsuligon
La softvaraĵoj de plej multaj kompanioj konstante evoluas. Ĉi tio signifas, ke la kodo devas esti ŝanĝita, ĝi devas esti konservita. Vi povas faciligi vian vivon per enkapsulado. Ĉi tio permesos al vi pli efike testi kaj konservi vian ekzistantan kodan bazon. .
Se vi skribas en Java tiam .
La principo de malfermiteco / proksimeco
Ĉi tiu principo povas esti facile memorita legante la sekvan deklaron: "Programaraj entoj (klasoj, moduloj, funkcioj, ktp.) estu malfermitaj por etendo, sed fermitaj por modifo." En praktiko, tio signifas, ke ili povas permesi sian konduton esti ŝanĝita sen ŝanĝi la fontkodon.
La principo estas grava kiam ŝanĝoj al la fontkodo postulas reviziojn, unutestadon kaj aliajn procedurojn. Kodo, kiu sekvas la malferman/fermitan principon, ne ŝanĝiĝas kiam ĝi estas etendita, do estas multe malpli da problemoj kun ĝi.
Jen ekzemplo de kodo, kiu malobservas ĉi tiun principon.
Se vi bezonas ŝanĝi ion en ĝi, ĝi daŭros multe da tempo, ĉar vi devos ŝanĝi ĉiujn partojn de la kodo, kiuj havas rilaton kun la dezirata fragmento.
Cetere, malfermiteco-fermo estas unu el la principoj de SOLID.
Ununura Principo de Respondeco (SRP)
Alia principo de la SOLIDA aro. Ĝi diras ke "ekzistas nur unu kialo kiu kondukas al klasŝanĝo." La klaso havas nur unu taskon. Ĝi povas havi plurajn metodojn, sed ĉiu el ili estas uzata nur por solvi komunan problemon. Ĉiuj metodoj kaj propraĵoj devas servi nur ĉi tion.
La valoro de ĉi tiu principo estas, ke ĝi malfiksas la ligon inter ununura programaro kaj la kodo. Aldonante pli ol unu funkciojn al klaso enkondukas rilaton inter la du funkcioj. Tiel, se vi ŝanĝas unu el ili, estas granda ŝanco difekti la duan, rilatan al la unua. Kaj ĉi tio signifas pliigi la testajn ciklojn por antaŭe identigi ĉiujn problemojn.
Dependeca Inversia Principo (DIP)
Ĉi-supra estas kodekzemplo kie la AppManager dependas de la EventLogWriter, kiu siavice estas proksime rilata al la AppManager. Se vi bezonas alian manieron montri la sciigon, ĉu ĝi estas puŝo, SMS aŭ retpoŝto, vi devas ŝanĝi la klason de AppManager.
La problemo povas esti solvita per DIP. Do, anstataŭ AppManager, ni petas EventLogWriter, kiu estos injektita uzante la kadron.
DIP ebligas facile anstataŭigi individuajn modulojn per aliaj ŝanĝante la dependecan modulon. Ĉi tio ebligas ŝanĝi unu modulon sen tuŝi la aliajn.
Komponado anstataŭ heredo
La du ĉefaj manieroj reuzi kodon estas heredo kaj kunmetaĵo, ĉiu kun siaj propraj avantaĝoj kaj malavantaĝoj. La dua estas kutime preferita ĉar ĝi estas pli fleksebla.
Kunmetaĵo donas al vi la kapablon ŝanĝi la konduton de klaso ĉe rultempo fiksante ĝiajn trajtojn. Dum efektivigado de interfacoj, polimorfismo estas uzita, kiu donas pli flekseblan efektivigon.
Eĉ "Efika Java" Joshua Bloch konsilas preferi kunmetaĵon ol heredon.
Barbara Liskov Anstataŭiga Principo (LSP)
Alia principo el la ilaro SOLID. Ĝi deklaras ke subtipoj devas esti anstataŭigeblaj por supertipo. Tio estas, metodoj kaj funkcioj kiuj funkcias kun superklaso devus povi funkcii sen problemoj kun ĝiaj subklasoj.
LSP estas rilatita al kaj la Ununura Principo de Respondeco kaj la Apartigo de Principo de Respondeco. Se klaso disponigas pli da funkcieco ol subklaso, tiam ĉi-lasta ne subtenos iun funkciecon, malobservante ĉi tiun principon.
Jen kodo, kiu kontraŭdiras LSP.
La areo (Rektangulo r) metodo kalkulas la areon de Rektangulo. La programo kraŝos post ekzekuto de Square, ĉar Square ne estas Rektangulo ĉi tie. Laŭ la LSP-principo, funkcioj kiuj uzas referencojn al bazklasoj devus povi uzi objektojn de derivitaj klasoj sen kromaj instrukcioj.
Tiu ĉi principo, kiu estas specifa difino de subtipo, estis proponita de Barbara Liskov en konferenca konferenco de 1987 nomita "Data Abstraktado kaj Hierarkio" - tial ĝia nomo.
Interfaca Apartiga Principo (ISP)
Alia SOLIDA principo. Laŭ li, interfaco kiu ne estas uzata ne devus esti efektivigita. Sekvi ĉi tiun principon helpas la sistemon resti fleksebla kaj refactorable kiam faras ŝanĝojn al la logiko de laboro.
Plej ofte, ĉi tiu situacio okazas kiam la interfaco enhavas plurajn funkciojn samtempe, kaj la kliento bezonas nur unu el ili.
Ĉar skribi interfacon estas kompleksa tasko, post kiam la laboro estas finita, ŝanĝi ĝin sen rompi ion ajn estos problemo.
La avantaĝo de la ISP-principo en Java estas, ke ĉiuj metodoj devas esti efektivigitaj unue, kaj nur tiam ili povas esti uzataj de klasoj. Tial la principo ebligas redukti la nombron da metodoj.
Programado por Interfaco, Ne Efektivigo
Ĉi tie ĉio estas klara de la nomo. Apliki ĉi tiun principon kondukas al fleksebla kodo, kiu povas funkcii kun ajna nova interfaca efektivigo.
Vi devus uzi interfacan tipon por variabloj, revenspecoj aŭ la tipo de metodo argumento. Ekzemplo uzas SuperClass prefere ol SubClass.
Tio estas:
Listo nombroj= getNumbers();
Sed ne:
ArrayList nombroj = getNumbers ();
Jen praktika efektivigo de tio, kio estas dirita supre.
Delega principo
Ofta ekzemplo estas la equals() kaj hashCode() metodoj en Java. Kiam du objektoj devas esti komparitaj, ĉi tiu ago estas delegita al la taŭga klaso anstataŭ al la klientoklaso.
La avantaĝo de la principo estas, ke ne ekzistas duobligo de kodo kaj estas relative facile ŝanĝi konduton. Ĝi ankaŭ validas por eventa delegacio.
Ĉiuj ĉi tiuj principoj permesas vin skribi pli flekseblan, belan kaj fidindan kodon kun alta kohezio kaj malalta kuniĝo. Kompreneble, teorio estas bona, sed por ke programisto vere ekuzi la akiritan scion, necesas praktiko. La sekva paŝo post regado de la principoj de OOP povas esti la studo de dezajnaj ŝablonoj por solvi oftajn programojn pri disvolvado de problemoj.
Skillbox rekomendas:
- Praktika kurso .
- Aplikata interreta kurso .
- Dujara praktika kurso .
fonto: www.habr.com