Неліктен дизайн үлгілерінде бізде көптеген сыныптар қажет?

Мен егде жастағы кішігірім құрылысшымын және олардың ой-саналарын, ойларын түсінуімен күресіп жатырмын.

Мен Домендік дизайн (DDD) оқып жатырмыз және бізге неге керек екенін түсінбеймін көптеген сыныптар жасаңыз. Егер біз бағдарламалық жасақтаманы жобалау әдісін ұстанатын болсақ, біз 20-30 сыныппен аяқталады, ол екі файлға және 3-4 функцияға ауыстырылады. Ия, бұл нашар болуы мүмкін, бірақ бұл әлдеқайда қол жетімді және оқылатын.

Кез-келген уақытта EntityTransformationServiceImpl түрінің қандай түрін көргім келеді, маған көптеген сыныптар, интерфейстер, олардың функционалдық шақырулары, конструкторлар, оларды жасау және т.б.

Қарапайым математика:

  • 60 сызық коды және 10 сынып X 10 (айталық, бізде мұндай логика мүлдем басқаша) = 600 сызықтармен 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+ сынақ тесті бар, ол: «сіз өзіңіздің дизайныңызды өзгертпесіз», дегенмен, не? ОП-лар көбейіп кетуі мүмкін және/немесе кодексі жақсы болуы мүмкін, бірақ шын мәнінде осы мәселені шешу үшін шынайы кодтың 6 жолына 1 класс болса, онда ол артық инженер болып табыла ма :-)
қосылды автор TraumaPony, көзі
Және «бірдей мәселені шеше отырып», әрине, толық шешілуді білдіреді, бұл ОС-ның осы кодтық базаның авторларының не көргенін көре алмаған тағы бір сала. Кодың 600 сызығы ең көп жұмыс уақытының ең көп түрі - бұл шынымен коды жұмыс істейтінін білуге ​​мүмкіндік беретін пайдалы теорияларды сырттай дәлелдейтін шеңберде отырған 100 сынып сияқты емес!
қосылды автор TraumaPony, көзі
@EricLippert: егер 100 сыныптағы код бағдарламалық қамтамасыз етуді пайдаланушысына оңай түсіндірілсе, аңғалдық коды жоқ болса, онда иә, бұл үлкен ұқсастығы. Менің ойымша, қабырғадағы тесік пен шыны терезе арасындағы айырмашылық өте ыңғайлы, өйткені «ақылға қонымды шешім нақты шешім емес, өйткені ол біздің нақты пайдаланушымыздың талаптарын қанағаттандырмайды». Осылайша, егер бұзылған код бір күнде жұмыс істеп тұрса, бірақ нақты пайдаланушыға қызмет көрсететін бағдарламалық жасақтама бумасына біріктіру мүмкін болмаса, онда бұл қосымша сабақтарды жазуға арналған слайд-шумақтық дәлел болар еді.
қосылды автор TraumaPony, көзі
@Jared: сіз 100-ден астам сыныптар монолиттен гөрі тестілеуді жеңілдететіндігіңізден жоғары қойылғансыз. Мен бұл шағымға тек жауап бердім. Кодын өзгертудің қарапайымдылығы - монолиттерге қарсы әртүрлі дәлел :-)
қосылды автор TraumaPony, көзі
OOP - әмбебап үздік құрал емес, мәселен проблемалардың әрқайсысын (бөлігін) шешіп алу, әсіресе мұрагерлікпен қосу арқылы кедейлерге, қажетсіз күрделі жобаларға әкелуі мүмкін. Мәселе мынада, жақсы дизайнмен айналысу уақытты талап етеді және тәжірибелі әзірлеуші, және екеуі де қымбат. Бизнес дәл қазір жұмыс істесе, жиі ұнамсыз дизайнмен жақсы.
қосылды автор Rorick, көзі
Сіз Java-ды жасамасаңыз, жоқ. Барлық сізде Java болған кезде, бәрі сыныпқа ұқсайды.
қосылды автор Krzysztof Klimonda, көзі
Қарапайым сөзбен айтқанда, бұл күрделі және талғампаз кодын жазудың ұзағырақ уақытты талап етеді, сол себепті адамдар тұрақсыз, бірақ өте құрылымдық кодты шешеді.
қосылды автор Mr Rogers, көзі
қосылды автор innaM, көзі
@Polginome: Мен дәл сол пікірді жазуды жоспарладым. Кіші жасақтаушыларға тән тағы бір түсініктеме: «Мен мұндай кодты кейінірек кодсыз кодты қозғайтындай сезінемін». Уақыттың жартысын қабырғаға айналдырсаңыз, жылдамырақ жүгіріп өтудің қажеті жоқ! Баяу тегіс, тегіс.
қосылды автор CodeCharming, көзі
Бұл сұрақ «бізге терезе салу үшін неге көп бөліктер қажет?» Деген сұраққа ұқсайды: «Бұл жамбас пен қылқырлық сымдары бар екі жартысы бар, екі қабатты және үш қабатты шыны тәрізді шыны тәрізді, қабырғаға тесік жасап, терезе жасаушылар неге соншалықты күрделі болса, бәрін жасауға тырысады?
қосылды автор CodeCharming, көзі
Мен пайдаланушы1318496 ретінде жалпы сыныптар туралы бірдей сезімін бастадым. Мүмкін, бұл оның жеке басын артық нәрсеге қарағанда артық.
қосылды автор Graham, көзі
@Graham Language ерекшелігі белгілі бір дәрежеде жеке артықшылық болып табылады, бірақ бұл мәселеге ортогоналды болып табылады. Функционалдық кодты оңай жасау және оңай өзгерту үшін жазуға болады.
қосылды автор R. Schmitz, көзі
@ 9000 Менің ойымша, сіз айтып жатқан нәрсе COP деп аталады деп ойлаймын - «сыныпқа бағдарланған бағдарламалау»? Егер объектілерді шын мәнінде көрсетуге болмайтын сабақтарсыз сабақ қосып жатсаңыз, OOP-ты жасамайсыз ...
қосылды автор R. Schmitz, көзі
Біз оларға шынымен қажет емес ...
қосылды автор Vector, көзі
Қарапайым мәселені шешу үшін EntityTransformationServiceImpl арқылы 20-30 сыныпты қолданатын болар деп ойлайтын жалғыз адаммын? Мен сіздердің кодтарыңыз негізделмейінше дизайн үлгілерінде конструкция үлгілерін тастайтын Java-ге сілтеме жасай аласыз деп ойлаймын ...
қосылды автор Solomonoff's Secret, көзі
Менің ойымша, мұнда жақсы сұрақ бар, бірақ гипербола мен бұзылыстың артына жасырынып жатыр. @ user1318496, мәселеңізді біршама перефраздаудың пайдасы болуы мүмкін.
қосылды автор Warpspace, көзі
@jamesqf Бәлкім, оны діни өзгеріс деп санайсың. Мен оны Religion -> Religion түріндегі функция ретінде көремін.
қосылды автор Chad, көзі
Осы жауаптар мен түсініктемелердің кейбірі бір-бірінен сөйлейді. Менің ойымша, бұл екі түрлі сұрақ туралы ойлауға көмектесуі мүмкін, мысалы: «Неге» қарапайым « жалпы » (тестілеу, ажырату және т.б.) және «Нақ осы Мен соншалықты көп сабақ күтемін? « (шамадан тыс инженерлік, тілге тән шұғыл шешімдер (мысалы, ламбдалар жоқ), ескірген стиль (мысалы, Java-інде ламбдалар бар, жүктерді күзету, техникалық қарыз және т.б.)
қосылды автор Warbo, көзі
Мен сіздің математика кодының желілерін және олардың дәлелділігін өте қызықты деп білемін. Мен сіз пайдаланып жатқан сандардың артындағы ақыл-ойды толықтай жазуды қалаймын.
қосылды автор Euphoric, көзі
«600 сызықты кодты оқу = бір күн». Бұл қате ... Мені сыныпты оқуға кететін уақыт экспоненталық түрде өседі, барлық салалық және салалық бұрмаланулар және т.б. ... 600 жолда мен өзімнің жайлылық аймағымның шетіне шығадым. 1000-ға жеткенде, әдетте сыныпты толығымен түсіну үшін мені бір айдай алады.
қосылды автор ArTs, көзі
F22 Raptor компаниясы IKEA қоймасының арматурасын алып, оларды ұшақ тәрізді қалыпқа құю арқылы салынбаған.
қосылды автор ArTs, көзі
Сіздің доменіңізде бар класстардың түсініктері бар ма? Егер жоқ болса, неге олар бар? Егер олар жасаса, онда олар бизнес құндылығы бар, дұрыс? Сіз домендік концепцияларды білдіретін 20-30 сыныпқа қарсы кодты 600 сызықты жазсаңыз, болашақ икемділік сізді жоғалтады?
қосылды автор Rob Crawford, көзі
OOP көбінесе анти-паттерн болып табылады және таза OOP әрдайым анти-паттерн болып табылады. OOP кодыңыздағы барлық орындарға, әсіресе, тестілеуге қабілетті болады. Дизайн үлгілері OOP-ды артық пайдаланумен шашырап жатқан барлық осы шегелерде қозғалу үшін балға (OOP) пайдаланылады. Егер сізде Provider , Entity немесе Processor атымен сынып бар болса, сіз OOP-ке шамадан тыс кіре аласыз, бірақ сіз көптеген адамдарды таба аласыз олар осы тырнаққа OOP қалай ойлап тапты.
қосылды автор Rich Remer, көзі
Айта кету керек, бұл кодты жазудың нақты тәсілі үлгілермен емес, кодты жазатын адамдармен проблема емес. Көптеген үлгілері бар бай бағдарламалар мен 40 немесе 50 сыныпты жаза аласыз; оңай. Бірақ егер сіз барлық нәрселерге үстемдік берсеңіз ... онда сіз 3 сабақ немесе 4-тен 5 процедуралық функциялармен жасалуы мүмкін нәрсе үшін 20 сабақ аласыз. Маңызды дағды - бұл сынып Құдайдың сыныбына айналмауы үшін үлкен сынға ұшырау керек екенін мойындайды.
қосылды автор marstato, көзі
ОП-ларда қорғаныста, ол сілтеме жасайтын жақсы мысал, қарапайым қосқыштарды 3 немесе 4-тен төмен мәндегі жағдайларды барлық жерде мемлекеттік үлгімен ауыстырады. Мен бұл жағдайды көрдім және нәтиже шын мәнінде кодтың жүз жолына емес, 100-ге тең болуы мүмкін. Техникалық қызмет көрсету де бұзылады.
қосылды автор Sentinel, көзі
Ешкім бірыңғай жауапкершілік қағидатын (егер сіз оны сақтасаңыз, көптеген класстардың өндірілуіне әкелетін болса) және тұтастай СОЛИД қағидаттарын айтпағанына сене алмайсыз.
қосылды автор sizzlecookie, көзі
@ user1318496 - Сізді алаңдатудың қажеті жоқ, пікіріңізді ортақ пайдаланатын көптеген табысты компаниялар бар. Және олар әрдайым жалдады, өйткені кодты сақтау үшін көп әзірлеушілер қажет, ол жылдам жазылған .. :)
қосылды автор Fabio, көзі
Ондаған жылдар бұрын DOS 2.0-ден DOS 3.0-ге дейін жаңартылған дүкенде жұмыс істедім. Бірінші нұсқада барлығы бар бір ғана каталог болған. Соңғысында ішкі қалталар енгізілді. Менің бастығым: «Неге бізде барлық ішкі қалталар қажет? Неліктен бәрін бір қапшыққа салып қоюға болмайды?» - деп сұрады. Жақсы уақыт. :)
қосылды автор David Lang, көзі
Дизайн үлгілері тек күтім жасау туралы ғана емес, сонымен қатар қайта пайдалану туралы.
қосылды автор Randy E, көзі
Бүгілуді басу қаупі бар, себебі сіздің тілің өкінеді. Мұны көп нәрсеге үйретпеңдер: әртүрлі себептерге байланысты қиындықсыз тіл көбінесе дұрыс техникалық таңдау болып табылады, бірақ бұл оның қолайсыздығына әкелмейді. Өзіңіздің нақты сұрағыңызға келетін болсақ, дұрыстылық оқуға қарағанда маңызды. Немесе бұл басқаша түрде айтуға болады: оқуға қабілеттілік дұрыстығын түсіндіруге мүмкіндік береді. Қандай тестілеуді жеңілдетеді, сіздің 100 сыныптарыңыз немесе монолиттік Құдай сыныбы? Мен қарапайым 100 сабақ өткіземін.
қосылды автор Sujan, көзі
@SteveJessop иә, жүйені тестілеу екі жағдайда бірдей күрделі. Мүмкін, тіпті көптеген сыныптардағы жағдай. Айырмашылық мынада: монолиттің көмегімен мұнда өзгертуді оңайырақ етуі мүмкін, оны жасаудан үзілуі мүмкін нәрселерді уақытша шектеу ықтималдығы бар. Бөлу код кодының дұрыс бөлігін табу қиын, бірақ белгілі мөлшерде және өзгерісті өзгерту тривиальды. Мен өзіме зиян келтірместен сенімді болғым келеді, бірақ YMMV және бір өлшем бәріне сай келмейді. 10к сызықтан кем нәрсе үшін мүмкін монолитті жақсы көреді. Мүмкін.
қосылды автор Sujan, көзі
@Theodoros Chatzigiannakis: Бұл тек діни өзгеріс. Мәселе - бағдарламалық қамтамасыз етуді әзірлеу әдіснамасына деген мінсіз ғибадат. Сіз тек Құдайды өзгерте аласыз, бірақ салт-жораларға қатысы жоқтығын сақтаңыз.
қосылды автор Ruks, көзі
@Rob Кроуфорд: «... 600 сызық кодты 20-30 сыныпқа қарсы ...», сізде екі байланысты емес нәрсе бар. 600-нен астам таза, жақсы түсініктеме кодын жазуға болады, себебі оны 20-30 аралығындағы сыныптарға айналдыруға болады.
қосылды автор Ruks, көзі

