Този пост беше последно редактиран от Summer на 27.09.2017 г., 15:32
Тази статия е кратък разказ, който имитира въпроси и отговори, а авторът използва хумористичен стил, за да анализира накратко работата, която вършат архитектите: Искам да бъда софтуерен архитект. Това е отличен вариант за млади софтуерни разработчици. Искам да ръководя екипа и да взимам важни решения относно бази данни и фреймуъркове, уеб сървъри и т.н. О, тогава изобщо не искаш да станеш софтуерен архитект. Разбира се, исках да вземам важни решения. Това е добре, но не включваш важни решения в списъка си, които са незначителни. Какво искаш да кажеш? Казвате ли, че базите данни не са важни решения, знаете ли колко харчим за тях? Може би струва твърде много. Въпреки това, базите данни не са сред важните решения. Как би казал това? Базата данни е ядрото на системата, където всички данни се систематизират, класифицират, индексират и достъпват. Без база данни нямаше да има система. Базата данни е просто IO устройство, което предоставя полезни инструменти за класификация, заявки и отчети на информация, но това са само допълнителни функции на системната архитектура. Помощ? Това е възмутително. Точно така, това е помощна служба. Бизнес правилата на системата може да се възползват от някои от тези инструменти, но те не са присъщи на съответните бизнес правила. Ако е необходимо, можете да замените съществуващите с други инструменти; И бизнес правилата няма да се променят. Да, но трябваше да бъде прекодирана, защото тези инструменти са използвани в оригиналната база данни. Това е твой проблем. Какво искаш да кажеш? Проблемът ти е, че мислиш, че бизнес правилата зависят от инструментите за бази данни, но не са. Или поне не би трябвало да е така, докато не се осигури добра архитектура. Просто е лудост. Как създавате бизнес правила, които не използват тези инструменти? Не казвам, че не използват инструменти за бази данни, но не зависят от тях. Бизнес правилата не трябва да знаят коя база данни използвате. Как да получиш бизнес правила, без да знаеш какви инструменти да използваш? Обърнете зависимостите така, че базата данни да зависи от бизнес правилата. Уверете се, че бизнес правилата не зависят от базата данни. Говориш глупости. Напротив, използвам езика на софтуерната архитектура. Това е принципът на инверсия на зависимостта: ниско ниво стандарти трябва да разчитат на високо ниво стандарти. Глупости! Критерии на високо ниво (при условие, че се позовават на бизнес правила), Извикване на ниско ниво критерии (предполагаем, че се отнася до бази данни). Следователно, критерият на високо ниво ще разчита на ниско ниво според принципа, че обаждащият се зависи от получателя. Всички го знаят! Това важи по време на изпълнение. Но при компилиране, това, което искаме, е инверсия на зависимостта. Изходният код на висшите насоки не трябва да споменава изходния код на ниско ниво насоките. Хайде! Как можеш да вземеш обаждане, без да го споменеш? Разбира се, няма проблем. Това е същността на обектно-ориентираното. Обектно-ориентираната е създаване на реални модели, комбинирайки данни, функционалност и свързани обекти. Става дума за организиране на кода в интуитивна структура. Така ли казват? Както всички знаем, това е очевидната истина. Да, така е, но при използване на обектно-ориентирани насоки наистина е възможно да се извикат без да се споменават. Е, как да го направим? В обектно-ориентирания дизайн обектите си изпращат съобщения един на друг. Точно така, разбира се. Когато изпращачът изпрати съобщение, той не знае типа получател. Зависи от използвания език. В Java изпращачът знае поне базовия тип на получателя. В Ruby изпращачът поне знае, че получателят е способен да обработва получените съобщения. Точно така. Във всеки случай обаче изпращачът не знае конкретния тип получател. Точно така, така е. Следователно, изпращачът може да проектира приемник да изпълнява функция, без да споменава конкретния тип приемник. Точно така, точно така. Разбирам. Въпреки това, изпращачът все още зависи от получателя. Това важи по време на изпълнение. Въпреки това, когато се компилира, е различно. Изходният код на подателя не споменава и не зависи от изходния код на получателя. Всъщност изходният код на получателя зависи от изходния код на подателя. Няма начин! Изпращачът все пак зависи от класа, който изпраща. Може би от някакъв изходен код ще стане по-ясно. Следващият параграф е написан на Java. Първи е изпращачът: изпращач на пратки; public class Sender {private Receiver receiver; публичен подател (Получател r) { получател = r; } public void doSomething () { receiver.receiveThis (); } публичен интерфейс Receiver { void receiveThis (); } }Ето и получателя: приемник на пакети; Импортирайте подателя. Изпращач; public class SpecificReceiver имплементира Sender.Receiver { public void receiveThis () { //do нещо интересно. } }Забележка: Получателят зависи от подателя, Специфичният приемник зависи от подателя, и няма информация, свързана с получателя, в подателя. Да, но лъжеш, сложи интерфейса на получателя в класа на изпращач. Започваш да разбираш. Какво знаеш ти? Разбира се, това е принципът на архитектурата. Изпращачът има интерфейса, който получателят трябва да реализира. Ако това означава, че трябва да използвам вложени класове, тогава ...... Вложените класове са само един от средствата за постигане на цел, има и други начини. Чакай малко. Какво общо има това с базите данни? Започнахме да говорим за бази данни. Нека разгледаме кода още малко. Първото е просто бизнес правило: пакетни бизнесПравила; Внасят обекти. Нещо; public class BusinessRule { private BusinessRuleGateway gateway; public BusinessRule (BusinessRuleGateway gateway) { this.gateway = gateway; } public void execute (String id) { gateway.startTransaction (); Нещо нещо = gateway.getНещо (id); thing.makeChanges (); gateway.saveSomething (нещо); gateway.endTransaction (); } }Бизнес правилата нямат голяма тежест. Това е само един пример. Може да има още такива класове, които прилагат много различни бизнес правила. Добре, какво точно е Gateway? Тя предоставя всички методи за достъп до данни чрез бизнес правила. Реализирайте го по следния начин: пакетни бизнесПравила; Внасят обекти. Нещо; публичен интерфейс BusinessRuleGateway { Something getSomething (String id); void startTransaction (); void saveSomething (нещо, което е нещо); void endTransaction (); }Забележка: Това е в businessRules. Добре, какъв е класът Нещо? Той представлява прост бизнес обект. Слагам го на обекти. пакетни обекти; public class Нещо { публична празнота правиПромени () { //... } }В крайна сметка имплементацията на BusinessRuleGateway, този клас познава истинската база данни: база данни с пакети; внос на бизнесRules.BusinessRuleGateway; Внасят обекти. Нещо; public class MySqlBusinessRuleGateway имплементира BusinessRuleGateway { public Something getSomething (String id) { // използвай MySql, за да получиш нещо. } public void startTransaction () { // start MySQL transaction } public void saveSomething (Something thing) { // save thing in MySQL } public void endTransaction () { // end MySQL транзакция } }Освен това, имайте предвид, че бизнес правилата извикват базата данни по време на изпълнение; Въпреки това, при компилация базата данни включва и зависи от businessRules. Е, мисля, че разбирам. Просто използваш полиморфизъм, за да скриеш факта, че базата данни е реализирана от бизнес правилата. Въпреки това, все още е необходим интерфейс, който да предостави всички инструменти за база данни към бизнес правилата. Не, изобщо не. Не сме се опитвали да предоставим инструменти за бази данни според бизнес правилата. Вместо това използват бизнес правила, за да създадат интерфейси за нуждите си. Внедряването на тези интерфейси ви позволява да извикате правилните инструменти. Да, но ако трябва да използвате всички инструменти за всички бизнес правила, просто поставете инструмента в интерфейса на шлюза. Ах, мисля, че още не разбираш. Какво да разбера? Това вече е ясно. Всяко бизнес правило определя само един интерфейс за инструментите за достъп до данни, от които се нуждае. Чакай малко, какво ще кажеш? Това е принципът на сегрегация на интерфейсите. Всеки клас бизнес правила използва само определени съоръжения от базата данни. Следователно интерфейсите, предоставени от всяко бизнес правило, могат да имат достъп само до съответните възможности. Въпреки това, това означава, че има много интерфейси и много малки класове за имплементация, които извикват други класове на база данни. Страхотно, започваш да разбираш. Но е твърде объркано и загуба на време. Защо го правиш? Това е организирано и спестява време. Хайде, вземи много код заради самия код. Напротив, нерелевантните решения могат да бъдат забавени от важни архитектурни решения. Какво означава това? Спомням си, че в началото каза, че искаш да станеш софтуерен архитект, нали? Искаш да вземеш всички решения, които наистина имат значение. Да, така си мислех. Искаш да вземаш решения относно бази данни, уеб сървъри и рамки, нали? Да, казваш, че нищо от това няма значение. Просто нерелевантно съдържание. Точно така. Това е всичко. Важните решения, взети от софтуерните архитекти, са тези, които ви позволяват да вземате решения относно бази данни, уеб сървъри и фреймуъркове. Но първо трябва да решите кои точно! Не, не работи. Всъщност тези решения могат да се решат по-късно в цикъла на разработка, когато информацията е по-изобилна. Катастрофа е, ако архитектите идентифицират рамки предварително, само за да открият, че те не осигуряват необходимата производителност или въвеждат нетърпими ограничения. Само когато архитектът реши да отложи решението, той ще вземе решение, когато информацията е достатъчна; Екипи, които не използват бавни и ресурсоемки IO устройства и рамки, могат да създават бързи и леки тестови среди по преценка на архитектите. Само неговите архитекти се интересуват от това, което наистина има значение, и забавят тези, които не го правят, а такъв екип е късметлията. Глупости, изобщо не разбирам какво имаш предвид. Е, разгледайте добре тази статия, иначе ще трябва да изчакате още 10 години, за да разберете.
| 
Публикувано в 27.09.2017 г. 15:29:46 ч.
|
|
|
Публикувано в 28.09.2017 г. 15:00:37 ч.
|
Хазяин|
Публикувано в 29.09.2017 г. 8:34:23 ч.
|
Публикувано в 27.11.2018 г. 11:12:17 ч.
|
