Навошта нам так шмат класаў у шаблонах праектавання?

Я малодшы распрацоўшчык сярод пажылых людзей і змагаюся шмат з разуменнем іх мыслення, развагі.

Я чытаю Дамен-Driven Design (DDD) і не магу зразумець, чаму мы павінны стварыць так шмат класаў. Калі мы будзем прытрымлівацца гэтым метадам праектавання праграмнага забеспячэння мы ў канчатковым выніку з 20-30 класаў, якія могуць быць замененыя на больш двух файлаў і 3-4 функцый. Так, гэта можа быць брудна, але гэта нашмат больш рамонтапрыдатнасць і чытэльным.

У любы час я хачу паглядзець, што нешта накшталт EntityTransformationServiceImpl гэта, мне трэба прытрымлівацца мноства класаў, інтэрфейсаў, іх выклікі функцый, канструктараў, іх стварэння і гэтак далей.

Простая матэматыка:

  • 60 радкоў кода фіктыўнага супраць 10 класаў X 10 (скажам, у нас зусім розныя такія логік) = 600 радкоў кода бруднага VS. 100 класаў + яшчэ трохі, каб абгарнуць і кіраваць імі; не забудзьцеся дадаць ін'екцыі залежнасцяў.
  • Чытанне 600 радкоў кода бруднага = адзін дзень
  • 100 класаў = адзін тыдзень, яшчэ забыўся, хто што робіць, калі

Усе кажуць, што гэта лёгка захаваць, але для чаго? Кожны раз, калі вы дадаеце новыя функцыянальныя магчымасці, можна дадаць яшчэ пяць класаў з заводамі, арганізацыямі, паслугамі і каштоўнасцямі. Я адчуваю, што гэты від кода рухаецца нашмат павольней, чым брудны код.

Скажам, калі вы пішаце 50K LOC брудны код у адзін месяц, то DDD, што патрабуе шмат аглядаў і змяненняў (я не супраць тэстаў у абодвух выпадках). Адно простае даданне можа заняць тыдзень, калі не больш.

На працягу аднаго года, вы пішаце шмат бруднага кода і нават перапісаць яго некалькі разоў, але са стылем DDD, вы ўсё яшчэ не маюць дастаткова магчымасцяў, каб канкурыраваць з брудным кодам.

Калі ласка, растлумачце. Навошта нам патрэбны гэты стыль DDD і шмат мадэляў?

UPD 1: I received so many great answers, can you guys please add comment somewhere or edit your answer with the link for reading list (not sure from which to start, DDD, Design Patterns, UML, Code Complete, Refactoring, Pragmatic ,... so many good books), of course with sequence, so that I can also start understanding and become senior as some of you do.