10 жауаптар

Бұл оңтайландыру мәселесі

Жақсы инженер мақсаттысыз оңтайландыру мәселесі мағынасыз екенін түсінеді. Тек оңтайландыруға болмайды, үшін үшін бір нәрсе оңтайландыру керек. Мысалы, компилятор опцияларына жылдамдықты оңтайландыру және код өлшеміне оңтайландыру кіреді; бұл кейде қарсы мақсаттар.

Әйеліме менің үстелім қосу үшін оңтайландырылғанын айтқым келеді. Бұл жай ғана құмыра және заттар қосу өте оңай. Әйелім оны іздеуге оңтайландырса, яғни менің заттарымды аздап ұйымдастырса, мен бұл нәрсені таба аламын. Бұл, әрине, қосу қиын.

Бағдарламалық жасақтама бірдей. Өнімді жасау үшін, әрине, оңтайландыруға болады - монолиттік код мүмкіндігінше жылдам жасаңыз , оны ұйымдастыру туралы алаңдамай. Сіз байқағандай, бұл өте тез, өте жылдам болуы мүмкін. Баламасы - техникалық қызмет көрсетуді оңтайландыру - оны жасау қиындық тудырады, бірақ өзгерістерді оңай немесе қауіпті ету. Бұл құрылымды кодтың мақсаты.

Бағдарламалық өнімді сәттен бастап бір рет жасайтын болар едім, бірақ бірнеше рет өзгерді деп ойлаймын. Тәжірибелі инженерлер құрылымдық емес кодтық базаларды өздерінің өміріне айналдырып, көлемді және күрделілігімен өсіп келе жатқан өнімге айналады. Егер код құрылымдалған болса, тәуекел болуы мүмкін. Міне, сондықтан да біз осы қиындықтарға барамыз.

Күрделілік қарым-қатынастардан емес, элементтерден келеді

Сіздің талдауыңызда сандарға қарап отырмын: кодының саны, сыныптар саны және т.б. Бұл қызықты нәрселер болғанымен, нақты әсер комбинаторлы түрде жарылып жатқан элементтер арасындағы қатынастардан туындайды. Мысалы, сізде 10 функция бар болса және қандай да болмасын түсініксіз болса, сізде 90 ықтимал қарым-қатынас бар (тәуелділіктер) сіз алаңдатуыңыз керек - он функцияның әрқайсысы тоғыз басқа функциялардың кез келгеніне тәуелді болуы мүмкін және 9 x 10 = 90. Сіз қай айнымалылардың немесе деректердің қалай айналатындығын өзгертетіндігіңізді білмеуіңіз мүмкін, сондықтан кодерлер белгілі бір мәселені шешу кезінде алаңдатуға болатын нәрселерге ие. Керісінше, егер сізде 30 сынып бар, бірақ олар ақылмен ұйымдастырылған болса, олар 29 қатынастармен, мысалы: егер олар қабаттасқан немесе стакаға орналастырылған болса.

Бұл сіздің командаңыздың өткізу қабілетіне қалай әсер етеді? Ал, тәуелділіктер аз, проблема әлдеқайда көп; кодерлер өзгеріс жасаған кезде олардың басындағы зиллион заттарын алып жүрудің қажеті жоқ. Осылайша, тәуелділікті барынша азайту проблема туралы сауатты білу қабілетіңізге үлкен әсер етуі мүмкін. Міне, сондықтан біз мүмкіндігінше тығызырақ сыныптар мен модульдер мен ауқым айнымалыларына бөліп, СОЛИД қағидасы.

