Sign In
Create Account
Back to top |
Chirurgia cranio-cerebrală minim invazivă
Tehnicile minim invazive impun utilizarea unei tehnologii ultramoderne. Endoscoapele operatorii de diverse tipuri, microscopul operator dedicat, neuronavigația, neuroelectrofiziologia, tehnicile avansate de anestezie, chirurgia cu pacientul treaz reprezintă armamentarium fără de care neurochirurgia prin "gaura cheii" nu ar fi posibilă. Folosind tehnicile de mai sus, tratăm un spectru larg de patologii cranio-cerebrale. www.neurohope.ro |
Baze de date embedded – exercitiu practic (pentru programatori mid-level)
2 votes
Last Updated: Oct 10 2018 14:21, Started by
jegmihai
, Sep 07 2018 22:27
·
0
0
#93
Posted 22 September 2018 - 14:29
|
OriginalCopy, on 21 septembrie 2018 - 15:11, said:
Exceptie in constructor: https://github.com/w...rc/Mark.php#L28 Datorita exceptiei, nu poti construi VOs invalide. Si datorita faptului ca celelalte modele accepta exclusiv VO, nu poti infecta niciun alt model cu date invalide (sintactic). Contact(std::string_view lastName, std::string_view firstName, std::string_view phoneNumber) noexcept; Contact(LastName const& lastName, FirstName const& firstName, PhoneNumber const& phoneNumber) noexcept; După ce rezolvi asta, putem vorbi despre o clasă Contact incoruptibilă. |
#94
Posted 22 September 2018 - 15:17
|
Done.
Am rezolvat și issue-ul legat de pattern matching, deși se putea mai bine aici (regex-ul nu este cel mai permisiv). |
#95
Posted 22 September 2018 - 15:25
|
C++ are un soi de pattern matching cu std::variant si visit, dar nu e prea frumos.
|
#96
Posted 22 September 2018 - 18:38
|
Până acum am tot menționat și aplicat niște principii.
Dacă te uiți pe main, care dintre aceste principii sunt violate? main e parte din ui desktop plugin și acest plugin are ca dependințe domain model și storage. Faptul că aceste dependințe sunt menționate în main e ok. Dar ce nu e ok? |
#97
Posted 22 September 2018 - 18:59
|
Faptul că PhoneBook nu manageriază plugin-urile de sub ea?
|
#98
Posted 22 September 2018 - 19:10
#99
Posted 22 September 2018 - 19:28
|
Anterior ai spus că este OK și daca asamblez plugins manual, deci nu este asta.
Faptul că le adaug in PhoneBook? Deși nici asta nu-mi pare în neregulă. Faptul că instanțiez PhoneBook? |
#100
Posted 22 September 2018 - 19:29
|
jegmihai, on 22 septembrie 2018 - 19:22, said:
Anterior ai spus că este OK și daca asamblez plugins manual, deci nu este asta. Aia a fost atunci. Acum codul arată omenește pe unele fronturi, și a venit vremea reconsiderării unor decizii. Dar vreau să văd dacă faci o distincție anume legată de "asamblarea" asta. Ceva e în neregulă cu ea, dar ce? Uită de trecut. Uită-te pe cod așa cum e el acum, și gândește-te la principii. |
|
#101
Posted 22 September 2018 - 20:35
|
Expun clase concrete de plugins?
Pe lângă asta, InMemorySQLite își expune readModel-ul. "leaky abstractions" |
#102
Posted 22 September 2018 - 20:43
|
Nu înțeleg exact, dar nu e asta. Vorbim despre main și nimic altceva.
"asamblarea" e practic corect, dar e compusă din diferite lucruri. Unul din acele lucruri e definitiv greșit. |
#103
Posted 22 September 2018 - 21:34
|
OriginalCopy, on 22 septembrie 2018 - 20:43, said:
dar e compusă din diferite lucruri. InMemorySQLiteStoragePlugin storagePlugin; ... UiPlugin uiPlugin(argc, argv); Instanțierea plugin-urilor mi se pare perfect în regulă.
storagePlugin.init();
uiPlugin.init(std::vector<IPlugin*>{&storagePlugin});
Inițierea fiecăruia din nou este OK. Și tu ai menționat acest lucru.if(storagePlugin.run()) return uiPlugin.run();Singurul lucru greșit s-ar putea ascunde aici. (Am făcut abstracție de PhoneBook). |
#104
Posted 22 September 2018 - 22:06
|
Ok, rezolv misterul: faptul că main nu doar că știe care sunt pluginurile, ci și dependențele fiecăreia și ordinea lor când e apelat init.
Aceste lucruri ar trebui tratate de fiecare plugin în parte. E vremea acelui getDependencies și tot mecanismul adiacent. Ca parte din acest refactoring: Introduci un director nou src/infrastructure/ Muți phonebook în el și o redenumești Application. Application va ști cum să initializeze pluginurile și să le execute. Creezi phonebook în domain model. Are ca membru o map de ContactId și Contact. Repository nu îți returnează o listă de contacte din search și listAll, ci PhoneBook cu contacte în ele. Ui folosește PhoneBook peste tot, consistent. |
#105
Posted 23 September 2018 - 18:01
|
|
#106
Posted 23 September 2018 - 20:05
#107
Posted 24 September 2018 - 10:24
|
OriginalCopy, on 22 septembrie 2018 - 22:06, said:
Introduci un director nou src/infrastructure/ Muți phonebook în el și o redenumești Application. Application va ști cum să initializeze pluginurile și să le execute. Creezi phonebook în domain model. Are ca membru o map de ContactId și Contact. Repository nu îți returnează o listă de contacte din search și listAll, ci PhoneBook cu contacte în ele. Trebuie acum să implementez sistemul de asamblare. |
#108
Posted 24 September 2018 - 13:53
|
jegmihai, on 24 septembrie 2018 - 10:24, said:
Done. Trebuie acum să implementez sistemul de asamblare. Food for thought: o alta varianta ar fi sa ai o clasa PluginRegistry care stie toate pluginurile si adaugarea de pluginuri in app e facuta in colaborare app <-> registry. Ar fi overengineering din punctul meu de vedere. Tu ce crezi si de ce? Si daca esti de acord ca ar fi overengineering, in ce situatii ai introduce totusi un astfel de registru? |
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
-
- Change Theme
- English
- Mark Community Read
- Termene & conditii
- Confidentialitate
- Consimtamant
- Cookies
- Help
© 2001-2024 Softpedia. All rights reserved. Softpedia® and the Softpedia logo are registered trademarks of SoftNews Net SRL.
Ora implicita a Forumului Softpedia este ora standard a Romaniei (GMT+2). Mai multe informatii →
⚠ Postarile afisate pe Forumul Softpedia reprezinta o opinie subiectiva a membrilor care le-au publicat si nu a SoftNews Net SRL.