198
@ User1318496 Гэта <�я> з'яўляецца </я> дублікат вышэй пытанне. Вы проста не ведаеце пра тое, што вы на самай справе просіце. Сутнасць вашага пытання на самай справе не мае нічога агульнага з OO супраць функцыянальнага праграмавання або шаблонаў праектавання, і ўсё рабіць з арганізацыяй. Пытанне, які вы на самой справе жадаеце адказ, «Чаму асобны код на асобныя атамныя адзінкі?». Цяпер, хоць многія распрацоўшчыкі могуць думаць, што адказ на гэта відавочна, я лічу, што гэта вельмі правільнае пытанне. Адзін, што многія распрацоўшчыкі змагаюцца з адной формы іншы, паколькі яны толькі пачынаюць.
дададзена аўтар Vassilis, крыніца
«Так, гэта можа быць брудным, але яго нашмат больш рамонтапрыдатнасць і чытэльным.». Калі яго неакуратна, як ён можа быць даступны для чытання і рамонтапрыдатнасць?
дададзена аўтар Bigballs, крыніца
@Jared: «Што лягчэй тэставаць?»: Як заўсёды, гэта залежыць ад таго, які тэст. Калі няма ў вас ёсць 100 трывіяльных класаў і ўсе паводзіны сістэмы ў тым, як яны звязаны адзін з адным, то, наогул кажучы, у выніку сістэмы не лягчэй пісаць інтэграцыі і QA тэсты для чым быў наіўны маналіт. У вас ёсць 100 + модульных тэстаў, якія сцвярджаюць, «вы не змянілі свой дызайн», але што? OP можа быць перабольшаны і/або код можа быць добра, але калі стаўленне сапраўды 1 класа на 6 радкоў наіўнага кода для вырашэння тых жа праблем, то ёсць падставы лічыць, калі гэта залішне :-)
дададзена аўтар TraumaPony, крыніца
І «вырашыць тую ж праблему» Я, вядома, маю на ўвазе цалкам вырашыць, што з'яўляецца яшчэ адной вобласцю, ОП можа не бачыць, што аўтары гэтага кода базы см. 600 радкоў кода, якую працу вялікую частку часу не тое ж самае, як 100 класаў сядзяць у рамках гэтага вонкава аказваецца карысныя тэарэмы, якія дазваляюць зрабіць выснову аб тым, што код <�я> на самой справе </я> працуе!
дададзена аўтар TraumaPony, крыніца
@EricLippert: калі код з 100 класаў мае функцыі лёгка растлумачыць карыстачу праграмнага забеспячэння, што наіўны код не робіць, то так, гэта вялікая аналогія. Я думаю, што розніца паміж адтулінай у сцяне і шклопакетам даволі лёгка класіфікаваць як «наіўнае рашэнне не з'яўляецца на самай справе рашэннем, так як яно не задавальняе нашы патрабаванні рэальнага карыстальніка". Такім чынам, калі узламаны-код разам працуе ў дзень, але не могуць быць інтэграваныя ў стэк праграмнага забеспячэння, які працуе фактычныя прыстасаваныя абліцавальны паслугі, то гэта быў бы прыклад слэм-Данк аргумент для напісання больш класаў.
дададзена аўтар TraumaPony, крыніца
@Jared: вы ўжо ставіце вышэй, што 100 класаў лягчэй праверыць, чым маналіт. Я быў толькі ў адказ на гэтую прэтэнзію. Лёгкасць змены кода зусім іншы аргумент супраць маналітаў :-)
дададзена аўтар TraumaPony, крыніца
Варта адзначыць, што ААП не з'яўляецца універсальным лепшым інструментам, таму рашэнні кожнага (часткі) задач шляхам дадання дадатковых класаў, асабліва з ўспадкоўванне, могуць прывесці і прыводзяць да дрэнным, залішне складаным канструкцый. Праблема заключаецца ў тым, што прыдумаць добры дызайн займае шмат часу і дасведчаны распрацоўшчык, і абодва з'яўляюцца дарагімі. Бізнес часта добра з бруднай дызайн, калі ён працуе <�я> зараз .
дададзена аўтар Rorick, крыніца
Вы гэтага не зробіце, калі вы не робіце Java. Калі ўсё ў вас ёсць Java, усё выглядае як клас.
дададзена аўтар Krzysztof Klimonda, крыніца
Прасцей кажучы, гэта значна складаней і займае больш часу, каб напісаць элегантны код, каб людзі згаджайцеся incohesive, але вельмі структураваны код.
дададзена аўтар Mr Rogers, крыніца
Можа быць, адзін павінен Revisit СВАЮ перакананні ?
дададзена аўтар innaM, крыніца
@Polygnome: Я збіраўся ўвесці сапраўды такі жа каментар. Іншы варыянт каментар характарыстыка малодшых распрацоўшчыкаў «Я адчуваю, што такі код шмат рухаецца павольней, чым брудны код.» Гэта не робіць вам ніякай карысці бегчы так хутка, як вы можаце, калі вы праводзіце палову свайго часу працуе ў сцены! Павольнае гладкая, гладкая хутка.
дададзена аўтар CodeCharming, крыніца
Гэтае пытанне, хутчэй, як пытаць "навошта нам так шмат дэталяў, каб стварыць акно? Там усё гэта жаргон з рамамі і створкамі вяровак і двайных павешаных і патройным шкленнем вокладак і гэта занадта заблытаным. Калі я хачу бачыць праз сцяну, я проста атрымаць дрыль, прасвідраваць адтуліну ў сцяне, зроблена. Чаму вокны вытворцы хочуць, каб зрабіць усё настолькі складаным, калі я магу зрабіць гэта так проста? »
дададзена аўтар CodeCharming, крыніца
Я пачынаю адчуваць сябе так жа, як пра класах у цэлым як user1318496. Магчыма, яго больш асабістага перавагі рэч, чым усе астатняе.
дададзена аўтар Graham, крыніца
Асаблівасці @Graham мовы ў пэўнай ступені асабістых пераваг, але, артаганальнай да гэтага пытання. Функцыянальны код можа быць гэтак жа добра напісана лёгка ствараць супраць лёгкага мадыфікавання.
дададзена аўтар R. Schmitz, крыніца
@ 9000 Я думаю, што вы кажаце пра тое, будзе называцца КС - «Класс-арыентаванае праграмаванне»? Калі вы дадаеце класы, не даючы гудок аб фактычна маючых аб'екты, вы не робіце ААП ...
дададзена аўтар R. Schmitz, крыніца
Мы сапраўды не патрэбныя ...
дададзена аўтар Vector, крыніца
Я адзіны, хто думае, што, магчыма, выкарыстоўваючы 20-30 класаў з EntityTransformationServiceImpl s, каб вырашыць простую задачу моцна над-інжынерыі? Я мяркую, што вы маеце на ўвазе Java, чыя культура кінуць шаблонаў дызайну на шаблонах праектавання да кодавая база не неспасціжная ...
дададзена аўтар Solomonoff's Secret, крыніца
Я думаю, што гэта добрае пытанне тут, але гэта хаваецца за гіпербала і расчараванні. @ User1318496, вы маглі б атрымаць выгаду з перафразаваць ваш пытанне няшмат.
дададзена аўтар Warpspace, крыніца
@jamesqf Магчыма, вы бачыце яго як рэлігійнае зварот. Я бачу гэта як функцыя тыпу Рэлігія -> Рэлігія .
дададзена аўтар Chad, крыніца
Некаторыя з гэтых адказаў і каментары кажуць адзін міма аднаго. Я думаю, што гэта магло б дапамагчы думаць пра двух розных пытанняў, напрыклад, "Навошта выкарыстоўваць DDD/дызайн-шаблоны/інш., А ці не 'просты' код <�я> у агульным " (тэстоўваную, развязку і г.д.) і «Чаму <�я> этще кодавая , выкарыстоўваючы так шмат больш класаў, чым я чакаў бы? » (Над-інжынірынг, канкрэтнага мовы абыходныя прыёмы (напрыклад, няма лямбда), састарэлы стыль (напрыклад, Java цяпер мае лямбда), грузапасажырскія culting, тэхнічны доўг і г.д.)
дададзена аўтар Warbo, крыніца
Я знаходжу матэматыку вакол радкоў кода і іх understantability даволі камічнай. Я б вельмі хацеў, каб убачыць падрабязную рэцэнзію аб вашых развагах за лічбамі, якія вы выкарыстоўваеце.
дададзена аўтар Euphoric, крыніца
«Чытанне 600 радкоў кода бруднага = адзін дзень». Гэта няправільна ... Час, неабходнае для мяне, каб прачытаць клас павялічваецца ў геаметрычнай прагрэсіі, будзе ўсё разгалінаванне і галіны misprediction і г.д ... У 600 ліній я на краі маёй зоны камфорту. У 1000 ён звычайна займае ў мяне каля месяца, каб цалкам зразумець клас ....
дададзена аўтар ArTs, крыніца
F22 Raptor ня быў пабудаваны, прымаючы склад IKEA свяцілень і заліванне іх у форме самалёта формы.
дададзена аўтар ArTs, крыніца
Ці з'яўляюцца гэтыя класы паняццяў, якія існуюць у дамене? Калі няма, то чаму яны існуюць? Калі яны робяць, то яны маюць каштоўнасць для бізнэсу, ці не так? Якая будучыня гнуткасць вы страціце, калі вы пішаце 600 радкоў коды бруднай супраць 20-30 класаў, якія ўяўляюць паняцце прадметнай вобласці?
дададзена аўтар Rob Crawford, крыніца
ААП часта анты-мадэль, і чыстая ААП амаль заўсёды анты-мадэль. ААП мае тэндэнцыю сыходзіць крывёй пры ўсіх відах месцаў у вашым кодзе, асабліва кантраляванай. Дызайн мадэль выкарыстоўвае Малаткова (ААП), каб кіраваць ва ўсіх гэтых пазногцях вы раскіданыя з празмернаму ЛСГ. Калі ў вас ёсць клас з імем Provider , Entity , або Працэсар , вы, верагодна, перанапружвацца ООП, але вы можаце, вядома, знайсці шмат людзей, якія высветлілі, як ООП, што цвік.
дададзена аўтар Rich Remer, крыніца
Варта адзначыць, што менавіта гэты спосаб напісання кода не з'яўляецца праблемай, з ўзорамі, але з людзьмі, напісанне кода. Вы можаце напісаць багатае праграмнае забеспячэнне з вялікай колькасцю шаблонаў і, можа быць, 40 або 50 класаў; лёгка. Але калі вы overengineer рэчы ... ну, вы ў канчатковым выніку з 20 класамі для чаго-тое, што магло быць зроблена з 3-ма класамі або з 4 да 5 працэдурных функцый. Важна ўменне зразумець, калі клас збіраецца атрымаць занадта вялікі перапынак у яго ўніз так, каб ён не стаў класам бога.
дададзена аўтар marstato, крыніца
У OPS абароны, добры прыклад таго, што ён можа мець на ўвазе замену простых перамыкачоў на 3 ці 4 ўмовах нізкай кошту з дзяржаўным малюнкам ўсюды. Я бачыў гэта адбылося, і вынік сапраўды можа быць сто класамі замест ста радкоў коды. Абслугоўванне скампраметаваная занадта.
дададзена аўтар Sentinel, крыніца
Не магу паверыць, што ніхто не згадаў адзіную адказнасць прынцып (які, калі вы будзеце прытрымлівацца яго, як правіла, прыводзіць да адукацыі шматлікіх класаў) і SOLID прынцыпаў у цэлым.
дададзена аўтар sizzlecookie, крыніца
@ User1318496 - вам не трэба турбавацца, ёсць шмат паспяховых кампаній, якія падзяляюць ваша меркаванне. І яны наймаюць ўвесь час, таму што патрэба больш распрацоўнікаў падтрымліваць код, які быў хутка напісаны .. :)
дададзена аўтар Fabio, крыніца
Некалькі дзесяцігоддзяў таму я працаваў у краме, дзе мы мадэрнізаваны з (я думаю) DOS 2.0 для DOS 3.0. У першым варыянце, быў толькі адзін каталог з усім у ім. У апошнім выпадку, былі ўведзеныя укладзеныя папкі. спытаў мой бос, «Навошта нам патрэбныя ўсе гэтыя ўкладзеныя папкі? Чаму я не магу проста паставіць усё ў адну тэчку, так што я ведаю, дзе яго знайсці?» Добры час. :)
дададзена аўтар David Lang, крыніца
Дызайн мадэлі не толькі пра рамонтапрыдатнасць, але гэта таксама аб магчымасці паўторнага выкарыстання.
дададзена аўтар Randy E, крыніца
На рызыку наступіць на пальцах ног, таму што ваш мова смокча. Не бярыце, што больш, чым гэта: Sucky мова часта правільны тэхнічны выбар па цэлым шэрагу прычын, але гэта не робіць яго не-Sucky. Што ж тычыцца вашага актуальнага пытання, карэктнасць важней чытальнасці. Або, што крыху па-іншаму: пытанні чытальнасць, паколькі ў дазваляе развагі аб правільнасці. Так што лягчэй праверыць, вашыя 100 класаў або ваш маналітны клас бог? Я стаўлю 100 простых класаў.
дададзена аўтар Sujan, крыніца
@SteveJessop ды, тэставанне сістэмы з'яўляецца менш складаным у абодвух выпадках. Можа быць, нават у большай ступені ў выпадку некалькіх класаў. Розніца заключаецца ў наступным: з маналітам у той час як гэта магло б быць лягчэй знайсці <�я>, дзе , каб унесці змены, ёсць патэнцыйна неабмежаваны час фіксацыі рэчаў, якія могуць зламацца ад яго падрыхтоўкі. Знаходжанне патрэбнага кавалка кода ў драбненні кодавага складаней, але вядомае колькасць, і робячы замену трывіяльна. Я хацеў бы быць упэўненым, чым кінуць косткі, але YMMV і адзін памер не падыходзіць для ўсіх. Для чаго-небудзь менш, чым 10k радкоў, I <�я> можа </я> аддаю перавагу маналіт. Можа быць.
дададзена аўтар Sujan, крыніца
@Theodoros Chatzigiannakis: Гэта проста рэлігійнае зварот. Праблема заключаецца ў бяздумнае пакланенне метадалогіі распрацоўкі праграмнага забеспячэння. Вы проста змяніць бажаство, але захаваць бяздумнае захаванне рытуалаў.
дададзена аўтар Ruks, крыніца
@Rob Кроўфард: Re «... 600 радкоў кода бруднага супраць 20-30 клясаў ...», у вас ёсць два незвязаных рэчаў тут. Гэта цалкам магчыма, каб напісаць 600 радкоў празрыстага, добра каментавалі код, гэтак жа, як гэта магчыма, каб пераўтварыць яго ў 20-30 заблытаных класы.
дададзена аўтар Ruks, крыніца

10 адказы

Гэта задача аптымізацыі

Добры інжынер разумее, што задача аптымізацыі не мае сэнсу без мэты. Вы не можаце проста аптымізаваць, вы павінны аптымізаваць для нешта. Напрыклад, вашыя опцыі кампілятара ўключаюць у сябе аптымізацыю хуткасці і аптымізацыі па памеры кода; яны часам супрацьлеглыя мэты.

Я хацеў бы сказаць сваёй жонцы, што мой стол аптымізаваны для дадае. Гэта проста куча, і гэта вельмі лёгка дадаць матэрыял. Мая жонка палічыў за лепшае б, калі б я аптымізаваны для пошуку, г.зн. арганізаваў мой матэрыял трохі, так што я магу знайсці рэчы. Гэта робіць яго больш цяжкім, вядома, дадаць.

Праграмнае забеспячэнне з'яўляецца такім жа чынам. Вы, вядома, можна аптымізаваць для прадукту creation-- генераваць тону маналітнага кода як мага хутчэй , не клапоцячыся пра яго арганізацыі. Як вы ўжо заўважылі, гэта можа быць вельмі, вельмі хутка. У якасці альтэрнатывы можна аптымізаваць для maintenance-- стварэння макіяжу дотыку больш цяжкага, але зрабіць змены прасцей і менш рызыкоўнымі. Гэта значыць мэта структураванага кода.

Я хацеў бы прапанаваць, што паспяховы праграмны прадукт будзе толькі створаны адзін раз, але шмат, шмат разоў мадыфікаваны. Вопытныя інжынеры бачылі неструктураваных кодавыя асновы ўзяць на сябе сваю ўласную жыццё і становяцца прадукты, павялічваючыся ў памерах і складанасці, пакуль нават невялікія змены не вельмі цяжка зрабіць, не уносячы вялізная рызыка. Калі код быў структураваныя, рызыка можа быць лакалізаваны. Вось чаму мы ідзем на ўсе гэтыя непрыемнасці.

Складанасць прыходзіць ад адносін, а не элементы