323
қосылды
@ jpmc26 Сыныптардың ең аз санын пайдаланатын және тренингке оңай әрі оңай оқылатын OOP бағдарламасының (мысалы,> 10k loc) мысал бола алады? Сондай-ақ, кодты оқудың күрделілігіне келіспеймін. Кодты IDE-ға жүктемей-ақ, RestoreRunner.RunAsync -ден RestoreCommand -ге және т.б. Менің ойымша, бұл NuGets қарапайым тізім емес, бірақ PackageReference деген ағаштан күнделікті күнделікті кілт сөзді өзіңіздің ақыл-ой моделіңізге түсіріп тастаған.
қосылды автор Kyle Hodgson, көзі
@Holger Сонымен, Mozilla Firefox-қа жаңа мүмкіндіктерді бірнеше жыл бойы браузерді толығымен қайта жазуды тоқтатты? Олар емес. Кодтың бөліктерін ауыстыруға болады және табиғи эволюция бар, бірақ толық қайта жазу - улы (IE6 және 8 арасында MS болған басқа компания үшін олар Netscape-ден қарағанда әлдеқайда жақсы жұмыс істемеген)
қосылды автор Kyle Hodgson, көзі
@Holger Сіз бүгінде «тек қана браузерлер, олар да, нөлден бастап қайта жазылған немесе тіпті ұзақ емес» деп айтасыз. Бұл қате жалған. Мен сіздердің нөлден бастап қайта жазылған кез-келген танымал өнімді таба аласыз және бұрынғыдай сәтті болғандығыңызға күмәнім бар (өйткені сіз айтқан мысал дұрыс емес, сіз жақсы білесіздер деп күмәнданамын). Netscape-дан кейін ұқсас нәрсені жасаған браузердің жалғыз сатушысы IE6-дан кейін Microsoft болды. Және олар 90% -дан көпшіліктің кішкентай ойыншысына айналды және браузерді планетаның ең танымал операциялық жүйесімен біріктіргеніне қарамастан ... үлкен жетістік.
қосылды автор Kyle Hodgson, көзі
Нөлден және екінші жүйелік синдромнан қайта жазылу - өнімді өлтірудің сенімді тәсілі, сондықтан оны ешкім әлі айналып жатыр. Сіз жасай отырып, жаңа мүмкіндіктерді қолданғанда қолданыстағы кодты жақсарту. Немесе қажет болған жағдайда, қосымшаның кішкене бөліктерін қайта жазуға шешім қабылдай аласыз (әдетте қауіпсіздік немесе өнімділік, өте сирек жөндеу). Бірақ нөлден қайта жазу керек пе? Джоэлдің мақаласында мұндай жаман идеяның көптеген себептері келтірілген.
қосылды автор Kyle Hodgson, көзі
Дегенмен, кластар мен инжирацияның артық болуы НОР техникалық қызмет көрсетуін түсінуге көмектеспейді. Сондай-ақ, басқарылатын басқару ағындары да жоқ (aka, callback hell).
қосылды автор Owen, көзі
«Баламасы техникалық қызмет көрсетуді оңтайландыру болып табылады - жасауды жеңілдетеді, бірақ өзгерістерді жеңілдетеді немесе азайтады, құрылымды кодтың мақсаты». Мен көбірек сабақтар = неғұрлым оңтайлылық деп түсініксіз ұғыммен айналысамын. Атап айтқанда, көптеген сыныптар бойынша шашыраңқы логика көбінесе кодекстегі тұтас логикалық тұжырымдарды табуды қиындатады (әсіресе түсініктерді қамтамасыз ету үшін өте көзге көрінбейтін көзқарассыз), бұл өте жақсы түрде қалпына келтіріледі.
қосылды автор jmibanez, көзі
Бұл менің мысалға мысал ретінде жақында болды NuGet қалпына келтіру пәрмені . Қалпына келтірудің үш негізгі қадамы бар: пакеттер тізімін оқып, оларды қотарып алып, оларды дискіге шығарыңыз. Бұл қадамдардың әрқайсысы қиындықтарға тап болса да, кодексте орындалатын жерлерді іздестіру өте қиын, ішінара ішінара салыстырмалы түрде көп объектілердің салдарынан және ішінара осы тұжырымдамаларды анықтауға болмайды атау мен ұйымда басымдыққа ие болды.
қосылды автор jmibanez, көзі
@Voo Мен команданың қандай нысанды бастағанын білмеймін; бәрі ОО-ның командалық-сызықты талдау әдісімен мазалайды. RestoreRunner екенін анықтағаннан кейін, егер сіз оқып жатсам, провайдер объектісіне қоңырау шалу арқылы сізді 4 әдісті шақыру арқылы жүргізетін «сұраулар» қалай жасалатынын қадағалауға тырысасыз бұл дұрыс. Ағашты табу - бұл таңқаларлық емес, бірақ оны табу өте көп қабаттар. Мен ақылды емеспін. Маған ұнайтын коды, оның ниеті туралы ойланып ойластырылған, ал объектілі-бағдарлы көзқарас кедей абстракцияларды әлсіретеді.
қосылды автор jmibanez, көзі
@JohnWu NuGet модулярлы болу кезінде өте қиын. Оның жанындағы кітапханалар (мысалы, NuGet.Frameworks ) мүлдем құжатталмаған (мен тіпті өздерінің құрылысын қайнар көзін таба алмадым), пәрмен жолы құралы VS плагинінің функционалдығы көп болмады және кодқа қарап, көптеген нысандарды жасау қажеттілігі бір бөлікке жұмыс істеу үшін кез-келгенін пайдалану үшін барлық код базасын өте кең түсіну керек. Ол қазірдің өзінде тиімді монолитті, сондықтан мен сіздің дәлеліңізді сатып алмаймын.
қосылды автор jmibanez, көзі
@JohnWu Бұл үлгілерге қатысты pervasive көрінісі қоспағанда. ДИ діни түрде қабылданады. Мен білмеймін, ДТ-ның бастамашысы жоқ, «Мәселен, ДИ шешуші мәселе болып табылады», - дейді олар, «Сіз ОО кодын жазуыңыз керек, демек сізде ДИ болуы керек, ал, oh, btw, сіз СОЛИД қағидаттарын ұстануыңыз қажет . « Іс жүзінде ешкім бұл идеялар шынымен қалай шешілетінін білмейді. Олар тек қана барлық уақытта қолданылатын ережелер ретінде ұсынылады.
қосылды автор jmibanez, көзі
@ R.Schmitz Шынымен жақсы бағдарламашылар бірінші кезекте ереже бойынша ойламайды. Олар проблемаларды шешу тұрғысынан ойлайды. Одан да маңыздысы, жақсы бағдарламашылар басқа бағдарламашылар қазірдің өзінде бұл ойлауда ойланбастан, ережелерді белгілеместен емес, оларды оған жақындатуды біледі.
қосылды автор jmibanez, көзі
@ R.Schmitz Мен шынымен де жақсы бағдарламашылар ойлануға тырысады дейді. Олар «кодты оқуға ыңғайлы ету үшін оңтайландыру керек» деп ойламайды. Олар: «Кейінгі уақытты немесе өзге де әзірлеушілерді өзгерту үшін кодты түсіну қабілетінің мәселесін шешу керек», - деп ойлайды. Біріншісі проблеманы түсіндірместен шешім шығарады. Екінші мәселе әртүрлі шешімдерге ашық және ашық болып қалады және сіз табысты болғаныңызда (ол әлі де субъективтілігіне қарамастан) неғұрлым анық болған мақсатқа ие.
қосылды автор jmibanez, көзі
Мен комбинаторлық үшін толық 10 × 10 = 100-ге баратынмын: бұл функцияларды рекурсивтілікке және ерекше нашар кодекске, қажет болған жағдайда, қажет емес.
қосылды автор LessIsMore, көзі
Жақсы жазылған, бірақ, мүмкін, неге «бір рет жасалған, бірақ көбінесе көп рет өзгертілген» жоқ па? (Егер барлық код EntityTransformationServiceImpl ) болса, сіз оны түзетпес бұрын қалай жұмыс істейтінін үйренуге мәжбүр болады, бірақ, мысалы, пішімде және Formatter class мұны өңдейді, бұл тек бұл бөлік қалай жұмыс істейтінін үйрену керек, сондай-ақ, 3 айдан кейін өзіңіздің кодыңызды оқып, бөтеннің кодын оқыған сияқты.) бізді бұл туралы ойластырылған ойлауға болады, бірақ бұл тәжірибеге байланысты болуы мүмкін. Бұл туралы 100% сенімді емес.
қосылды автор R. Schmitz, көзі
@Holger No, өйткені жаңа кодты қосқанда, алдыңғы код сіздің жазу стандарттарыңыз сияқты маңызды емес. Егер бағдарламалық жасақтама кодын қосу үшін қасіретті қылып қоятын болса, онда бұл тек жайсыз код. Сіз өте жақсы модульдік жобаға ие бола аласыз, бірақ кейбір тез және жеңіл кодты қосыңыз. Сіз сондай-ақ бірыңғай құдай сыныбында толық бағдарлама аласыз, бірақ кейінірек сіздің қосылуға қалай жасауға болады туралы кейбір ойлар өткізіңіз. Сіз айтып отырған компаниялар туралы болсам, мен тек біреуі туралы естідім және оны Netscape деп атады .
қосылды автор R. Schmitz, көзі
@Holger Егер компания код негізін қайта жазылмайтын жаңа өнім жасаса, бұл бірінші кезекте жасау . Әйтпесе, бүгінгі күні AutoCAD және 3DSMax және т.б. 1968 UNISURF және Call of Duty: «Modern Warfare 3» - тек «DOOM» -тің қайта жазылуы ғана болып табылады. Сондай-ақ, бұл жағдайдың болмайтынын айтпаймын, тек сол жағдайларда бұл жақсы болмаса, жақсы болар еді.
қосылды автор R. Schmitz, көзі
@Holger Мен айтқанымның, сондай-ақ, қайта жазылғандардың түсіндірмелері дұрыс емес. Call of Duty - бұл емес DOOM-ты қайта жазу. Бұл толығымен басқа әзірлеуші ​​мүлдем басқа өнім. Әрине, кодтың әрбір бөлігі тек қана жазылған бірінші бөлік кодын қайта жазады, бірақ сөз тек практикалық мәнді жоғалтады және сіз, бәлкім, Сұрақ қойыңыз .
қосылды автор R. Schmitz, көзі
@Holger Look, Firefox 2004 жылы шығарылды, яғни 14 жыл; Android-те 2007 жылы 11 жыл. IT-де бұл тек қана емес, бұл ежелгі . Сіздің теорияңызға сәйкес, Firefox «ескірген, патчталған» (бір уақытта), 2006 жылы пайдаланылмайтын шиеленісті немесе 2010 жылдың ішінде Android болуы керек еді. Бұл жай күттірмейтін кодтың тиімділігін жоққа шығару, өйткені олар енді жақсы барлық аспектілерде - қауіпсіздік, қол жетімділік, мүмкіндіктер жиынтығы, сіз оны атаңыз. Ұсталған кодқа қарсы жеке күн тәртібі бар сияқты.
қосылды автор R. Schmitz, көзі
@ jpmc26 Жақсы бағдарламашылар барлық «ережелерді» прагматикалық түрде қолдану керек екенін біледі; Барлық ережелер автоматты түрде «егер сізде шынымен жақсы себеп болса, соңында алыңыз. Егер сіз прагматикалық емес, догматикалық адамдармен жұмыс істесеңіз, бұл кез келген ережесі үшін жаман болады.
қосылды автор R. Schmitz, көзі
@Holger Қайтадан дұрыс емес, сіздің бастапқы мәлімдемеңіз « бағдарламалық жасақтама қасақана қымбатқа түсетін етіп жасалған, сондықтан оны толықтай ескірген, бұзылған шіркеудің өлуі керек екеніне жетуіміз керек. «Мен байланыстырылған мақала сізді қызықтыратын болса, неге қайта жазуыңыздың нашар екеніне қатысты түсінік береді. Сіздің алғашқы мәлімдемеңіз Firefox және Android-ң дұрыс емес екенін дәлелдеді. Бұдан кейін барлығы талқылау болатын, түсініктемелері жоқ, сондықтан, қазір бұл жағдайды тоқтатып көрейік.
қосылды автор R. Schmitz, көзі
@Holger Сіз жазған [A] маңызды болуы мүмкін, себебі [B] себебі [C] . Міне, сіздің «құдіретіңіз» қолданылған. Сіздің теорияңыз [B] себебі [С]. Қолданбайтын екі үлкен мысал тез [B] [С] тудырмайтынын дәлелдейді. Егер сіздің мәселеңіз басқаша болса, онда мен оны жоққа шығарған жоқпын және сіздің үй-жайыңыздың біреуі дұрыс емес екенін көрсетті.
қосылды автор R. Schmitz, көзі
@ jpmc26 Мен «ережелерді» тырнақша белгілеріне қоямын, себебі олар нұсқаулықтар . Ереже «Сен керек» -дан бастай алмайды. Егер сізде « сияқты кодты оқып шығу үшін оңтайландыру керек» немесе « сіз командаңыздың код конвенцияларын орындауыңыз керек» деген негізгі нұсқауларды орындамаса (барлық қосымша «Егер сізде шынымен жақсы себеп болмаса»), олар көп жағдайда » нақты бағдарламашы «дегенді білдіреді.
қосылды автор R. Schmitz, көзі
@ jpmc26 Жеткілікті түрде жеткілікті, бірақ 5-сұраққа жауап беруді сұрағаннан кейін, «сіздермен команда кодексі конвенцияларын ұстануыңыз керек» деген сөздер сіздің мансабыңыз үшін жақсы емес. Кейде түсініктеме қосу үшін түсініксіз.
қосылды автор R. Schmitz, көзі
@ jpmc26 «Мен көп сыныптар = неғұрлым оңтайлылық деген ұғыммен айналысамын». Әрине, «көп» операндалы неге байланысты. Бұл жағдайда ол «50K LOC кодының коды». Мен ОС-ның лауазымының нақты контексінде келісетінімді білмеймін.
қосылды автор John Wu, көзі
Nuget, ең алдымен, керемет мысал болмағандықтан, оның модульділігі сәулетшілердің артықшылығынан гөрі сыртқы талаптарға негізделуі мүмкін, себебі Visual Studio кеңейтімі ішінде PowerShell командирі ретінде жұмыс істейтін кеңейтілетін шеңберлерді басқаруға арналған кеңейтілген құрылым. Енді бұл туралы ойланамын, егер бәрі бірдей жазылған болса, Нугет тіпті болмады ....
қосылды автор John Wu, көзі
@Holger Менің лауазымдағы екі ықтимал оңтайландыру мақсатын талқылаймын. Әрине, сіз басқа мақсаттар үшін оңтайландыруға болады - мысалы. өнімді құруға ыңғайлы болу үшін оңтайландыру сияқты бірдей емес «қайта жазу санын азайту» (бұл оңалту үшін оңтайландыруға ұқсас) немесе «қайта жазудың оңтайлылығын арттыру» үшін (бұрынғы үйлесімділік және теңдестірілген теңдік). Мақсатты белгілемеймін, мұқият дизайны үшін негізді түсіндіру құралы ретінде айырмашылықтарды ерекше атап өткім келеді.
қосылды автор John Wu, көзі
@Taw «конструкциялық үлгілерді барлық тәсілдермен және діни түрде табуға болады.» Бұл дизайнерлік шешім (шығу) сияқты дизайнерлік мақсат емес (есте сақтау). Қажетті нәтижелерді оңтайландыру енгізуіне алдын-ала жүктеу кезінде, процесс көп мәнді қоспайды (бұл эндогенділік тестін сәтсіз аяқтайды), а. Сіздің архитекторыңыз сияқты «Pet NFR » деген сөздер бар, олар әрдайым нашар.
қосылды автор John Wu, көзі
@JohnWu бұл түсініктеме - мен оқып жүрген біреуді түсінудің жақсы әрі оңай болуы.
қосылды автор Les H, көзі
Мен кодты алғаш үйреніп, бір сыныпта бағдарлама жаздым, ол жақсы жұмыс істеді, бірақ қарапайым өзгерісті жасау үшін маған бірнеше күнді түзететін 4-тен 5-ке дейін қателер жібереді. Мен дизайнды зерттей бастадым, барлығы 10-ға жуық сыныпты бөліп алдым, техникалық қызмет көрсету проблемалары жоғалып кетті. Осы рефакордан кейін енгізілген 0 қателермен көптеген өзгерістер жасадым. Менің ойымша, бұл сабақ, неге бұның қажеті екенін түсінудің қиын жолын үйренуі керек.
қосылды автор reggaeguitar, көзі
@Voo, «сыныптардың ең аз саны» анықтамасына байланысты. Бізде мыңдаған сабақтардан тұратын өтінім бар, алайда біз белгілі бір жиі қолданылатын шеңберлерді пайдаланғанымызды білеміз және бізде жиырма рет бізде болатын «үздік тәжірибелер» ...
қосылды автор Holger, көзі
@ Р. Шмитц бұл қызықты мәселе. «Бір рет жасалған, бірақ бірнеше рет өзгертілген, бірнеше рет өзгертілген» маңызды болуы мүмкін, себебі бағдарламалық жасақтама қымбатқа түсетін қиял жасайтын етіп жасақталған, сондықтан оны толығымен ескірген, нашар қаупі бар. Әрбір адам осы үлгіге сай келмейді. Бағдарламалық жасақтаманы шығаратын компаниялар да әрдайым жаңа нұсқасының дамуы, нөлден бастап жазылған, алдыңғы нұсқаны дамытудан алынған барлық сабақтарды, сондай-ақ жаңадан пайда болған технологияларды қамтитын күн.
қосылды автор Holger, көзі
@ R.Schmitz сол уақыттағы барлық браузерлердің бастапқы мозаикаға негізделгенін білдіңіз бе? Internet Explorer браузері әлі күнге дейін бар ма? Сіздің ойыңызша, бүгінгі күнгі браузерлердің қаншасы әлі күнге негізделген? Бүгінгі таңда тек қана браузерлер бар, олар сол уақыттан бері қайта-қайта жазылған немесе біраз уақыттан бері бұрыннан бар болған жоқ. Теориялық әлемде, алғашқы браузер модульдік, кеңейтілген, болашақ жолмен жазылған болар еді, келешектегі барлық өзгерістерге дайын болу. Шындығында емес. Талаптар мен технологиялар өте көп өзгереді.
қосылды автор Holger, көзі
@ R.Schmitz, Doom-ның бастапқы кодын негіздеген және бұл Doom бағдарламасының нашар бағдарламалық жасақтамасының белгісі болып табылатын, егер «Call of Duty: Modern Warfare 3» 't? Немесе сіз ескі бағдарламаны жаңасымен ауыстыратындығымды растайсыз ба, өйткені ескі жаңару шексіз болып саналады ма?
қосылды автор Holger, көзі
@Voo Мен барлық бағдарламалық жасақтама әзірлеушілерінің қайда екенін айтқанымды көрмеймін. Мүмкін, сіз дұрыссыз және Firefox өз өмірін Netscape үшін қайта-сызудан бастап-сызат ретінде бастағаннан кейін қайта жаңартқан емес. Мүмкін бұл Firefox-тің қаншалықты жақсы жобаланғандығының белгісі. Немесе Firefox-тың сапасы шынымен даулы болып көрінетіндіктен, сіз фламеварды бастағаныңыз жөн. Құрттардың бұл түрін ашпаңыз.
қосылды автор Holger, көзі
@ R.Schmitz, сіз бұл мәселені толығымен жоғалтасыз деп ойлаймын. Жаңа бағдарламалық жасақтама ескі немесе жаңа өнімнің «қайта жазуы» болып табылатыны маңызды емес. Мәселе мынада, бұл new бағдарламалық жасақтама, оның ескі нұсқасы қаншалықты оңай болғаны маңызды емес. Қазір оны аласың ба? Ескі бағдарлама өледі. Ескі бағдарламалық жасақтама жаңадан ауыстырылады. Бұл міндетті емес факт. Сіз жаңа ғана сіздің немесе сіздің бәсекелестеріңіздің болуына әсер ете аласыз. Бірақ сіз бағдарламалық жасақтаманы техникалық қызмет көрсету үшін оңтайландырып, жаңа бағдарламалық жасақтаманың қымбат тұратындығын жасап, жаңадан жазуды болдырмауға тырысасыз ...
қосылды автор Holger, көзі
@Voo нақты, Microsoft өзінің браузерлерін нөлден қайта жазды. Енді, бүгінгі таңда бұрыннан бар (негізгі қайта жазу жоқ, басқаша айтқанда, әлі күнге дейін Мозаиканың коды негізінде) бар Microsoft корпорациясынан басқа кез келген браузері. Шын мәнінде, Netscape-де қайта жазылған, бірақ оны Mozilla негізіне аударды, ол Firefox-тың дамуына әкелді. Сондықтан өнімнің «өлтірілгенін» қайта жазыңыз, себебі ол жаңадан туды. Бүгінгі күні ескі кодқа негізделген Netscape браузері әлі де бар ма? Mozilla келіспеді.
қосылды автор Holger, көзі
@JohnWu әртүрлі мақсаттардың функциясын оңтайландыруды сипаттайтын әдісіңіз өте жақсы, мен бұған қарсы емеспін. Бұл өте жақсы жауап.
қосылды автор Holger, көзі
@ R.Schmitz, Firefox бас демеушісі Firefox-ға емес, Chrome атты өзінің браузерін жазуға шешім қабылдағаннан басқа, сіз дұрыссыз. Firefox - ежелгі. Дегенмен, дәлелдеуді қалайсыз? Менің алғашқы мәлімдеме, бүгінгі таңда ешқандай браузер Mosaic-ға негізделмеген, өйткені барлық бар браузерлердің барлығы осы уақыттан бері қайта жазылған немесе одан әлдеқайда кішкентай. Мозаиканың 1993 жылдан бері болғанын ескерсек, Firexfox әлдеқайда кіші. Сондықтан сіз мені дұрыс деп тапқан жоқсыз. Бұдан басқа, мен қолдау көрсетілетін кодқа қарсы емеспін, ешқашан айтқан жоқпын. Керісінше, өсіп келе жатқан білетін кодқа қарсы боламын.
қосылды автор Holger, көзі
@ R.Schmitz сіз мәтінді контекстен бұл фразаны өшіріп жатырсыз. Ұсыныс « 'бір рет жасалған, бірақ көп өзгерді, бірнеше рет' мүмкін болуы мүмкін, себебі бағдарламалық жасақтама қымбатқа түседі ...». Бұл мүмкін бағдарламалық жасақтама жобаларының кейбір саны қолданылатын үлгі туралы болжам. Сіз шиелендірілген бағдарламалық жасақтама туралы талқылауды ашып, бұрыннан бері екі рет мысалға келтірдіңіз, ол өте ұзақ уақытқа сақталды, бұл жасады өлген барлық бағдарламалық жасақтамаға елеусіз қалды. Бұл алыпсатарлық мәлімдеме тек екі мысал арқылы «дәлелденбеген» емес.
қосылды автор Holger, көзі
Үлкен жауап, бірақ ..: баламасы техникалық қызмет көрсету үшін оңтайландыру болып табылады дегеніміз, бұл жалғыз және бір ОС шағымданады. Сондай-ақ, дизайн үлгілерін діни түрде барлық әдістермен табу үшін оңтайландыру бар. Кілт сөз - бұл smart және көптеген сыныптар жасау арқылы бұл берілген емес. ДИ - керемет/түршігерлік мысал, онда бір дана адам жазғандай, сіз $ 100 сөздік сөз үшін 50с тұжырымдамасын аласыз.
қосылды автор pong, көзі
Жақсы жауап, бірақ өте қызықты: «600-х жолсыз кодты» дұрыс сынақтан өткізу мүмкін емес, ал бұл ОС-да айтылған тәсіл үшін келісім-шартты бұзушы болып табылады.
қосылды автор Nath, көзі

