Šo ziņu pēdējo reizi rediģēja Vasara 2017-9-27 15:32
Šis raksts ir īss stāsts, kas imitē jautājumus un atbildes, un autors izmanto humoristisku stilu, lai īsi analizētu arhitektu darbu: Es gribu būt programmatūras arhitekts. Šī ir lieliska iespēja jauniem programmatūras izstrādātājiem. Es vēlos vadīt komandu un pieņemt svarīgus lēmumus par datu bāzēm un ietvariem, tīmekļa serveriem utt. Ak, tad jūs vispār nevēlaties būt programmatūras arhitekts. Protams, es gribēju būt svarīgu lēmumu pieņēmējs. Tas ir labi, bet jūs neiekļaujat svarīgus lēmumus savā sarakstā, kas ir nebūtiski lēmumi. Ko tu ar to domā? Vai jūs sakāt, ka datubāzes nav svarīgi lēmumi, vai jūs zināt, cik daudz mēs tām tērējam? Varbūt tas maksā pārāk dārgi. Tomēr datubāzes nav viens no svarīgākajiem lēmumiem. Kā jūs to varat teikt? Datu bāze ir sistēmas kodols, kurā visi dati tiek sistematizēti, klasificēti, indeksēti un piekļūsti. Bez datubāzes nebūtu sistēmas. Datu bāze ir tikai IO ierīce, kas nodrošina dažus noderīgus rīkus klasifikācijai, vaicāšanai un informācijas ziņošanai, bet tās ir tikai sistēmas arhitektūras palīgfunkcijas. Palīdzība? Tas ir briesmīgi. Tieši tā, tas ir palīglīdzeklis. Sistēmas darbības noteikumi var izmantot dažus no šiem rīkiem, bet šie rīki nav raksturīgi atbilstošajiem biznesa noteikumiem. Ja nepieciešams, jūs varat aizstāt esošos ar dažādiem instrumentiem; Un biznesa noteikumi nemainīsies. Nu, jā, bet tas bija jāpārkodē, jo šie rīki tika izmantoti sākotnējā datu bāzē. Tā ir jūsu problēma. Ko tu ar to domā? Jūsu problēma ir tāda, ka jūs domājat, ka biznesa noteikumi ir atkarīgi no datu bāzes rīkiem, bet tie nav. Vai vismaz tam nevajadzētu būt tādam, kamēr nav nodrošināta laba arhitektūra. Tas ir vienkārši traki. Kā izveidot biznesa kārtulas, kurās netiek izmantoti šie rīki? Es nesaku, ka viņi neizmanto datu bāzes rīkus, bet viņi nav atkarīgi no tā. Biznesa kārtulām nav jāzina, kuru datu bāzi izmantojat. Tātad, kā jūs varat iegūt biznesa noteikumus, nezinot, kādus rīkus izmantot? Apgrieziet atkarības, lai datu bāze būtu atkarīga no biznesa kārtulām. Pārliecinieties, ka biznesa kārtulas nav atkarīgas no datu bāzes. Jūs runājat muļķības. Gluži pretēji, es izmantoju programmatūras arhitektūras valodu. Tas ir atkarības inversijas princips: zema līmeņa standartiem jābalstās uz augsta līmeņa standartiem. Muļķības! Augsta līmeņa kritēriji (pieņemot, ka attiecas uz uzņēmējdarbības noteikumiem) Zema līmeņa kritēriju izsaukšana (pieņemot, ka attiecas uz datubāzēm). Tāpēc augsta līmeņa kritērijs balstīsies uz zema līmeņa kritēriju saskaņā ar principu, ka zvanītājs ir atkarīgs no zvanītāja. Visi to zina! Tas attiecas uz izpildlaiku. Bet, apkopojot, mēs vēlamies atkarības inversiju. Augsta līmeņa pamatnostādņu pirmkodā nevajadzētu minēt zema līmeņa pamatnostādņu pirmkodu. Nu! Kā jūs varat veikt zvanu, to nepieminot? Protams, nekādu problēmu. Tas ir tas, kas ir saistīts ar objektorientāciju. Objektorientācija ir saistīta ar reālās pasaules modeļu izveidi, apvienojot datus, funkcionalitāti un saliedētus objektus. Tas ir par koda organizēšanu intuitīvā struktūrā. Tas ir tas, ko viņi saka? Kā mēs visi zinām, tā ir acīmredzama patiesība. Jā, tas ir, tomēr, izmantojot objektorientētas vadlīnijas, patiešām ir iespējams piesaukt, to nepieminot. Nu, kā to izdarīt? Objektorientētā dizainā objekti sūta ziņojumus viens otram. Protams, tas ir pareizi. Kad sūtītājs nosūta ziņojumu, tas nezina saņēmēja tipu. Tas ir atkarīgs no izmantotās valodas. Java sūtītājs zina vismaz saņēmēja bāzes tipu. Rubīnā sūtītājs vismaz zina, ka saņēmējs spēj apstrādāt saņemtos ziņojumus. Tas ir pareizi. Tomēr jebkurā gadījumā sūtītājs nezina konkrēto saņēmēja veidu. Tas ir pareizi, labi, tas ir. Tāpēc sūtītājs var izstrādāt uztvērēju, lai veiktu funkciju, neminot konkrēto uztvērēja tipu. Tas ir pareizi, tas ir pareizi. Es saprotu. Tomēr sūtītājs joprojām ir atkarīgs no saņēmēja. Tas attiecas uz izpildlaiku. Tomēr, apkopojot, tas ir atšķirīgs. Sūtītāja avota kods nemin vai nav atkarīgs no saņēmēja avota koda. Faktiski saņēmēja avota kods ir atkarīgs no sūtītāja avota koda. Nekādā gadījumā! Sūtītājs joprojām ir atkarīgs no nosūtītās klases. Varbūt no kāda avota koda tas būs skaidrāks. Nākamais punkts ir rakstīts Java. Pirmais ir sūtītājs: pakas sūtītājs; publiskās klases sūtītājs { privāts saņēmējs saņēmējs; publiskais sūtītājs (saņēmējs r) { saņēmējs = r; } public void doSomething () { receiver.receiveThis (); } publiskais interfeiss Uztvērējs { void receiveThis (); } }Šeit ir uztvērējs: iepakojuma uztvērējs; importēt sūtītāju. Sūtītājs; publiskā klase SpecificReceiver īsteno Sender.Receiver { public void receiveThis () { //do kaut ko interesantu. } }Piezīme: Saņēmējs ir atkarīgs no sūtītāja, SpecificReceiver ir atkarīgs no sūtītāja, un sūtītājā nav ar saņēmēju saistītās informācijas. Jā, bet jūs melojat, jūs ievietojat saņēmēja interfeisu sūtītāja klasē. Jūs sākat saprast. Ko jūs zināt? Protams, tas ir arhitektūras princips. Sūtītājam ir interfeiss, kas uztvērējam ir jāievieš. Ja tas nozīmē, ka man ir jāizmanto ligzdotas klases, tad ...... Ligzdotās klases ir tikai viens no līdzekļiem mērķa sasniegšanai, ir arī citi veidi. Nu, pagaidiet minūti. Kāds tam sakars ar datubāzēm? Mēs sākām runāt par datu bāzēm. Apskatīsim kodu nedaudz vairāk. Pirmais ir vienkāršs biznesa noteikums: paketes biznesa noteikumi; importēt entītijas. Kaut kas; publiskā klase BusinessRule { private BusinessRuleGateway vārteja; public BusinessRule (BusinessRuleGateway vārteja) { this.gateway = vārteja; } public void execute (String id) { gateway.startTransaction (); Kaut kas = gateway.getSomething (id); thing.makeChanges (); gateway.saveKaut kas (lieta); gateway.endTransaction (); } }Biznesa noteikumiem nav lielas nozīmes. Šis ir tikai viens piemērs. Varētu būt vairāk šādu nodarbību, kas īsteno daudz dažādu biznesa noteikumu. Labi, kas tad īsti ir vārteja? Tas nodrošina visas datu piekļuves metodes, izmantojot biznesa kārtulas. Īstenojiet to šādi: paketes biznesa noteikumi; importēt entītijas. Kaut kas; publiskais interfeiss BusinessRuleGateway { Something getSomething (virknes id); anulēt startTransaction (); void saveSomething (Kaut kas lieta); anulēt endTransaction (); }Piezīme: Tas ir businessRules. Labi, kas ir kaut kas klase? Tas ir vienkāršs biznesa objekts. Es to ievietoju vienībās. paketes vienības; publiskā klase Kaut kas { public void makeChanges () { //... } }Galu galā BusinessRuleGateway ieviešana, šī klase zina reālo datu bāzi: paketes datu bāze; importēt businessRules.BusinessRuleGateway; importēt entītijas. Kaut kas; publiskā klase MySqlBusinessRuleGateway īsteno BusinessRuleGateway { public Something getSomething (String id) { // izmantojiet MySql, lai iegūtu lietu. } public void startTransaction () { // start MySql transaction } public void saveSomething (Kaut kas lieta) { // saglabāt lietu MySql } public void endTransaction () { // end MySql transakcija } }Turklāt ņemiet vērā, ka biznesa kārtulas izsauc datu bāzi izpildlaikā; Tomēr kompilēšanas laikā datu bāze ietver un ir atkarīga no businessRules. Nu, es domāju, ka es to saprotu. Jūs vienkārši izmantojat polimorfismu, lai slēptu faktu, ka datu bāze ir ieviesta no biznesa noteikumiem. Tomēr joprojām ir nepieciešams interfeiss, lai nodrošinātu visus datu bāzes rīkus biznesa noteikumiem. Nē, nemaz. Mēs neesam mēģinājuši nodrošināt datu bāzes rīkus biznesa noteikumiem. Tā vietā viņi izmanto biznesa noteikumus, lai izveidotu saskarnes nepieciešamajam. Šo saskarņu ieviešana ļauj izsaukt pareizos rīkus. Jā, bet, ja jums ir nepieciešams izmantot katru rīku visiem biznesa noteikumiem, tad vienkārši ievietojiet rīku vārtejas saskarnē. Ak, es nedomāju, ka jūs joprojām saprotat. Saprotiet, ko? Tas jau ir skaidrs. Katra biznesa kārtula definē tikai vienu interfeisu nepieciešamajiem datu piekļuves rīkiem. Pagaidiet minūti, ko jūs sakāt? Tas ir interfeisa segregācijas princips. Katra biznesa kārtulu klase izmanto tikai noteiktas datu bāzes iespējas. Tāpēc saskarnes, ko nodrošina katra biznesa kārtula, var piekļūt tikai atbilstošajām iespējām. Tomēr tas nozīmē, ka ir daudz saskarņu un daudzas mazas ieviešanas klases, kas izsauc citas datu bāzes klases. Lieliski, jūs sākat saprast. Bet tas ir pārāk nekārtīgs un laika izšķiešana. Kāpēc to darīt? Tas ir organizēts un ietaupa laiku. Nāc, iegūstiet daudz koda koda dēļ. Gluži pretēji, nebūtiskus lēmumus var aizkavēt ar svarīgiem arhitektūras lēmumiem. Ko tas nozīmē? Es atceros, ka sākumā jūs teicāt, ka vēlaties kļūt par programmatūras arhitektu, vai ne? Jūs vēlaties pieņemt visus lēmumus, kas patiešām ir svarīgi. Jā, tas ir tas, ko es domāju. Jūs vēlaties pieņemt lēmumus par datu bāzēm, tīmekļa serveriem un ietvariem, vai ne? Jā, jūs sakāt, ka nekas no tā nav svarīgs. Tikai neatbilstošs saturs. Tas ir pareizi. Tas ir viss. Programmatūras arhitektu pieņemtie svarīgi lēmumi ir tie, kas ļauj pieņemt lēmumus par datu bāzēm, tīmekļa serveriem un ietvariem. Bet jums vispirms ir jāizlemj, kuri no tiem! Nē, tas nedarbojas. Faktiski tos var izlemt vēlāk izstrādes ciklā, kad informācija ir bagātāka. Tā ir katastrofa, ja arhitekti iepriekš identificē sistēmas, lai konstatētu, ka tās nenodrošina vajadzīgo veiktspēju vai ievieš neciešamus ierobežojumus. Tikai tad, kad arhitekts nolemj atlikt lēmumu, viņš pieņems lēmumu, kad informācija būs pietiekama; Komandas, kas neizmanto lēnas un resursietilpīgas IO ierīces un sistēmas, var izveidot ātras, vieglas testēšanas vides pēc arhitektu ieskatiem. Tikai tās arhitekti rūpējas par to, kas patiešām ir svarīgi, un aizkavē tos, kas to nedara, un šāda komanda ir laimīgā. Muļķības, es vispār nesaprotu, ko jūs domājat. Nu, labi apskatiet šo rakstu, pretējā gadījumā jums būs jāgaida vēl 10 gadi, lai to izdomātu.
| 
Publicēts 27.09.2017 15:29:46
|
|
|
Publicēts 28.09.2017 15:00:37
|
Saimnieks|
Publicēts 29.09.2017 08:34:23
|
Publicēts 27.11.2018 11:12:17
|