Я заўважаю ў вашым аналізе вы глядзіце на quantities-- колькасць кода, колькасць класаў і г.д. Хоць гэта свайго роду цікавае, рэальнае ўздзеянне адбываецца ад стасункаў паміж элементамі, выбухае камбінаторныя. Напрыклад, калі ў вас ёсць 10 функцый і ніякай ідэі, якая залежыць ад таго, у вас ёсць 90 магчымых адносін (залежнасць), вы павінны турбавацца about-- кожныя з дзесяці функцый могуць залежаць ад любога з дзевяці іншых функцый, і 9 х 10 = 90. Вы не маглі б мець ні найменшага падання, якія функцыі рэдагавання, якія зменныя ці як дадзеныя атрымлівае раздадзеныя, таму кодэры ёсць тоны рэчаў, каб турбавацца пра тое, калі рашэнне якой-небудзь канкрэтнай праблемы. У адрозненне ад гэтага, калі ў вас ёсць 30 класаў, але яны ўладкованыя хітра, яны могуць мець як 29 адносін, напрыклад, калі яны накладзеныя адзін на аднаго або размешчаны ў выглядзе чаркі.

Як гэта ўплывае на прапускную здольнасць вашай каманды? Ну, ёсць менш залежнасцяў, праблема значна больш згаворлівым; кодэры не прыйдзецца жангляваць мильона рэчы ў галаве кожны раз, калі яны робяць змены. Такім чынам, звядзенне да мінімуму залежнасць можа быць велізарным штуршком да вашай здольнасці разважаць пра праблему з веданнем справы. Вось чаму мы дзелім рэчы на ​​класы або модулі, і вобласць бачнасці зменных як мага шчыльней, і выкарыстоўваць SOLID прынцыпы .