Ең алдымен, оқуға қабілеттілік пен еңбекқорлық жиі мінездің көзінде болады.

Сізге оқуға болатын нәрсе сіздің жақыныңызға болмауы мүмкін.

Қарапайымдылық көбінесе ашықтыққа (кодекс базасында табылған мінез-құлық немесе тұжырымдаманың қаншалықты оңай болуы мүмкін) және басқа да субъективті нәрсе болып табылады.

DDD

DDD әзірлеуші ​​топтарына сіздің код түсініктеріңізді және мінез-құлықтарды ұйымдастырудың нақты (әлі де субъективті) әдісін ұсыну арқылы көмектесетін тәсілдердің бірі. Бұл конвенциясы нәрселерді табуды жеңілдетеді, сондықтан оны қолдануды жеңілдетеді.

  • Домен ұғымдары Ұйымдар және жиынтықтар ретінде кодталған
  • Домендік әрекеттер Entities немесе Domain Services қызметінде болады
  • Тиімділік жиынтық түбірлермен қамтамасыз етіледі
  • Төзімділік мәселелері Репозиторийлермен өңделеді

Бұл келісім объективті емес, оңай қолдау көрсетпейді. Дегенмен, барлық адамдар 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, көзі
Сондай-ақ, бағдарламалық жасақтама контекстіндегі «талғампаздық» жиі Weasel Word сөзі болып табылады. en.wikipedia.org/wiki/Weasel_word
қосылды автор Warpspace, көзі
Кодты ұйымдастыруға қатысты кез келген тәсіл туралы да айтуға болады. Бәрі кодты қалай ұйымдастырылғандығын түсіну үшін қызмет көрсету тобына қосылады. Жақсы және анықталған конвенцияларды қолданудың бұл жолы бар.
қосылды автор Warpspace, көзі
@ jpmc26 Мен келісемін, сабақтар сиқыр емес. Алайда, олар инкапсуляция және мемлекеттік келісім-шарттар сияқты заттарға жиі тілдік деңгейде қолдау көрсетеді.
қосылды автор Warpspace, көзі
@ icc97 Сіз тәжірибе, контекст және конвенциялар туралы білімдер туралы айтар болсақ, бұл үлкен айырмашылықты тудырады. Және бұл кіші жасөспірімдердің осы нәрселердің жетіспеуі мүмкін, олар үшін бұл туралы естеліктер жазылған кодты жасау қиын.
қосылды автор Warpspace, көзі
Overengineering функциясы емес әлдеқайда оңтайландырылған немесе түсінікті кодты береді - керісінше, сіз талап ететініне қарамастан. Мәселені неғұрлым талғампаз түрде шеше алатын болсаңыз, кімге қажет AddressServiceRepositoryProxyInjectorResolver ? Дизайн үлгілері үшін дизайнерлік модельдер қажетсіз күрделіліктікке әкеледі.
қосылды автор Ian Yates, көзі
Үлкен жауап! Сізбен келіспейтін ескертулерде таңқалдым
қосылды автор reggaeguitar, көзі
Егер олар бірінші сыныптарға бөлінсе және бұл сыныптарды қабаттарға біріктіретін содан кейін болса, онда ештеңе ештеңе істемейді. Сіз мұны басқа тәсілмен орындағыңыз келеді (сонымен бірге сабақтарды бастау үшін).
қосылды автор Clearer, көзі
содан кейін бүкіл үлгісін бұзу үшін тек бір маймыл кілтін ғана алады
қосылды автор user2890248, көзі

