Sign In
Create Account
Back to top
 |
Second Opinion
Folosind serviciul second opinion ne puteți trimite RMN-uri, CT -uri, angiografii, fișiere .pdf, documente medicale. Astfel vă vom putea da o opinie neurochirurgicală, fără ca aceasta să poată înlocui un consult de specialitate. Răspunsurile vor fi date prin e-mail în cel mai scurt timp posibil (de obicei în mai putin de 24 de ore, dar nu mai mult de 48 de ore). Second opinion – Neurohope este un serviciu gratuit. 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
#145
Posted 25 September 2018 - 23:03
|
Solutia: introducem o noua abstractie.
Pe de o parte trebuie sa instantiem un Plugin pentru a ii afla dependintele. Pe de alta parte, trebuie sa ii pasam dependintele constructorului pluginului. De aici rezulta conflictul. init() nu e deloc problema, ci getDependencies() care nu e la locul potrivit. getDependencies() e metoda a fix acelui lucru (pluginul) ale carui dependinte vrem sa le aflam => imposibil. Cum sa numim aceasta noua abstractie? Eu i-as zice PluginSpecification. Fiecare plugin are unul. Application::addPlugin() devine Application::addPluginSpecification(). |
#147
Posted 26 September 2018 - 12:05
|
This one? Interesant, dar fa-o simplist de tot, nu ca acolo: extrage getDependencies() in clase separate care implementeaza PluginSpecification si adapteaza Application. Simplu, nimic fancy, un refactoring de 30-60 minute. |
#148
Posted 26 September 2018 - 12:15
|
Fiecare plugin are unul. |
#149
Posted 26 September 2018 - 12:20
|
Ca membru? Mai degraba invers: PluginSpecification are o factory method pentru Plugin. |
#150
Posted 26 September 2018 - 16:11
|
Interesant, dar fa-o simplist de tot, nu ca acolo: extrage getDependencies() in clase separate care implementeaza PluginSpecification si adapteaza Application. Momentan la mine arată așa.
class IPluginSpecification
{
public:
virtual ~IPluginSpecification() = default;
virtual IPlugin* create(std::vector<IPlugin*> const& dependencies = std::vector<IPlugin*>())
= 0;
virtual std::vector<std::string> getDependencies() const noexcept = 0;
};
Am adaptat Application, funcționează, însă nu știu dacă s-ar comporta 100% corect în alte cazuri. Asta ar fi metoda care s-ar ocupa de instanțiere.
auto Application::instantiatePlugins(std::vector<int> const& topologicallySorted) -> void
{
for (auto currentSpecificationIndex = 0; currentSpecificationIndex < topologicallySorted.size();
++currentSpecificationIndex)
{
std::vector<IPlugin*> dependenciesSupplier;
for (auto const & [ specificationIndex, dependencySpecificationIndex ] : _dependencies)
{
if (currentSpecificationIndex == specificationIndex)
dependenciesSupplier.push_back(_plugins[dependencySpecificationIndex]); //Linia asta mă îngrijorează.
}
if (dependenciesSupplier.empty())
_plugins.push_back(_specifications[currentSpecificationIndex]->create());
else
_plugins.push_back(
_specifications[currentSpecificationIndex]->create(dependenciesSupplier));
}
}
|
#152
Posted 27 September 2018 - 08:04
|
Voi mai testa metoda instantiatePlugins(), iar apoi voi incerca să scap de naked pointers.
|
#153
Posted 27 September 2018 - 11:27
|
Voi mai testa metoda instantiatePlugins() Am făcut update-ul complet pe GitHub. |
#154
Posted 27 September 2018 - 19:24
|
Am descoperit un bug pe care l-am corectat. Am făcut update-ul complet pe GitHub. |
|
#155
Posted 27 September 2018 - 19:55
|
Sunt mulțumit.
Acum vreau să revin asupra UI-ului. Atenție că până acum, din motive de testare, am folosit vechiul storage plugin, fără Repository. Acum trebuie să adaptez UI-ul să comunice cu noul storage plugin. Comunicarea dintre ele trebuie să se facă exclusiv prin obiecte din domain model? |
#156
Posted 27 September 2018 - 20:02
|
La citire de informatii din DB, ar trebui sa primesti doar modele.
La salvare, ai nevoie de PhonebookRepository, apelezi metode din el precum delete, create, update, cu modelul (Contact) corespunzator ca parametru. Variatii si abordari exista o gramada. Toate implica crearea de noi abstractii, construirea de noi punti in arhitectura. Pe astea le inveti pe masura ce citesti despre arhitectura, si in practica. Nu as include in acest proiect nimic altceva. Ce ai acum poate fi carmit in multe directii, ti le las tie ca "tema pentru acasa" sa le explorezi. |
#157
Posted 27 September 2018 - 21:51
|
La citire de informatii din DB, ar trebui sa primesti doar modele. Cum se numește mai exact acest sistem bazat pe plugins? Nu am găsit nici o denumire oficială/altceva.
Ce ai acum poate fi carmit in multe directii, ti le las tie ca "tema pentru acasa" sa le explorezi. Mulțumesc frumos pentru tot suportul pe care mi l-ai oferit de-a lungul acestui proiect.
Cum se numește mai exact acest sistem bazat pe plugins? Nu am găsit nici o denumire oficială/altceva. OriginalCopy said:
Arhitectura pe care ti-o dau e bazata pe POCO si nu am gasit o situatie in care nu e buna, poate fi suprapusa peste orice combinatie de tehnologii sau arhitecturi. E sinteza mea personala a foarte multor ani de proiecte de succes care ruleaza milioane / an, carti, articole si conferinte. Presupun ca exista proiecte facute curat de altii intr-un mod similar, dar eu nu am intalnit asa ceva pana acum in industrie. Unii POs sunt reticenti atunci cand incerci sa le "vinzi" ideea unei arhitecturi curate, deoarece au impresia ca ar costa mai mult. Eu iti arat cum poti face lucruri cu mijloace simple, pastrand codul curat, modular, si cu probabilitate de buguri mai mica. |
#158
Posted 28 September 2018 - 06:14
|
Și aici presupun că voi fi nevoit să folosesc un soi de adapter. repository returneaza si/sau opereaza cu obiecte Contact / Phonebook. Important e sa folosesti doar repositories oferite de storage. Storage are doar trei clase publice (utilizate de alte pluginuri): plugin specification, clasa plugin insasi si repository (adaugi noi repositories dupa nevoi, ceea ce nu e necesar pentru aceasta aplicatie). Pastreaza suprafata de contact cat mai mica. PS: uita-te prin toate fisierele si curata-le. De exemplu includes nefolosite: https://github.com/I...esktop/main.cpp Edited by OriginalCopy, 28 September 2018 - 06:42. |
#159
Posted 28 September 2018 - 09:03
|
repository returneaza si/sau opereaza cu obiecte Contact / Phonebook. Pe de altă parte, pe fluxul Storage -> Ui, cel din urmă va avea nevoie de un Qt Model. Contact/PhoneBook sunt model-urile mele, însă ele trebuie să fie adaptate pentru a putea fi folosite împreună cu View-urile din Qt. Bineînțeles că treaba asta o pot face în interiorul lui Ui Plugin. Am aceeași problemă ca cel de aici: https://stackoverflo...to-qt-tableview. Edited by jegmihai, 28 September 2018 - 09:04. |
|
#160
Posted 28 September 2018 - 14:22
|
A da, acel adapter, bineînțeles că ai nevoie de el.
Dar fi atent să nu introduci acel model specific UI nici în storage, nici în domain model. Si nici să nu modifici modelul în orice mod. Asta te asigură că într-adevăr modificarea ce tine de ui chiar rămâne în ui. |
#161
Posted 28 September 2018 - 18:18
|
Cum se numește mai exact acest sistem bazat pe plugins? Nu am găsit nici o denumire oficială/altceva. Dacă ai vizionat deja, după experiența acestui proiect vei înțelege că ce zice uncle bob trebuie luat fix ca atare, cuvânt cu cuvânt: [ https://www.youtube-nocookie.com/embed/asLUTiJJqdE?feature=oembed - Pentru incarcare in pagina (embed) Click aici ] |
#162
Posted 28 September 2018 - 21:35
|
Mi-am creat propriul model, am reușit să-l folosesc, dar mai am de lucru.
|
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.