323
дададзена
@ Jpmc26 Што б прыклад нетрывіяльнай праграмы ААП (скажам> 10k LOC), які выкарыстоўвае мінімальная колькасць класаў і лёгка падтрымліваць і чытаць? Акрамя таго, я не згодны на складанасць чытання кода. Нават без загрузкі кода ў IDE, здаецца, даволі лёгка прытрымлівацца разам з RestoreRunner.RunAsync у RestoreCommand і гэтак далей. Праблема, я думаю, што вы прапусцілі, што NuGets не проста спіс, але дрэва з PackageReference у гэтыя дні, якія кідаюць ключ у вашу разумовую мадэль.
дададзена аўтар Kyle Hodgson, крыніца
@Holger Дык калі Mozilla спыніць даданне новых функцый у Firefox на працягу некалькіх гадоў, каб цалкам перапісаць свой браўзэр? Яны не рабілі. Вядома, вы можаце замяніць часткі коды і ёсць натуральная эвалюцыя, але цалкам перапісаны яд (іншая кампанія, якая зрабіла гэта было MS паміж IE6 і 8 .. не працуе нашмат лепш для іх, чым Netscape)
дададзена аўтар Kyle Hodgson, крыніца
@Holger Вы сцвярджаеце, што сёння «толькі браўзэры, якія альбо былі перапісаныя з нуля ці нават не існуюць, што доўга». Гэта відавочна няправільна. Я сумняваюся, што вы знойдзеце любы папулярны прадукт, які быў перапісаны з нуля і да гэтага часу так паспяхова, як гэта было раней (так як прыклад вы згадалі гэта не так, я сумняваюся, што вы ведаеце, што лепш адзін). Адзіны браўзэр пастаўшчык, які зрабіў нешта падобнае, так як Netscape быў Microsoft пасля IE6. І яны пайшлі ад 90% большасці да нязначнага гульца і што, нягледзячы на ​​пакетірованія браўзэр з самай папулярнай аперацыйнай сістэмай на планеце ... вялікі поспех гэтага.
дададзена аўтар Kyle Hodgson, крыніца
Перазапіс з нуля і сіндрому другой сістэмы з'яўляецца беспамылковым спосабам забіць прадукт, таму ніхто да гэтага часу вакол не робiць гэта. Тое, што вы робіце, гэта паляпшэнне існуючага кода пры рэалізацыі новых магчымасцяў. Ці вы можаце вырашыць перапісаць невялікія часткі прыкладання, заснаванага на падставе неабходнасці (бяспекі або прадукцыйнасці, як правіла, вельмі рэдка рамонтапрыдатнасць). Але перапісаны з нуля? У артыкуле Джоэл дае шмат, шмат прычын, чаму гэта такая дрэнная ідэя.
дададзена аўтар Kyle Hodgson, крыніца
Я хацеў бы адзначыць, аднак, што празмернасць класаў і ўскосна не дапамагае зразумець NOR абслугоўванне. А таксама не згорнуты патокі кіравання (так званы, зваротны выклік пекла).
дададзена аўтар Owen, крыніца
«У якасці альтэрнатывы можна аптымізаваць для стварэння maintenance-- макіяжу сэнсарных больш цяжкімі, але зрабіць змены прасцей і менш рызыкоўнымі. Гэта значыць мэта структураванага кода.» Я прымаю пытанне з няяўнай паняццем, што больш класаў = больш рамонтапрыдатнасць. У прыватнасці, логіка ў многіх класах рассейвання часта робіць яго цяжка знайсці ўсёабдымныя лагічныя паняцці ў кодзе (асабліва без вельмі наўмысных вока на забеспячэнне канцэпцыя вельмі прыкметная), што пагаршае рамонтапрыдатнасць надзвычай.
дададзена аўтар jmibanez, крыніца
Мой ісці да прыкладу гэта ў апошні час стаў
дададзена аўтар jmibanez, крыніца
@Voo У мяне была праблема высветліць, які аб'ект пачаў каманду; што гэта ўсё заблытваецца з падыходам ГА для аналізу опцый каманднага радка. Пасля таго, як вы высвятліце гэта RestoreRunner , вы спрабуеце адсачыць праз, як яго «запыты» ствараюцца, які вядзе ўніз праз прыкладна 4 выклікаў метаду кульмінацыяй выкліку на аб'ект правайдэра, калі я чытаю гэта права. Пошук дрэва не дзіўна, але проста знайсці яго ўключае ў сябе занадта шмат слаёў. Я не разумны. Мне падабаецца код, які старанна намер, каб паказаць намер ззаду яго, і падыход, арыентаваны аб'ект там абвастрае бедныя абстракцыі.
дададзена аўтар jmibanez, крыніца
@JohnWu NuGet трывае няўдачу даволі цяжка на быць модульным. Яго пабочныя бібліятэкі (напрыклад, NuGet.Frameworks ) з'яўляюцца цалкам без дакументаў (я нават не быў у стане знайсці крыніца для іх зборкі.), інструмент каманднага радка не хапае шмат функцыянальнасці VS Plug-in, і гледзячы на ​​код, трэба пабудаваць так шмат аб'ектаў, проста каб атрымаць адзін кавалак працу азначае, што вы павінны мець вельмі шырокае разуменне ўсёй кодавай базы для выкарыстання якой-небудзь з яго. Гэта ўжо фактычна маналітнае, так што я не купляю вашы аргументы.
дададзена аўтар jmibanez, крыніца
@JohnWu Акрамя таго, што гэта <�я> які распаўсюджваецца </я> Від у бок мадэляў. DI прымаецца рэлігійна. Няма DI Прыхільнік я ведаю, ня кажа: «Вось што праблема, DI добра, як рашэнне выглядае», яны кажуць: «Вы павінны напісаць код OO і гэта азначае, што вы павінны мець DI. І пра, дарэчы, вы павінны прытрымлівацца SOLID прынцыпы «. Практычна ніхто не кажа пра тое, што праблемы гэтыя ідэі павінны рэальна вырашыць. Яны проста прапанавалі як правілы, якія нібыта ўжываюць ўвесь час.
дададзена аўтар jmibanez, крыніца
@ R.Schmitz Сапраўды добрыя праграмісты не думаю, што з пункту гледжання правілаў, у першую чаргу. Яны думаюць, што з пункту гледжання вырашэння праблем. Яшчэ больш важна, добрыя праграмісты прызнаюць, калі іншыя праграмісты ўжо не думаць у гэтым мысленні і падштурхнуць іх да яе, а не пра тое, правілы.
дададзена аўтар jmibanez, крыніца
@ R.Schmitz я кажу вельмі добрыя праграмісты інвертаваць мысленне, хоць. Яны не думаюць, «Вы павінны аптымізаваць свой код для чытання.» Яны думаюць, што, «Мы павінны вырашыць гэтую праблему, каб быць у стане зразумець код, каб зрабіць змены пазней падчас або іншымі распрацоўшчыкамі.» Першы накладае рашэнне без тлумачэння праблемы. Другая сцвярджае, праблема і застаецца адкрытым для розных рашэнняў, і ў яго ёсць мэта, дзе гэта нашмат больш ясна, калі вы паспяхова або няма (хоць яна па-ранейшаму суб'ектыўна).
дададзена аўтар jmibanez, крыніца
Я б для поўнага 10 × 10 = 100 для камбінаторныя: гэтыя функцыі цалкам могуць быць рэкурсіўны, і ў прыватнасці, дрэнны код, ня necesarrily відавочна так.
дададзена аўтар LessIsMore, крыніца
Добра напісана, але гэта, магчыма, не хапае, чаму «ствараецца адзін раз, але шмат, шмат разоў мадыфікаваны» важна? (Калі ўвесь код у EntityTransformationServiceImpl , вы вымушаныя вучыцца <�я>, як працуе ўся рэч </я>, перш чым вы можаце гэта выправіць - але калі, напрыклад, што-то не так з фармату і Formatter клас апрацоўвае гэта, вам трэба толькі навучыцца <�я>, як гэтая частка працы . Плюс чытанне свайго ўласнага кода пасля ~ 3-х месяцаў, як чытанне кода незнаёмца.) я адчуваю, што большасць з нас падсвядома думаў пра гэта, але гэта можа быць з-за вопыту. Не 100% упэўнены ў гэтым.
дададзена аўтар R. Schmitz, крыніца
@Holger Не, таму што пры даданні новага кода папярэдні код не так важны, як вашыя стандарты напісання. Калі <�я> праграмнае забеспячэнне </я> робіць гэта жудасна дорага, каб дадаць код, то гэта проста брудны код. Вы можаце мець зусім модульны праект, але дадаць хуткі і лёгкі код. Вы таксама можаце мець ўсю праграму ў адным класе бога, але выдаткаваць некаторыя думкі аб тым, як зрабіць складанне які абслугоўваецца пазней. Што тычыцца тых кампаній, пра якія вы кажаце, я толькі чуў аднаго і ён называўся Netscape .
дададзена аўтар R. Schmitz, крыніца
@Holger Калі кампанія стварае новы прадукт, які не перапісвання кода базы, гэта <�я> стварэння у першую чаргу. У адваротным выпадку вы спрачаецеся, што сённяшнія AutoCAD і 3DSMax і г.д., проста «перапісвае» 1968 UNISURF і Кліч Duty: Modern Warfare 3 з'яўляецца толькі перапісваннем DOOM. Акрамя таго, я не кажу, што гэта не адбудзецца, так што ў тых выпадках, было б аказалася лепш, калі б ён не зрабіў.
дададзена аўтар R. Schmitz, крыніца
@Holger вашых інтэрпрэтацый таго, што я сказаў, а таксама тое, што перазапіс не правы. Службовы абавязак з'яўляецца не перапісванне DOOM. Гэта зусім іншы прадукт зусім іншым распрацоўшчыкам. Вядома, вы можаце сказаць, кожны кавалак кода проста перапісваюць першай частцы кода калі-небудзь напісаных, але гэтае слова проста губляе ўсякі практычны сэнс, і вы павінны, верагодна, задаць пытанне тут тады.
дададзена аўтар R. Schmitz, крыніца
@Holger Паглядзіце, Firefox быў выпушчаны ў 2004 годзе, гэта значыць 14 гадоў; Android у 2007 годзе, гэта 11 гадоў. У ІТ, гэта не толькі старыя, гэта <�я> старажытны . Згодна з вашай тэорыі, Firefox павінен быў «састарэлым, заплаці» (у той жа час), непрыдатныя месіва да 2006 году, або Android каля 2010 года гэтыя проста патанчаюцца адмаўленне эфектыўнасці што абслугоўваецца коды, таму што яны зараз лепш амаль кожны аспект - бяспека, зручнасць выкарыстання, набор функцый, вы называеце яго. Падобна на тое, у вас ёсць толькі асабістыя планы супраць які абслугоўваецца кода.
дададзена аўтар R. Schmitz, крыніца
@ Jpmc26 Гэта таму, што добрыя праграмісты ведаюць, што ўсе «правілы» павінны прымяняцца прагматычна; ўсе правілы аўтаматычна атрымаць «за выключэннем таго, калі ў вас ёсць сапраўды добрая прычына, каб" у канцы . Калі вы працуеце з людзьмі, якія дагматычныя замест прагматычнага, што атрымаецца дрэнна для любога правілаў.
дададзена аўтар R. Schmitz, крыніца
@Holger Няпраўда, ваша першапачатковае заява была «<�я> праграмнае забеспячэнне распрацавана такім чынам, што робіць стварэнне жудасна дорага, таму мы павінны захоўваць і падтрымліваць яго, пакуль мы не дасягнем кропкі, што гэта цалкам састарэлі, лата беспарадак павінен памерці. »у артыкуле я звязваў можа даць вам больш разумення, чаму перапісвае дрэнна, калі вы зацікаўленыя. Ваша першапачатковае заява была аспрэчана з дапамогай Firefox і Android. Усе, пасля гэтага было проста абмеркаванне, што каментары не, так што давайце проста спыніць гэта зараз тут.
дададзена аўтар R. Schmitz, крыніца
@Holger Вы пісалі <�я> [A] можа мець важнае значэнне, так як [B] прыводзіць да [C] . Гэта тое, што ваш «можа» прымяняцца да. Тэорыя у вас была ў тым, што [B] прыводзіць да [C]. Два велізарных прыкладаў, калі не прымяняюцца хутка даказаць, што [B] не выклікае [C]. Калі кропка была нешта яшчэ, то я не аспрэчваць, што і паказаў, што адзін з вашых памяшканняў было няправільным.
дададзена аўтар R. Schmitz, крыніца
@ Jpmc26 я стаўлю "правілы" ў двукоссі, таму што яны рэкамендацыі . Правіла не можа пачынацца з «Вы павінны». Калі адзін не варта нават асноўныя прынцыпы, такія як «<�я>, вы павінны аптымізаваць свой код для лёгкачытэльнасць " ці "<�я>, вы павінны прытрымлівацца пагадненням код, які вы каманды </я>», (усе з даданнем «за выключэннем таго, калі ў вас ёсць сапраўды добрая прычына, каб не»), то яны больш чым" сапраўды добры праграміст ".
дададзена аўтар R. Schmitz, крыніца
@ Jpmc26 Справядліва, але прашу 5 чамусьці пытання пасля таго, як вы сказалі, «вы павінны прытрымлівацца канвенцый кода, які вы каманда» не добра для вашай кар'еры. Часам гэта занадта відавочна, каб заўсёды дадаць тлумачэнне.
дададзена аўтар R. Schmitz, крыніца
@ Jpmc26 «Я бяру пытанне з паняццем, што больш класаў = больш рамонтапрыдатнасць.» Залежыць, вядома, ад таго, што аперанд «больш» ёсць. У гэтым выпадку, «50K LOC брудны код.» Так што я не ўпэўнены, што я згодны, у пэўным кантэксце паста ФПА ст.
дададзена аўтар John Wu, крыніца
NuGet, верагодна, не з'яўляецца вялікім прыкладам, так як яго модульнасць можа быць выклікана больш вонкавымі патрабаваннямі, чым архітэктара overenthusiasm-- гэта, у рэшце рэшт, якая пашыраецца структура для кіравання пашыраецца структур, якая працуе як commandlet PowerShell ўнутры пашырэння Visual Studio. Цяпер, калі я думаю пра гэта, калі б усе гэтыя рэчы былі напісаныя monlithically, NuGet не можа нават існаваць ...
дададзена аўтар John Wu, крыніца
@Holger У маім пасце я распавяду дзве магчымыя мэты аптымізацыі. Вядома, вы можаце аптымізаваць для іншых мэтаў too-- напрыклад каб «звесці да мінімуму колькасць перазапісаў» (якая вельмі падобная на аптымізацыю для рамонтапрыдатнасць) або «максімальнага зручнасці перапісванне», які падобны, але не такі ж, як аптымізаваць для прастаты стварэння прадукту (існуюць дадатковыя патрабаванні, такія як зваротнай сумяшчальнасці і цотнасці функцыі). Я не прапісваць мэты, я проста хачу, каб падкрэсліць адрозненні, як сродак тлумачэння абгрунтавання дбайнай распрацоўкі.
дададзена аўтар John Wu, крыніца
@Taw «знайсці шаблоны праектавання усімі сродкамі і любым коштам рэлігійна.» Гэта гучыць як праектнае рашэнне (выхад) не дызайнерскія мэты (уваход). Калі вы з франтальнай загрузкай вашых жаданых вынікаў у аптымізацыі ўводу, працэс не дадае вялікае значэнне (яно не праходзіць тэст эндагенных), а.к.а. вы робіце гэта няправільна. Падобна на тое, ваш архітэктар проста мае «Pet NFR ,» якія заўсёды дрэнна.
дададзена аўтар John Wu, крыніца
@JohnWu гэта тлумачэнне чынам лепш і лягчэй зразумець той, які я калі-небудзь чытаў.
дададзена аўтар Les H, крыніца
Калі я першы вучачыся код, які я напісаў праграму, усё ў адным класе, ён працаваў добра, але патрапіў у кропку, дзе робіць простае змяненне будзе ўвесці 4 ці 5 памылак, якія б мяне пару дзён, каб выправіць. Я пачаў даследаваць дызайн і зламаў усе з ў каля 10 класаў і мае праблемы абслугоўвання зніклі. Я зрабіў шмат змен з 0 памылак, уведзеных пасля гэтага рэарганізаваць. Я думаю, што гэты ўрок трэба вывучыць цяжкі шлях, каб сапраўды зразумець, чаму гэта каштуе.
дададзена аўтар reggaeguitar, крыніца
@Voo, што залежыць ад вызначэння «мінімальнага колькасці класаў». У нас ёсць дадатак, якія складаюцца з тысяч класаў, тым не менш, я ведаю, што калі б мы выкарыстоўвалі некаторыя часта выкарыстоўваюцца асновы і «лепшыя практыкі» у нас было дваццаць разоў больш ...
дададзена аўтар Holger, крыніца
@ R.Schmitz гэта цікавы момант. «Ствараецца адзін раз, але шмат, шмат разоў мадыфікаваны» можа мець важнае значэнне <�я>, паколькі </я> праграмнае забеспячэнне распрацавана такім чынам, што робіць стварэнне жудасна дорага, таму мы павінны захоўваць і падтрымліваць яго, пакуль мы не дасягнем кропкі, што гэта цалкам састарэлыя, лата беспарадак павінен памерці. Не ўсе вынікаюць гэтаму узоры. Там з'яўляюцца кампаніі былі выпуск праграмнага забеспячэння таксама заўсёды дзень, калі развіццё пачынаецца новая версія, напісаная з нуля, уключыўшы ў яго ўсе ўрокі, вынятыя з распрацоўкі папярэдняй версіі, а таксама прыезджыя тэхналогіі.
дададзена аўтар Holger, крыніца
@ R.Schmitz вы ведаеце, што ўсе браўзэры таго часу былі заснаваныя на арыгінальнай мазаікі, у тым ліку, напрыклад, Internet Explorer, каб назваць той, які ўсё яшчэ існуе? Як вы думаеце, колькі з сучасных браўзэраў па-ранейшаму заснаваныя на ім? Сёння ёсць толькі браўзэры, якія альбо былі перапісаныя з нуля (больш чым адзін раз) з тых часоў, або нават не існуюць, што доўга. У свеце тэорыі, што першы браўзэр мог быць напісана ў модульным, пашырацца, перспектыўнай чынам, быць гатовым да любых змен, што прынясе будучыню. На самай справе, няма. Патрабаванні і тэхналогіі мяняюцца занадта шмат.
дададзена аўтар Holger, крыніца
@ R.Schmitz так што вы хочаце сказаць, што было б лепш, <�я>, калі «Кліч Duty: Modern Warfare 3» быў заснаваны на зыходным кодзе Згубы, і што гэта прыкмета дрэннага дызайну праграмнага забеспячэння Згубы, што гэта ISN «т? Ці вы на самой справе, якія пацвярджаюць мой пункт гледжання, што старое праграмнае забеспячэнне будзе заменена новым, як бясконца абнаўляючы стары ілюзія?
дададзена аўтар Holger, крыніца
@Voo я не бачу, дзе я сцвярджаў, што ўсе распрацоўшчыкі праграмнага забеспячэння робяць гэта. Можа быць, вы маеце рацыю, і Firefox ніколі не быў перапрацаваны з нуля пасля таго, як ён пачаў сваё жыццё як перапрацаваная-з нуля замена Netscape. Магчыма, гэта прыкмета таго, наколькі добра Firefox быў распрацаваны. Ці, можа быць, вы толькі збіраецеся пачаць flamewar, так як якасць Firefox »ўспрымаецца вельмі спрэчным. Не адкрывайце гэтую слоік з чарвякамі.
дададзена аўтар Holger, крыніца
@ R.Schmitz, здаецца, вы цалкам адсутнічае кропка. Не мае значэння, ці з'яўляецца новае праграмнае забеспячэнне з'яўляецца «перапісванне» са старога або зусім новы прадукт. Справа ў тым, што <�я> новы </я> праграмнае забеспячэнне, да якога ён не мае значэння, наколькі лёгка ўтрыманне старога ёсць. Ці атрымліваеце Вы цяпер? Старая праграма будзе паміраць. Старая праграма замяняюцца на новым. Гэта непазбежны факт. Вы можаце ўплываць толькі Ці, што новы адзін за вамі ці ў вашых канкурэнтаў. Але вы таксама можаце аптымізаваць праграмнае забеспячэнне для тэхнічнага абслугоўвання, што робіць распрацоўку новага праграмнага забеспячэння дарагі, і паспрабаваць пазбегнуць, каб напісаць новы назаўжды ...
дададзена аўтар Holger, крыніца
@Voo дакладна, Microsoft была толькі адзін перазапісаўшы свой браўзэр з нуля. Цяпер імя <�я> любы </я> браўзэр акрамя таго, што ад Microsoft, якая існавала ў той час (Netscape 4 або вышэй), што па-ранейшаму існуе сёння (не маючы асноўную перапісваюць, іншымі словамі, да гэтага часу на аснове Mosaic кода). Ну, на самай справе Netscape зрабіў рерайт таксама, але на баку яе заснавання Mozilla, што прывяло да распрацоўкі Firefox. Так перапісванне «забіта» прадукт, таму што ён спарадзіў новы. Як вы думаеце, браўзэр Netscape, заснаваны на старым кодзе усё яшчэ можа існаваць сёння? Mozilla не пагадзілася.
дададзена аўтар Holger, крыніца
@JohnWu ваш спосаб апісання аптымізацыйных функцыі розных мэтаў вельмі добра, я не запярэчу, што. Гэта вельмі добры адказ.
дададзена аўтар Holger, крыніца
@ R.Schmitz за выключэннем таго, што галоўны фундатар Firefox »когда-то вырашыў напісаць свой уласны браўзэр пад назвай Chrome, ня заснаваны на Firefox наогул, вы маеце рацыю. Firefox з'яўляецца старажытным. Тым не менш, тое, што вы хочаце давесці? Маё першае заява была, што сёння ні адзін браўзэр не заснаваны на Mosaic, таму што ўсе існуючыя браўзэры небудзь былі цалкам перапісаны з тых часоў або нашмат маладзей. Улічваючы, што Мазаіка з 1993 года, Firexfox <�я> з'яўляецца </я> нашмат маладзей. Такім чынам, вы не даказаць, што не мая праўда. Акрамя таго, я не супраць што абслугоўваецца коды, ніколі не казаў. Хутчэй за ўсё, я супраць кода, які ведае толькі <�я> расце .
дададзена аўтар Holger, крыніца
@ R.Schmitz вы раздзіраюць гэтую фразу з кантэксту. Прысуд быў «<�я>" створаны адзін раз, але шмат, шмат разоў мадыфікаваны "<�б> можа мець важнае значэнне, так як праграма распрацавана такім чынам, што робіць стварэнне жудасна дорага ... </я>». Гэтая здагадка аб шаблоне, які можа </я> прымяніць да <�я> некаторая колькасць праграмных праектаў. Вы ўжо ўпусцілі момант, адкрыўшы абмеркаванне вішняй праграмнага забеспячэння, два прыкладу IIRC, які быў захаваны на працягу вельмі доўгага часу, ігнаруючы ўсе мільярды праграмнага забеспячэння, якое <�я> зрабіў </я> памерці. Гэта спекулятыўнае зацвярджэнне не «аспрэчана» толькі два прыкладаў.
дададзена аўтар Holger, крыніца
Вялікі адказ, але ..: <�я> У якасці альтэрнатывы можна аптымізаваць для забеспячэння </я> азначае, што гэта толькі адзін і адзін О.П. скардзіцца. Там таксама <�я> Аптымізацыя для пошуку шаблонаў праектавання усімі сродкамі і любым коштам рэлігійна . Ключавое слова <�я> разумны </я> і проста стварыць шмат класаў гэта не дадзена. DI з'яўляецца вялікім/жахлівым прыкладам, дзе, як адзін мудры чалавек напісаў, вы атрымліваеце 50C канцэпцыю 100 $ слоўцаў.
дададзена аўтар pong, крыніца
Добры адказ, але з відавочным недаглядам: вельмі верагодна, што «600 радкоў кода бруднага» не могуць быць правераны належным чынам, і што само па сабе справа выключальнік для падыходу выступаў у АП.
дададзена аўтар Nath, крыніца

Ну, у першую чаргу, чытальнасць і maintability часта ў вачах таго, хто глядзіць.

Што чытаецца вам не можа быць вашым суседам.

Рамонтапрыдатнасць часта зводзіцца да зразумеласці (як лёгка гэта паводзіны ці паняцце выявілі ў кодавую) і Discoverability яшчэ адна рэч суб'ектыўная.

DDD

Адзін са спосабаў DDD дапамагаюць камандам распрацоўшчыкаў, прапаноўваючы спецыфічны (пакуль яшчэ суб'ектыўны) спосаб арганізацыі вашых канцэпцый коды і паводзіны. Гэта <�ет> ўмоўнасць робіць яго лягчэй выявіць рэчы, і, такім чынам, прасцей у абслугоўванні прыкладання.

  • Паняцці дамена кадуюцца як суб'екты і агрэгаты </літый>
  • Паводзіны дамена знаходзіцца ў Entities або даменных службаў
  • <�Літый> Паслядоўнасць забяспечваецца за кошт сукупнага Карані
  • праблемы Сталасць апрацоўваюцца Сховішчы

Такое размяшчэнне не <�ет> аб'ектыўна прасцей у абслугоўванні. Гэта, аднак, <�ет> вымерна лягчэй падтрымліваць, калі ўсе разумеюць, што яны працуюць у кантэксце DDD.

класы

класы help with maintainability, readability, discoverability, etc... because they are a well known convention.

In Object Oriented settings, класы are typically used to group closely related behaviour and to encapsulate state that needs to be controlled carefully.

Я ведаю, што гэта гучыць вельмі абстрактна, але вы можаце думаць пра гэта так:

With класы, you don't necessarily need to know how the code in them works. You just need to know what the class is responsible for.

класы allow you to reason about your application in terms of interactions between well defined components.

Гэта зніжае кагнітыўную нагрузку пры развазе пра тое, як працуе прыкладанне. Замест таго, каб успомніць, што 600 радкоў кода выконвае, вы можаце думаць аб тым, як 30 кампанентаў ўзаемадзейнічаць.

І, прымаючы пад увагу гэтыя 30 кампанентаў, верагодна, ахопліваюць 3 слаёў вашага прыкладання, вы, верагодна, толькі кожны павінен быць развагі аб прыкладна 10 кампанентаў, у той час.

Гэта здаецца даволі кіраваным.

рэзюмэ

Па сутнасці, тое, што вы бачыце, старэйшыя распрацоўшчыкі зрабіць гэта:

They are breaking down the application into easy to reason about класы.

Яны затым арганізаваць іх у лёгка разважаць пра слаёў.

They are doing this because they know that, as the application grows, it becomes harder and harder to reason about it as a whole. Breaking it down into Layers and класы means that they never have to reason about the entire application. They only ever need to reason about a small subset of it.

64
дададзена
Акрамя таго, невялікія класы лягчэй замяніць/рэфактарынг.
дададзена аўтар Pieter, крыніца
«З класамі, вам не абавязкова трэба ведаць, як код у іх працуе. Вам проста трэба ведаць, што клас адказвае за». Класы, безумоўна, не з'яўляецца адзіным спосабам для дасягнення гэтай мэты, хоць яны могуць быць карысным спосабам у некаторых абставінах. Што яшчэ больш важна, хоць, гэта не з дапамогай класаў, дасягае гэтай мэты, гэта <�я> добры выбар дызайну </я> распрацоўшчыкам, што робіць. Класы не чароўны соус, які дае вам гэта, на любым участку.
дададзена аўтар jmibanez, крыніца
У адпаведнасці з ОП, які «змагаецца шмат з разуменнем іх мысленне, разважанне», здаецца, што абгрунтаванне стварэння кода, які лёгка разважаць пра тое, ці не так лёгка разважаць пра.
дададзена аўтар Erb, крыніца
Так, перабудова дрэнна. Так забіваюць шчанюк. Ніхто тут не выступае за небудзь. logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/169/ & hellip;
дададзена аўтар Warpspace, крыніца
Акрамя таго, «элегантнасць» у кантэксце распрацоўкі праграмнага забеспячэння часта Хорек Слова. en.wikipedia.org/wiki/Weasel_word
дададзена аўтар Warpspace, крыніца
Тое ж самае можна сказаць і пра любым падыходзе да арганізацыі кода. Усё залежыць ад разумення каманды абслугоўвання чаму код арганізаваны як гэта. Вось і ўвесь сэнс выкарыстання устояных і разумеюцца канвенцый.
дададзена аўтар Warpspace, крыніца
@ Jpmc26 Я згодны, класы не магія. Яны, аднак, часта прапаноўваюць падтрымку на ўзроўні мовы для рэчаў, як інкапсуляцыя і дзяржаўных кантрактаў.
дададзена аўтар Warpspace, крыніца
@ Icc97 гэта гучыць, як вы кажаце, вопыт, кантэкст і веды канвенцый і мадэляў мае вялікае значэнне. І што малодшы DEV можа не хапаць гэтыя рэчы, што робіць яго цяжка для іх звяртаў увагу на код, напісаны з гэтымі рэчамі у выглядзе.
дададзена аўтар Warpspace, крыніца
Перабудовы робяць <�я> не </я> даць больш ремонтопригоден або зразумелы код - зусім наадварот, нягледзячы на ​​тое, што вы сцвярджаеце. Хто мае патрэбу ў AddressServiceRepositoryProxyInjectorResolver , калі вы можаце вырашыць гэтую праблему больш элегантна? Дызайн мадэль дзеля шаблонаў праектавання проста прыводзіць да непатрэбнага складанасці і шматслоўя.
дададзена аўтар Ian Yates, крыніца
Вялікі адказ! Я здзіўлены, што каментары не згодны з вамі
дададзена аўтар reggaeguitar, крыніца
Калі яны <�я> першы </я> разбіць яго на класы і <�я>, то </я> аб'яднанне гэтых класаў у пластах, гэта не дзіўна, усё не заблытацца. Вы хочаце зрабіць гэта наадварот (таксама, вы хочаце, каб увесці класы для пачатку).
дададзена аўтар Clearer, крыніца
а затым ён прымае толькі адзін развадны ключ, каб разбіць ўвесь шаблон
дададзена аўтар user2890248, крыніца
<�Р> Калі ласка, патлумачце мне, навошта нам патрэбны гэты DDD стыль, шмат шаблонаў?

Па-першае, звярніце ўвагу: важная частка DDD не з'яўляецца шаблоны , але выраўноўванне намаганняў у галіне развіцця з бізнесам. Грег Янг адзначыў, што кіраўнікі ў сіняй кнізе ў няправільным парадку .

Але на ваш канкрэтны пытанне: ці ёсць, як правіла, нашмат больш класаў, чым можна было б чакаць, (а), таму што прыкладаюцца намаганні, каб адрозніць паводзіны дамена ад вадаправоднага і (б) таму, што дадатковыя намаганні для таго, каб гарантаваць, што паняцці у мадэлі прадметнай вобласці выяўляецца ў відавочным выглядзе.

Папросту, калі ў вас ёсць два розных паняцця ў галіне, то яны павінны быць розныя ў мадэлі , нават калі яны адбываюцца адны і тыя ж ва ўяўленні памяці .

У сутнасці, вы будуеце дамена канкрэтнага мовы, які апісвае мадэль на мове бізнесу, такім чынам, каб спецыяліст у прадметнай вобласці павінны быць у стане глядзець на яго і вызначыць памылкі.

Additionally, you see a bit more attention paid to separation of concerns; and the notion of insulating consumers of some capability from the implementation details. See D. L. Parnas. The clear boundaries empower you to change or extend the implementation without the effects rippling throughout you entire solution.

Матывацыя тут: для прыкладання, якое з'яўляецца часткай асноўнай кампетэнцыі бізнесу (гэта значыць месца, дзе ён вытворны канкурэнтная перавага), вы хочаце, каб мець магчымасць лёгка і нядорага замяніць паводзіны дамена з лепшай варыяцыяй. У сутнасці, у вас ёсць часткі праграмы, якія вы хочаце хутка развівацца (як стан развіваецца на працягу доўгага часу), і іншыя часткі, якія вы хочаце змяніць павольна (як захаванае стан); дадатковыя пласты абстракцыі дапамогі незнарок злучэння адзін з адным.

Дзеля справядлівасці: некаторыя з іх таксама аб'ектна-арыентаванага пашкоджанні мозгу. Узоры першапачаткова апісаны Эванс заснаваныя на праектах, Java, што ён удзельнічаў у 15+ гадоў таму; стан і паводзіны цесна звязаны ў тым стылі, што прыводзіць да ўскладненняў, вы можаце аддаць перавагу, каб пазбегнуць; см Успрыманне і дзеянне Сцюарт Halloway або <�а HREF = "http://number-none.com/blow/john_carmack_on_inlined_code.html" отн = "noreferrer"> Ўбудаванне кода Джон Кармак.

<�Р> Незалежна ад таго, якую мову вы працуеце, праграмаванне ў функцыянальным стылі не дае перавагі. Вы павінны рабіць гэта кожны раз, калі гэта зручна, і вы павінны падумаць аб рашэнні, калі гэта не зручна. Кармак, 2012 па
29
дададзена
Я думаю, што гэта лепшы адказ тут. Хоць я далёка не прададзенага на DDD, гэты адказ, вядома, па меншай меры, тлумачыць, што гэта на самай справе і актуальнай матывацыяй для яго, а не апелюючы да агульных банальнасцяў, якія нічога не значаць.
дададзена аўтар jmibanez, крыніца
Джон Кармак з'яўляецца выдатным прыкладам ИМО, так як ён добра вядомы для напісання кода, гэта і чыста і лёгка зразумець, у той жа час, быўшы добра выступаць. Гэта асабліва прыкметна, як адсочваць свой код з надыходзячымі тэхналогіямі - з лепшымі працэсарамі і памяццю, вы можаце ўбачыць шмат рэчаў, падштурхнулі ад «гэта павінна быць вельмі лаканічнымі», каб «гэта павінна быць сапраўды ясна/ізаляваным/... ». Адзін з самых прагматычных праграмістаў я ведаю :)
дададзена аўтар Luaan, крыніца
Я збіраўся дадаць свой адказ, пакуль я не прачытаў гэта. Я хацеў бы падкрэсліць, першы абзац, што мэта складаецца ў тым, каб змадэляваць бізнес-канцэпцый ў галіне праграмнага забеспячэння для выраўноўвання праграмнага забеспячэння з бізнес-патрабаваннямі. Шчыра кажучы, аналітык ваджэння праект павінен таксама выказаць, колькі часу, драйвера для дастаўкі, і код/​​якасць тэсту або паўната павінна быць скарэкціравана адпаведным чынам.
дададзена аўтар Sentinel, крыніца

Ёсць шмат добрых кропак у іншых адказах, але я думаю, што яны прапускаюць ці не падкрэсліць важную канцэптуальную памылку вы робіце:

Вы параўноўваеце намаганні, каб зразумець поўную праграму.

Гэта не з'яўляецца рэальнай задачай з большасцю праграм. Нават простыя праграмы складаюцца з так шмат коды, які проста немагчыма кіраваць усімі яго ў галаве ў любы момант часу. Ваш адзіны шанец знайсці частка праграмы, якая мае дачыненне да задачы (выпраўленне памылкі, рэалізуючы новую функцыю) і працаваць з гэтым.

Калі ваша праграма складаецца з велізарных функцый/метадаў/класаў гэта практычна немагчыма. Вы павінны разумець, сотні радкоў кода проста вырашыць, калі гэты кавалак кода мае дачыненне да вашай праблеме. З ацэнкамі вы далі становіцца лёгка правесці тыдзень толькі, каб знайсці кавалак кода, які неабходна працаваць.

Параўнайце гэта з кодавай базы з невялікімі функцыянальнымі/метадаў/класаў, названых і арганізаваных у пакеты/прастор імёнаў, што робіць яго відавочным, дзе знайсці/паставіць дадзеную частку логікі. Калі ўсё зроблена правільна ў многіх выпадках вы можаце перайсці прама да патрэбнага месца, каб вырашыць вашу праблему або, па меншай меры, да месца, адкуль распальвання ваш адладчык прывядзе вас у патрэбнае месца ў пару скачкоў.

Я працаваў у абодвух відах сістэм. Розніца можа быць лёгка на два парадку ў прадукцыйнасці для супастаўных задач і супастаўнага памеру сістэмы.

The effect this has on other activities:

  • testing becomes much easier with smaller units
  • less merge conflicts because chances for two developers to work on the same piece of code are smaller.
  • less duplication because it is easier to reuse pieces (and to find the pieces in the first place).
26
дададзена

Because testing code is harder than writing code

Шмат адказаў далі добрыя развагі з пункту гледжання распрацоўніка - што абслугоўванне можа быць зменшана, за кошт стварэння коды больш напружаную пісаць у першай чаргі.

However, there is another aspect to consider - testing can only be fine-grained as your original code.

Калі вы пішаце ўсё ў маналіце, адзіны эфектыўны тэст, які вы можаце напісаць гэта «з улікам гэтых уваходаў, з'яўляецца выхад правільна?». Гэта азначае, што любыя памылкі, выяўленыя, з'яўляюцца вобласцю бачнасці «дзесьці ў вялізнай кучы кода».

Вядома, вы можаце мець распрацоўшчык сядзець з адладчыкам і знайсці менавіта тое, дзе праблема пачалася і праца над выпраўленнем. Гэта займае шмат рэсурсаў, і дрэннае выкарыстанне часу распрацоўніка. Уявіце сабе, што калі-небудзь недахоп у вас ёсць, прыводзіць да распрацоўніку неабходнасць адладкі ўсёй праграмы зноў.

Рашэнне: Шматлікія невялікія тэсты, якія дакладна вызначыць, адзін канкрэтны, патэнцыйны адмову кожнага.

Гэтыя невялікія тэсты (для тэстаў прыкладу Unit), маюць перавагу праверкі канкрэтную галіне кодавых і дапамагае знайсці памылкі ў абмежаваным аб'ёме. Гэта не толькі паскарае адладку, калі тэст не пройдзены, але таксама азначае, што, калі ўсе вашы маленькія тэсты не - вы можаце лёгка знайсці няспраўнасць у вашых вялікіх выпрабаванняў (гэта значыць, калі гэта не ў канкрэтнай тэстоўванай функцыі, яна павінна быць ва ўзаемадзеянні паміж імі).

Як павінна быць ясна, каб зрабіць меншыя выпрабаванні азначае, што ваш кодавы павінна быць падзеленыя на больш дробныя кавалкі каго правяраюць. Спосаб зрабіць гэта, на вялікім камерцыйным кодавым, часта прыводзіць да кода, які выглядае як тое, што вы працуеце з.

Гэтак жа, як пабочнае заўвага: Гэта не значыць, што людзі не будуць прымаць рэчы «занадта далёкія». Але ёсць законныя падставы для падзелу баз коды на больш дробныя/менш падлучаныя часткі. - калі зроблена тлумачальна

19
дададзена
У той час як вашыя адрасы адказу толькі тэставанне і проверяемость, што з'яўляецца самым важным пытаннем, які некаторыя іншых адказаў цалкам ігнаруецца, так +1.
дададзена аўтар Nath, крыніца
<�Р> Калі ласка, патлумачце мне, навошта нам патрэбны гэты DDD стыль, шмат шаблонаў?

Многія (большасць ...) з нас сапраўды не <�моцны> патрабуецца іх. Тэарэтыкі і вельмі прасунутыя, дасведчаныя праграмісты пішуць кнігі аб тэорыі і метадалогіі, як вынік вялікай колькасці даследаванняў і іх глыбокага вопыту - гэта не значыць, што ўсе яны пішуць гэта дастасавальна да кожнага праграмісту ў сваёй паўсядзённай практыцы.

Як малодшы распрацоўшчык, гэта добра, каб чытаць кнігі, такія, як адзін вы згадалі, каб пашырыць свае перспектывы, і вы даведаецеся аб некаторых праблемах. Ён таксама пазбавіць вас ад атрымання збянтэжана і збянтэжаным, калі вашы старэйшыя калегі выкарыстоўваюць тэрміналогію вы не знаёмыя з. Калі вы знайшлі што-то вельмі складана, і, здаецца, не мае сэнсу, або, здаецца карысным, не забівай сябе над ім - проста падаць яго далей у галаву, што ёсць такое паняцце, або падыход.

У свой дзень на развіццё дня, калі вы не навукоўцы, ваша праца складаецца ў тым, каб знайсці працаздольнае, абслугоўвацца рашэнне. Калі ідэі, якія вы знойдзеце ў кнізе, не дапаможа вам дасягнуць гэтай мэты, то не турбуйцеся пра гэта прама цяпер, да таго часу, як ваша праца лічыцца здавальняючым.

Там можа наступіць момант, калі вы выявіце, што вы можаце выкарыстоўваць некаторыя з таго, што вы чыталі, але не зусім «атрымаць» у першы, а можа і няма.

17
дададзена
Вы кажаце, што ў вашым 20-гадовы досвед працы, ніколі не мае такое ж рашэнне, прадстаўленае на сябе частку праблемы? Вы заўсёды ствараецца зусім новае рашэнне кожны раз, калі вы два класы, якія ўзаемадзейнічаюць адзін з адным? Даволі добра кожны выкарыстоўвае мадэлі зноў і зноў, кніга толькі там, таму мы называем іх такім жа чынам, калі мы гаворым пра іх.
дададзена аўтар Rob Hunter, крыніца
У той час як на чыстым узроўні гэта правільна, гэта гучыць як DDD і іншыя шаблоны проста тэорыя. Яны не з'яўляюцца. Яны з'яўляюцца важнымі інструментамі для дасягнення чытанага і падтрымоўванага кода.
дададзена аўтар Moogie, крыніца
@vikingsteve OP не з'яўляецца гуру праграмавання, каментуючы па агульным празмернаму шаблонаў праектавання. OP з'яўляецца вучнем і <�я> лічыць яны злоўжываюць <�я> ў яго краме </я>. Я ведаю, што для пачаткоўца я б думаў гэтак жа пра код я пішу ў цяперашні час, але пачатковец мяне было шмат асабістых праектаў церпяць няўдачу, таму што яны ў канчатковым выніку занадта заблытаным.
дададзена аўтар R. Schmitz, крыніца
@Vector Я трохі збіты з панталыку, наколькі добрыя гэтыя праўкі былі. Гэта працягвалася з «здаецца самаўпэўненым» да «100% згодзен» для мяне, безумоўна, +1!
дададзена аўтар R. Schmitz, крыніца
@Luaan Калі вы ўжо клапаціліся аб добра прадуманыя, арганізаваны, структураваныя, ООП, я б наўрад ці можна назваць гэта пачатковец вас, але ды злоўжывайце дрэнна. Тым не менш, гаворка ідзе пра тое, як OP сапраўды не разумее, якія праблемы гэтыя рэчы вырашаць. Калі вы не ведаеце прычыны, здаецца, няма ніякіх прычын, - але на самой справе, вы проста не ведаеце, што яшчэ.
дададзена аўтар R. Schmitz, крыніца
@JensSchauder - Я рэдагаваў адказ у святле Вашага каментара. Я згодны, што проста назваўшы яго «тэорыю», як правіла, няправільна. «Метадалогія» з'яўляецца значна больш дарэчы.
дададзена аўтар Vector, крыніца
@ R.Schmitz - Я чытаў каментары і зразумеў, што мой мова была не вельмі дакладным і мая пазіцыя гучыць трохі экстрэмальнай.
дададзена аўтар Vector, крыніца
@PeteKirkham ППО дылема з'яўляецца <�я> злоўжывайце патэрнаў праектавання. Вы сапраўды патрэбен AccountServiceFacadeInjectResolver (рэальны прыклад, які я толькі што знайшоў у сістэме на працы) - адказ, хутчэй за ўсё, не.
дададзена аўтар Ian Yates, крыніца
@ R.Schmitz Гэта кажа, пачаткоўцу мяне было шмат асабістых праектаў церпяць няўдачу, таму што яны спрабавалі занадта цяжка зрабіць рэчы добра прадуманыя, арганізаваныя, структураваныя, ААП ... Усе гэтыя інструменты. Яны павінны быць зразуметыя і выкарыстаны належным чынам, і вы наўрад ці можна вінаваціць малаток за тое, што бедны пры зашрубоўвання. Дзіўна, але, здаецца, займае шмат разумення і вопыту, каб зразумець гэтую простую рэч :)
дададзена аўтар Luaan, крыніца
Дзіўная рэч у маім вопыце, я знайсці AccountServiceFacadeInjectResolver рэчы тыпу часцей у кодзе НЕ з дапамогай DDD. Spring-дадатак, здаецца, амаль цалкам класы, якія маюць больш агульнага з запаўненнем ў рамках, чым з праблемнай вобласцю.
дададзена аўтар Rob Crawford, крыніца

Як ваша пытанне ахоплівае шмат зямлі, з вялікай колькасцю здагадак, я вылучыць тэму вашага пытання:

<�Р> Навошта нам так шмат класаў у шаблонах праектавання

Мы не робім. Там не існуе агульнапрынятага правілы, якое кажа, што павінна быць шмат класаў у шаблонах праектавання.

Ёсць два ключавых кіраўніцтва для прыняцця рашэння, дзе паставіць код, і як скараціць свае задачы ў розныя адзінка коды:

  • Згуртаванасць: любы блок коды (няхай гэта будзе пакет, файл, клас або метад) варта належыць разам . Г.зн., любы канкрэтны метад павінен мець адзін <�эм /> задача, і зрабіць гэта адной свідравінай. Любы клас павінен адказваць за адной большай тэмы (што б гэта можа быць). Мы хочам, каб высокае счапленне.
  • <�Літый> Муфта: любыя дзве адзінак коды павінны залежаць толькі адзін ад аднаго, наколькі гэта магчыма - не павiнна быць ніякай асабліва цыклічнай залежнасцю. Мы хочам, каб нізкае счапленне.

Чаму менавіта гэтыя два павінны быць важныя?

  • Згуртаванасць: метад, які робіць шмат рэчаў (напрыклад, старамодны CGI-скрыпт, які робіць графічны інтэрфейс, логіку, доступ да базы дадзеных і г.д. усё ў адзін доўгі беспарадак коды) становіцца грувасткім. На момант напісання, павабна проста пакласці ваш ход думак у доўгі метад. Гэта працуе, лёгка ўявіць і такі, і вы можаце рабіць з ім. Праблема ўзнікае пазней: пасля некалькіх месяцаў, вы можаце забыцца, што вы зрабілі. Радок кода ў верхняй частцы можа быць некалькі экранаў удалечыні ад лініі на дне; лёгка забыцца ўсе дэталі. Любое змяненне ў любым месцы метады можа парушыць любую колькасць паводзін складанай рэчы. Гэта будзе даволі cumbersone рэарганізаваць або паўторна выкарыстоўваць часткі метады. І гэтак далей.
  • Счапленне: у любы час змяніць адзінку коды, вы патэнцыйна разбіць ўсе іншыя падраздзяленні, якія залежаць ад яго. У мер мовах, як Java, вы можаце атрымаць падказкі падчас кампіляцыі (г.зн. аб параметрах, абвясціў выключэнне і гэтак далей). Але многія змены не выклікае такіх (гэта значыць паводніцкія змены), і іншыя, больш дынамічныя, мовы, не маюць такіх магчымасцяў. Чым вышэй счапленне, тым складаней становіцца змяніць што-небудзь, і вы можаце размалоць да прыпынку, дзе цалкам перапісана неабходна для дасягнення нейкай мэты.

Гэтыя два аспекты з'яўляюцца базавымі «драйверамі» для любога выбару «куды падзець тое, што" ў любой мове праграмавання, і любы парадыгмы (не толькі ГА). Не ўсе ведаюць Відавочна з іх, і гэта займае шмат часу, часта гадоў, каб атрымаць сапраўды ўкаранілася, аўтаматычнае адчуванне таго, як гэтыя ўплыву праграмнага забеспячэння.

Відавочна, што гэтыя два паняцці не сказаць вам што-небудзь пра тое, што на самой справе зрабіць . Некаторыя людзі дапускаюць памылку на баку занадта шмат, другія на баку занадта мала. У некаторых мовах (гледзячы на ​​вас тут, Java), як правіла, выступаюць многія класы з-за надзвычай статычны і педантычны характар ​​самой мовы (гэта не значэнне сцвярджэння, але гэта тое, што гэта такое). Гэта становіцца асабліва прыкметна, калі параўнаць яго з дынамічнымі і больш выразных моў, напрыклад Ruby.

Іншы аспект заключаецца ў тым, што некаторыя людзі падпісваюцца на спрытны падыход толькі напісанне кода, які неабходна зараз , і рэарганізаваць моцна пазней, калі гэта неабходна. У гэтым стылі развіцця, вы б не стварыць інтэрфейс калі ў вас ёсць толькі адзін клас, які рэалізуе. Вы б проста рэалізаваць канкрэтны клас. Калі пазней, вам трэба другі клас, вы б рэарганізаваць.

Некаторыя людзі проста не працуюць такім чынам. Яны ствараюць інтэрфейсы (ці, у больш агульным плане, абстрактныя базавыя класы) для ўсяго, што калі-небудзь можна было б выкарыстоўваць у больш агульным плане; гэта прыводзіць да класа выбуху хутка.

Зноў жа, ёсць аргументы за і супраць, і гэта не мае значэння, я ці вы, аддаюць перавагу. Вы, у вашым жыцці, як распрацоўшчык праграмнага забеспячэння, сутыкаюцца ўсе крайнасці, ад доўгіх метадаў спагецці, праз асвечаных, толькі што вялікі досыць канструкцый класа, да неверагодна разадзьмутымі схем класа, якія нашмат overengineered. Як вы больш дасведчанымі, вы будзеце расці ў «архітэктурныя» ролі, і можаце пачаць ўплываць на гэта ў напрамку, куды вы хочаце. Даведаюся залатую сярэдзіну для сябе, і вы яшчэ ўбачыце, што многія людзі не згодныя з вамі, што вы робіце.

Такім чынам, непрадузята самы важны біт, тут, і гэта будзе мой асноўны савет вам, бачачы, што вы, здаецца, шмат болю аб праблеме, мяркуючы па астатняй часткі вашага пытання ...

8
дададзена

Дасведчаныя праграмісты навучыліся:

  • Паколькі гэтыя праграмы нізкаватую і clasess пачынаюць расці, асабліва ўдалыя. Тое, што простыя мадэлі, якія працавалі на простым ўзроўні не маштабуюцца.
  • Паколькі гэта можа здацца цяжкім, каб дадаць/змяніць некалькі артэфактаў для кожнага дадання/змены, але вы ведаеце, што дадаць, і гэта лёгка зрабіць. 3 хвіліны набралі ўдары 3 гадзіны разумным кадавання.
  • Шмат маленькіх класаў не «брудны» толькі таму, што вы не разумееце, чаму накладныя выдаткі на самай справе добрая ідэя
  • Без дадало веданне аб прадметнай вобласці, код «для мяне відавочна» часта таямнічы маіх таварышаў па камандзе ... плюс будучы мне.
  • Племянное веданне можа зрабіць праекты неверагодна цяжка дадаць член каманды лёгка і цяжка для іх, каб хутка быць прадуктыўнымі.
  • найменне адзін з двух жорсткіх праблем вылічальнай тэхнікі па-ранейшаму дакладна і мноства класаў і метадаў, часта інтэнсіўныя практыкаванні ў назве, якое шмат хто лічыць, што вялікую карысць.
7
дададзена
@vikingsteve Вы працягваеце спасылацца на адзін прыклад некарэктнай рэалізацыі ў надзеі, што ён будзе даказваць, што структураваны код, увогуле, гэта дрэнная ідэя. Гэта проста не адсочвае.
дададзена аўтар Warpspace, крыніца
@Clearer Я ўпэўнены, што ўсе тут згодныя, што гіпатэтычны растрата структураванага кода з'яўляецца дрэннай рэччу. OP кажа, што яны Юніёр. Вось чаму людзі мяркуючы, што ён/яна не знаёмы з перавагамі структураванага кода і пацвердзіўшы іх.
дададзена аўтар Warpspace, крыніца
Але накладныя выдаткі неабходна? У многіх выпадках, калі я бачу, шаблоны праектавання перагружаныя. У выніку overcomplexity павялічваюцца цяжкасці ў разуменні, падтрымцы тэставання і адладкі кода. Калі ў вас ёсць 12 класаў і 4 Maven модуляў вакол аднаго простага класа абслугоўвання (рэальны прыклад, які я толькі што бачыў), ён хутка становіцца менш кіраваным, чым вы маглі б падумаць.
дададзена аўтар Ian Yates, крыніца
@MetaFight OP не гаворыць пра структуру кода. Ён кажа пра тое, што ён бачыць, як, занадта шмат абстракцый. Калі ў вас занадта шмат абстракцый, я лічу, вы хутка атрымаць вельмі і вельмі неструктураваны код і шмат амаль аднолькавых частак, проста таму, што людзі не могуць справіцца з колькасцю матэрыялу, які яны павінны мець справу з.
дададзена аўтар Clearer, крыніца

Стварэнне больш класа і функцыі, як за выкарыстанне будзе вялікі падыходам для вырашэння праблем у пэўнай манеры, якая дапаможа ў будучыні для вырашэння любых пытанняў.

Некалькі класаў дапамагаюць вызначыць, як іх асноўную працу і любы клас можна выклікаць у любы час.

Аднак, калі вы шмат класаў і функцый ад іх імя getable яны знаходзяцца ў лёгка выклікаць і кіраваць. Гэта называецца чыстым кодам.

4
дададзена
Выбачайце, але што ты кажаш?
дададзена аўтар Shizam, крыніца
Гэты адказ павінен прадставіць ідэю (а), што гэта, нібыта, каб прадставіць у ясным англійскай. Падобна на тое, што асноўная ідэя адказу заключаецца ў тым, што меншыя класы, кожны з якіх з аднаго цалкам пэўнай функцыянальнасці, гэта добрая ідэя, але жахлівая граматыка робіць яго амаль немагчыма зразумець. Акрамя таго, само па сабе гэта зацвярджэнне не можа быць дастаткова.
дададзена аўтар Stefan Kendall, крыніца
@Deduplicator давайце разгледзім прыклад у Java, калі мы праектуем мы выкарыстоўвалі jframes тэмы і класы для іх атрымання ў спадчыну. Ад толькі аднаго класа, мы не можам мець магчымасць выкарыстоўваць некаторыя працы Java для распрацоўкі, таму мы павінны зрабіць больш класаў
дададзена аўтар David Farrell, крыніца

Адказы да гэтага часу, усе з іх добра, пачаўшы з разумным здагадкай, што тых, хто просіць нешта адсутнічае, што пытацца таксама прызнае. Таксама магчыма, што Аскер ў асноўным правільна, і гэта варта абмеркаваць, як гэтая сітуацыя можа адбыцца.

Вопыт і практыкі з'яўляюцца магутнымі, і калі старшакласнікі атрымалі свой вопыт у буйных і складаных праектах, дзе адзіны спосаб, каб трымаць рэчы пад кантролем з вялікай колькасцю EntityTransformationServiceImpl 's, то яны становяцца хутка і камфортна з дызайнам ўзоры і няўхільнае выкананне DDD. Яны былі б значна менш эфектыўна выкарыстоўваць лёгкі падыход, нават для невялікіх праграм. Як няцотныя аднаго з іх, вы павінны адаптавацца, і гэта будзе вялікім вопытам.

Прыстасоўваючыся, хоць, вы павінны прыняць гэта як урок балансу паміж навучаннем адзінага падыходу глыбока, да кропкі, вы можаце прымусіць яго працаваць у любым месцы, у залежнасці ад знаходжання ўніверсальныя і ведаючы, якія інструменты даступныя не абавязкова быць экспертам з любым з іх. Ёсць перавагі абодвух, і абодва неабходныя ў свеце.

2
дададзена