Пожалуйста, мені түсіндіріп беріңізші, неге біз осы DDD стиліне, көп үлгілерге қажет?

Біріншіден, ескертпе: DDD-дің маңызды бөлігі үлгілері емес, сонымен бірге бизнестің даму күштерін теңестіру. Грег Янг көк кітабының басшыларының дұрыс емес тапсырысына ие екенін атап өтті.

Бірақ сіздің нақты сұрағыңыз: сіз күткеннен гөрі әлдеқайда көп сыныптар болуы мүмкін: (а) домендік мінез-құлықты сантехникамен ажырату үшін күш жұмсалады, және (b) концепцияларды қамтамасыз ету үшін қосымша күш-жігер жұмсалады домен үлгісінде айқын көрінеді.

Егер доменде екі түрлі ұғым бар болса, онда олар үлгісінде әр түрлі болуы керек, тіпті олар жадыдағы көріністі бөліседі. .

Іс жүзінде, сіз домен сарапшысы оны қарап шығып, қателерді анықтап алу үшін бизнесіңіздің тілінде сіздің модельіңізді сипаттайтын доменнің нақты тілін жасайсыз.

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.

Мұнда мотивация: бизнестің негізгі құзыреттілігінің бөлігі болып табылатын (бәсекелестік артықшылығын тудыратын орынды білдіретін) бағдарлама үшін сіз домендік мінез-құлқын оңай және арзан алмастыра аласыз. Іс жүзінде сіз жылдам дамитын бағдарламаның бөліктері (уақыттың қалай дамитындығы) және сіз өзгерткіңіз келетін басқа бөліктер (мемлекет қалай сақталады); абстракцияның қосымша қабаттары бір-біріне қате араласуға жол бермейді.

Адалдықта: оның кейбіреулері де нысанға бағытталған мидың зақымдануы болып табылады. Бастапқыда Эванс ұсынған модельдер 15+ жыл бұрын қатысқан Java жобаларына негізделген; күйі мен мінез-құлқы осы стильде тығыз байланысты, бұл сізден аулақ болуды қалайтын асқынуларға әкеледі; Стюарт Хэллоуэйдің Қабылдау және әрекет бөлімін қараңыз немесе John Carmack-тің «http://number-none.com/blow/john_carmack_on_inlined_code.html» rel = «noreferrer»> кірістіру кодын .

Қандай тілде жұмыс істесеңіз де, функционалдық стильде бағдарламалау артықшылықтар береді. Сіз бұл ыңғайлы болған кезде оны жасауыңыз керек және бұл шешім ыңғайлы болған кезде қатты шешім қабылдау керек. Кармак, 2012

29
қосылды
Бұл жерде ең жақсы жауап деп ойлаймын. Мен DDD-де сатылмайтын кезімде, бұл жауап, ең болмағанда, ештеңе білдірмейтін ортақ пікірге жүгінудің орнына, ол шын мәнінде не болып жатқанын және оның нақты мотивациясын түсіндіреді.
қосылды автор jmibanez, көзі
Джон Кармакс - IMO тамаша үлгісі, өйткені ол жақсы және жақсы түсіну үшін, сондай-ақ таза және оңай түсінуге болатын кодты жазу үшін танымал. Бұл, әсіресе, процессорлар мен жадыларды жақсарта отырып, оның кодын бақылаған кезде әсіресе көрінеді, бұл «шын мәнінде шынайы болуы керек» дегенден көптеген нәрселерді көре аласыз, бұл «шынымен таза/оқшауланған болуы керек» ... «. Мен білетін ең прагматикалық бағдарламашылардың бірі :)
қосылды автор Luaan, көзі
Мен оқып шыққанға дейін өзіме жауап бергім келді. Бірінші параграфты баса назар аударатын болар едім, оның мақсаты бағдарламалық жасақтаманың бизнестің талаптарына сәйкес келуі үшін бағдарламалық жасақтаманың бизнес тұжырымдамасын модельдеу. Әділеттілікке қарай, жобаны басқаратын талдаушы, сонымен қатар, жеткізушіге жеткізілу уақытының қаншасы екенін білдіруі керек және код/​​сынақ сапасы немесе толықтығы тиісінше түзетілуі керек.
қосылды автор Sentinel, көзі

Басқа жауаптарда көптеген жақсы жақтар бар, бірақ менің ойымша, олар маңызды тұжырымдамалық қателіктерді жіберіп алмайды немесе айқындамайды:

Сіз толық бағдарламаны түсіну әрекетін салыстырып жатырсыз.

Бұл бағдарламалардың көпшілігінде шынайы міндет емес. Тіпті қарапайым бағдарламалар тіпті көп кодтан тұрады, бұл кез келген уақытта басын басқаруға болмайды. Сіздің жалғыз мүмкіншілігіңіз - тапсырманы орындауға қатысты бағдарламаның бөлігін табу (қатені түзету, жаңа мүмкіндікті енгізу) және онымен жұмыс істеу.

Егер сіздің бағдарламаңызда үлкен функциялар/әдістер/сыныптар бар болса, бұл мүмкін емес. Сізге кодының бұл бөлігі мәселеңізге қатысты екенін анықтау үшін жүздеген жол кодтарын түсіну керек. Сіз берген бағалаулармен жұмыс істеуіңіз қажет код бөлігін табу үшін бір апта жұмсауға болады.

Оны кішігірім функция/әдістермен/сыныптармен салыстырып, пакеттерге/аттар кеңістігіне айналдырылған кодтық базаға салыстыру, бұл логиканың қай бөлігін табу/қою керек екенін анық көрсетеді. Көптеген жағдайларда дұрыс орындаған кезде мәселені шешу үшін дұрыс орынға секіріп өтуге болады немесе, кем дегенде, сіздің отладчикыңызды ататын орын, сізді бірнеше пышақтағы оң жаққа әкеледі.

Жүйенің екі түрінде де жұмыс істедім. Салыстырмалы тапсырмалар мен салыстырмалы жүйе өлшемі үшін өнімділіктегі екі шамалы айырмашылық оңай болуы мүмкін.

Бұл басқа әрекеттерге әсер етеді:

  • тестілеу кішірек бірліктермен оңайырақ болады
  • қақтығыстардың бірігуін азайтады, себебі екі әзірлеушілерге бірдей код бөлігінде жұмыс істеу мүмкіндігі аз болады.
  • қайталануды азайту, себебі бөліктерді қайта пайдалану оңай (және бірінші кезекте бөліктерді табу).
26
қосылды

Сынақ коды жазу кодынан қиын болғандықтан

Көптеген жауаптар әзірлеуші ​​тұрғысынан жақсы негіздеме берді - ең алдымен, кодты кодтау үшін шығынды азайтуға болады.

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

Егер сіз монолитте бәрін жазсаңыз, онда сіз тек қана жазуға болатын тиімді нәтиже болып табылады: «бұл кірістер берілген, шығыс дұрыс па?». Бұл табылған кез келген қателерді, «бұл жерде үлкен кофе қаптамасында» кеңейтілген дегенді білдіреді.

Әрине, сіз әзірлеушіні қате туралы хабарлау құралымен бірге отыра аласыз және мәселенің қай жерде басталатындығын және түзетуге әрекет жасай аласыз. Бұл көптеген ресурстарды талап етеді және әзірлеуші ​​уақытының нашар пайдаланылуы. Өзіңіздің кішігірім қателіктеріңізді елестетіп көріңіз, әзірлеушіге бүкіл бағдарламаны қайтадан түзету қажет.

Шешім: әрқайсысы нақты, әлеуетті сәтсіздікті анықтайтын көптеген шағын сынақтар.

Бұл шағын сынақтар (мысалы, Unit Tests) кодбазаның белгілі бір аумағын тексерудің артықшылығына ие және шектеулі көлемде қателерді табуға көмектеседі. Бұл тестілеу сәтсіз аяқталғанда ғана отладтау жылдамдығын арттырып қана қоймай, барлық шағын сынақтарыңыз сәтсіз болса, үлкен сынақтарыңызда сәтсіздікті оңай табуға болады (яғни ол нақты сыналған функцияда болмаса, ол өзара әрекеттесу керек олардың арасында).

Тұтастай алғанда, тестілеуді азайту үшін кодының кішірек сыналған бөліктерге бөлінуі қажет екенін білдіреді. Үлкен коммерциялық кодтық кеңістікте мұны істеу тәсілі көбінесе сіз жұмыс істеп жатқандай көрінеді.

Бүйірлік ескерту ретінде: Бұл адамдар «тым алыс» нәрселерді қабылдамайтынын айтпайды. Бірақ кодбазаларды кіші/аз қосылатын бөліктерге бөлуге заңды негіз бар - егер мұқият жасалса.

19
қосылды
Сіздің жауабыңыз тек тестілеу мен тестілеуді қарастырса да, басқа біреудің жауаптары мүлдем елеусіз қалған бір маңызды мәселе +1.
қосылды автор Nath, көзі

Пожалуйста, мені түсіндіріп беріңізші, неге біз осы DDD стиліне, көп үлгілерге қажет?

Көптеген (көбі ...) бізден мұқтаж емес . Теориялықтар мен өте озық, тәжірибелі бағдарламашылар көптеген зерттеулер мен терең тәжірибелердің нәтижесі ретінде теориялар мен әдістер туралы кітаптар жазады, бұл олар жазғандарының әрқайсысы күнделікті тәжірибеде қолданылатындығын білдірмейді.

Кішкентай әзірлеуші ​​ретінде сіз өзіңіздің перспективаларыңызды кеңейтіп, белгілі бір мәселелер туралы хабардар етіп отыратын кітаптарды оқып шығыңыз. Сондай-ақ, сіздің аға әріптестеріңіз сіз таныс емес терминологияны қолданғанда, сізді уайымдаудан және құтқарудан құтқарады. Егер сіз өте қиын нәрсе тапсаңыз және мағынасы жоқ болса немесе пайдалы болып көрінбесе, өзіңізді өлтірмеңіз - жай ғана бұл туралы тұжырымдама немесе көзқарастың бар екеніне көз жеткізіңіз.

Күнделікті дамуыңызда, академиялық болмасаңыз, сіздің жұмысыңыз жұмыс істейтін, қол жетімді шешімдерді табу болып табылады. Егер кітабыңызда табылған идеялар сіз осы мақсатқа жетуге көмектеспесе, онда сіздің жұмысыңыз қанағаттанарлық деп есептесеңіз, қазір бұл туралы алаңдамаңыз.

Сіз оқыған нәрселердің кейбірін пайдалана алатыныңызды білесіз, бірақ алдымен «алдыға» келмейтінін немесе мүмкін болмайтынын білетін уақыт келуі мүмкін.

17
қосылды
Сіз өзіңіздің 20 жылдық тәжірибеңізде ешқашан бірдей шешімді проблеманың бір бөлігіне айналдырған жоқсыз ба? Сіз әрқашанда екі сыныпты бір-бірімен әрекеттескен кезде жаңа шешім шығардыңыз ба? Әрқайсысымыздың әдет-ғұрыптарымызды қайта-қайта пайдаланатын болсақ, онда кітаптар ғана бар, сондықтан олар туралы әңгімелескенде біз де солай атаймыз.
қосылды автор Rob Hunter, көзі
Таза деңгейде бұл дұрыс, бұл DDD сияқты көрінеді және басқа үлгілер тек теория болып табылады. Олар жоқ. Олар оқылатын және қол жетімді кодты жетудің маңызды құралдары болып табылады.
қосылды автор Moogie, көзі
@vikingsteve OP - дизайнерлік үлгілердің жалпылама қолданысы туралы түсініктеме беру бағдарламалаушы емес. OP - оқушы және ойлайды олар өз дүкенінде қолданылған . Бастаушы мен бүгінгі күнде жазған код туралы ойланғанын білемін, бірақ бастаушы менде көптеген жеке жобалар сәтсіз болды, себебі олар өте төзімді болды.
қосылды автор R. Schmitz, көзі
@Vector Мен бұл түзетулер қаншалықты жақсы болғанына таңданамын. Бұл «100% келісемін» деп айтқанымнан «дәлелденген», анық, +1!
қосылды автор R. Schmitz, көзі
@Luaan Егер сіз қазірдің өзінде жақсы ойластырылған, ұйымдастырылған, құрылымдалған, ООП-ға қамқорлық көрсеткен болсаңыз, мен сізді осы бастаушы деп атайтын болар едім, бірақ өте жаман нәрсе. Дегенмен, мәселе осы мәселелердің қандай мәселелерді шешетінін ОЖ түсінбейді. Егер сіз себептерін білмесеңіз, онда ешқандай себеп жоқ сияқты, бірақ шын мәнінде сіз әлі білмейсіз.
қосылды автор R. Schmitz, көзі
@JensSchauder - Мен сіздің пікіріңізді ескере отырып, жауапты редакцияладым. Мен оны «теория» деп атайтын болсақ, әдетте дұрыс емес. «Әдістеме» әлдеқайда орынды.
қосылды автор Vector, көзі
@ Р.Шмитц - Мен түсініктемелерді оқыдым және менің тілімнің нақты емес екендігін түсіндім және менің ұстанымым біршама шекті.
қосылды автор Vector, көзі
@PeteKirkham ОП дилеммасы дизайн үлгілерінің асыра пайдалану болып табылады. Сізге шынымен AccountServiceFacadeInjectResolver керек (нақты жұмыс істейтін жүйеде нақты жұмыс істеп тұрған мысал) - жауап, бәлкім, жоқ.
қосылды автор Ian Yates, көзі
@ Р.Шмитц Бұл айтқанымдай, бастамашылардың жеке жобалары сәтсіз болды, себебі олар жақсы ойластырылған, ұйымдастырылған, құрылымдалған, OOP ... үшін бәрібір тырысады. Оларды дұрыс түсіну және дұрыс қолдану керек, ал сіз балғамен жұмыс істемей тұрғандықтан, оны бұрмалайтын боласыз. Бір қызығы, бұл қарапайым нәрсені түсіну үшін көп түсінік пен тәжірибе алу керек сияқты :)
қосылды автор Luaan, көзі
Менің тәжірибемдегі қызық нәрсе - мен AccountServiceFacadeInjectResolver деп DDD-ны пайдаланбаған кодта жиі кездесетін нәрселерді табамын. Көктемге негізделген қосымшалар проблемалық доменге қарағанда шеңберлерді толтырумен айналысатын іс жүзінде толығымен сыныптар болып көрінеді.
қосылды автор Rob Crawford, көзі

Сіздің сұрағыңыз көптеген жерді қамтитындықтан, көптеген болжамдармен сіз өзіңіздің сұрағыңыздың тақырыбын бөліп аламын:

Неліктен біз дизайнерлік үлгілерде көптеген сыныптарға қажет?

Біз жоқпыз. Дизайн үлгілерінде көптеген сыныптар болуы керек деп айтылған жалпы қабылданған ереже жоқ.

Кодты қайда қою керектігін шешу үшін және тапсырмаларды әртүрлі код бірліктеріне қалай қысқартуға арналған екі негізгі нұсқаулық бар:

  • Біріктіру: кез-келген код бірлігі (пакет, файл, сынып немесе әдіс болсын) бірге тиесілі болуы керек . Иә, кез-келген нақты әдіс бір тапсырмасына ие болуы керек және бұл бір жақсы. Кез келген класс үлкен бір тақырыбына жауап беруі керек (бәрі де болуы мүмкін). Біз жоғары бірігуді қалаймыз.
  • Біріктіру: кодының кез келген екі бірлігі мүмкіндігінше бір-біріне байланысты болмауы керек - әсіресе айналмалы тәуелділіктер болмауы керек. Біз төмен байланғанды ​​қалаймыз.

Неге бұл екі маңызды болуы керек?

    Бірлескен: көп нәрсені жасайтын әдіс (мысалы, GUI, логика, ДБ қатынасы және т.б.). Жазу кезінде ойыңызды өзіңіздің ұзын әдісіңізге қоюға тырысыңыз. Бұл жұмыс істейді, ол оңай және сол сияқты, және сіз онымен жасай аласыз. Кейінірек ақаулар пайда болады: бірнеше айдан кейін сіз өзіңіздің жұмысыңызды ұмытып кетуіңіз мүмкін. Жоғарғы жағындағы код сызығы төменгі жағындағы сызықтан бірнеше экран болуы мүмкін; барлық мәліметтерді ұмыту оңай. Кез келген өзгеріс әдіс кез келген жерде күрделі нәрсенің кез-келген әрекетін бұзуы мүмкін. Әдістің бөліктерін рефакторға немесе қайта пайдалануға болады. Және де.
  • Біріктіру: кодының бірлігін өзгерткен кез келген уақытта сіз оған тәуелді барлық басқа бөліктерді бұза аласыз. Java сияқты қатал тілдерде компиляция уақытында (яғни параметрлер туралы, жарияланған ерекшелік туралы және т.б.) кеңестер алуға болады. Бірақ көптеген өзгертулер осындай мінез-құлықты (мысалы, мінез-құлықтың өзгеруі) және басқа, неғұрлым серпінді тілдерде мұндай мүмкіндіктерді жоққа шығармайды. Магнитудасы неғұрлым жоғары болса, соғұрлым ол ештеңені өзгерте алмайды, және сіз қандай да бір мақсатқа қол жеткізу үшін толық қайта жазу қажет болғанда тоқтата аласыз.

Бұл екі аспект - кез келген бағдарламалау тілінде «қайда қою керек», кез келген парадигма (OO ғана емес) таңдау үшін «драйверлер» базасы. Әрқайсысы оларды түсінбейді және бұл бағдарламаға қалай әсер ететіндігі туралы шын мәнінде ойдағыдай, автоматты түрде сезіну үшін, көп уақыт қажет.

Әлбетте, бұл екі тұжырым шынымен істеу туралы ештеңе айтпайды. Кейбір адамдар тым көп жағында қателеседі, басқалары тым аз. Кейбір тілдер (сізді осында қарап, Java) көптеген тілдерді үйренеді, өйткені ол өте статикалық және педагогикалық сипаттағы тілдің өзі (бұл құн туралы мәлімдеме болып табылмайды, бірақ ол солай). Бұл әсіресе динамикалық және көп мәнерлі тілдермен, мысалы, Ruby-мен салыстырғанда, байқалады.

Тағы бір аспект - кейбір адамдар тек қана дәл қазір жазу кодының икемді тәсіліне жазылса және қажет болса, кейінірек рефакторды қажет етеді. Дамудың осы стилінде сізде тек бір бағдарлама класы болған кезде interface құруға болмайды. Сіз жай ғана нақты сыныпты енгізесіз. Егер кейінірек сізге екінші сынып қажет болса, онда сіз рефрактор едік.

Кейбір адамдар жай ғана осылай істемейді. Олар жалпыға ортақ пайдаланылатын барлық нәрселер үшін интерфейстерді (немесе, негізінен, дерексіз негіздік сыныптарды) жасайды; бұл сыныпты тез жарылысқа алып келеді.

Тағы да, қарсы және дәлелдер бар, және мен не, сіз қалайсыз, маңызды емес. Бағдарламалық жасақтаманың әзірлеушісі ретінде сіздің өміріңізде ұзын спагетти әдістерінен барлық жарықтылықты, ағартылған, әдемі, жеткілікті дәрежеде сыныптық конструкциялармен, керемет шығарылған керемет сыныптық схемаларға дейін кездесетін боласыз. Егер сіз тәжірибе жинақтаған болсаңыз, онда сіз «сәулет» рөлдеріне көбірек қарай түсетін боласыз және сіз өзіңіз қалаған бағытқа әсер ете аласыз. Сіз өзіңіздің алтын ортаңызды таба аласыз, сонда сіз көптеген адамдар сізбен келіспейтінін таба аласыз.

Сондықтан ашық ойды сақтау - ең маңызды бит, осында, және бұл менің басты кеңесім болар еді, өйткені сіздің мәселеңіздің қалған мәселелеріне қарағанда сізде ауырған сияқты көрінеді ...

8
қосылды

Тәжірибелі кодшылар білді:

  • Осы шағын бағдарламалар мен кластерлердің өсуі, әсіресе табысты болғандықтан. Қарапайым деңгейде жұмыс істеген қарапайым үлгілер ауқымды емес.
  • Әрбір қосу/өзгерту үшін бірнеше артефактілерді қосу/ауыстыру қажет болуы мүмкін, бірақ сіз не қосу керектігін білесіз және мұны оңай. 3 минуттық теру 3 сағат ақылды кодтауды басады.
  • Көптеген шағын сыныптар «неғұрлым лас» емес, өйткені сіз түсінесіз, неге үстеме ақиқат жақсы идея болса
  • Домен туралы білмейінше, «маған анық» коды жиі менің командамызға құпия болып табылады ... ал мен болашақта.
  • Таиланд білімі жобаның мүшелеріне тез әрі жемісті болуға оңай және қиындық тудыратын жобаларды жасауға өте қиын.
  • Атауы - есептеулердегі екі күрделі мәселенің бірі болып табылады және көптеген сыныптар мен әдістер көбінесе олардың көпшілігінің үлкен пайда табу деп аталатын күшті жаттығу болып табылады.
7
қосылды
@vikingsteve Сіз құрылымдық кодтың жалпы нашар идея екендігін дәлелдейтініне сенімдіміз. Бұл жай ғана бақыламайды.
қосылды автор Warpspace, көзі
@Clearer Мен мұнда әркімнің құрылымдық кодтың гипотетикалық дұрыс қолданбауы жаман нәрсе екендігіне сенімдімін. ОР-лар Джуниор екендігін айтады. Сондықтан адамдар құрылымдық кодының артықшылықтары туралы білмейтіндіктерін және оларды қайталайтынын болжайды.
қосылды автор Warpspace, көзі
Бірақ үстеме керек пе? Көптеген жағдайларда, менің ойымша, дизайн үлгілері артық пайдаланылады. Неғұрлым күрделі нәтиже түсіну, сақтау, тестілеу және кодты жөндеу кезінде қиындық тудырады. Сізде 12 сынып пен 4 қарапайым қызмет көрсету класында модульдер бар болса (мен көрген нақты мысал), ол сіз ойлағаннан оңай басқарылмайды.
қосылды автор Ian Yates, көзі
@MetaFight OP құрылымдық код туралы айтпайды. Ол туралы айтады, ол көреді, тым көп абстракция. Егер сізде абстракцияның саны тым көп болса, менің ойымша, сіз өте тез құрылымсыз кодты және дерлік бірдей бөліктерді аласыз.
қосылды автор Clearer, көзі

Әрбір мәселені шешуге көмектесетін белгілі бір мәселені шешу үшін сынып пен функцияны қолдануға сәйкес пайдалануға болады.

Көптеген сыныптар негізгі жұмыс ретінде анықтауға көмектеседі және кез-келген сыныпты кез келген уақытта шақыруға болады.

Дегенмен, егер сіз көптеген сыныптар мен функциялары олардың атына ие болса, олар қоңырау шалуға және басқаруға оңай. Бұл таза код деп аталады.

4
қосылды
Кешіріңіз, бірақ сіз не айтасыз?
қосылды автор Shizam, көзі
Бұл жауап нақты ағылшын тілінде сөйлейтін идеяны (идеяларды) ұсынуы қажет. Жауаптағы басты идея - бұл ұсақ-түйек, олардың әрқайсысы нақты функционалдығы бар, жақсы идея, бірақ өте қорқынышты грамматика түсіну мүмкін емес. Сонымен қатар, бұл бекіту жеткілікті болмауы мүмкін.
қосылды автор Stefan Kendall, көзі
@Deduplicator java-ге мысал келтіріп көрейік, егер біз жобаны біз мұраға алу үшін жіп жиектерін және сыныптарын қолданған болсақ. Бір сыныптан біз дизайны үшін Java-ның кейбір жұмыстарын пайдалана алмаймыз, сондықтан бізге көбірек сабақ қажет
қосылды автор David Farrell, көзі

Осы уақытқа дейін жауаптар, бәрі жақсы, әскери қызметкердің бірдеңе жоқ екендігі туралы ақылға қонымды болжаммен бастады. Сонымен қатар, әскери қызметкер негізінен дұрыс болуы мүмкін және бұл жағдайдың қалай пайда болуы мүмкін екендігін талқылауға тұрарлық.

Тәжірибе мен практика күшті, ал үлкендер күрделі жобаларда тәжірибе жинаған жағдайда, бақылауға алынатын заттарды сақтаудың жалғыз жолы EntityTransformationServiceImpl көп болса, онда олар дизайнымен тез және ыңғайлы болады үлгілері мен DDD-ге тығыз байланысты. Олар кішігірім бағдарламалар үшін тіпті қарапайым тәсілмен тиімдірек болады. Қалай таңқаларлық, сізге бейімделу керек, бұл тамаша тәжірибе болады.

Дегенмен, бейімделе отырып, оны бір жақты көзқарастың тереңдігін, кез-келген жерде жұмыс істеуге болатындығын, жан-жақты болуды және кез-келген маманмен міндетті түрде сарапшы болмай-ақ қандай құралдарды білуді үйрену арасындағы сабақта сабақ ретінде қабылдау керек. Әлемде екеуіне де артықшылықтар бар, екеуі де қажет.

2
қосылды