[Homework] - SOLID Principles in Software Design
Здравейте, някой може ли да ми покаже решение на задачата от домашното от SOLID принципи.
Нещо съвсем се овъртях и обърках...
Конкретно ако искаш насоки, дай код. Иначе днес именно това решавахме, има и видео:
Благодарско, определено видеото ще ми е от голяма полза. (не бях стигнал до него)
За да не отварям нова тема, ще ползвам тази :).
Това е моето решение, на въпросното домашно. Ще се радвам на всякаква критика и препоръки :).
Аз имам няколко забележки без да съм прегледал обстойно цялата ти творба:
1. Не бих именовал базовите класове AbstractНещо - по-скоро биха били Нещо и наследниците им ще са ConsoleНещо, FileНещо и т.н.
2. Ексепшън месиджите на DataValidator са ти хардкоднати - аз бих ги изнесъл в енумерация.
3. В StandartReportLevelComparer - аз не бих правил такова сложно конвертиране - щях просто да задам стойности на членовете на енумерацията и директно да ги сравнявам с някакво публично пропърти или константа, която пази границата за изписване и може да се сетва според желанието на потребителя. В базовия клас бих сложил само един абстрактен метод Compare, който да приема енумерация и бих оставил всеки наследник да си го разписва в зависимост от това каква енумерация приема.
4. В лейаут класовете - нямаш нужда от тоя суич/кейс, за да изписваш енумерациите - като подадеш стойност от енумерация на някой от държавните статични класове дето пише стрингове насам-натам - той си я изписва като стринг директно, както е с останалите типове данни.
Ами това е на пръв поглед, надявам се да съм бил полезен...
Поздрави!
П.П. А защо линкът, който Наско е дал по-горе е счупен?
Привет,
Първо, благодаря за отделеното време :).
На мен лично ми е по-лесно да се ориентирам, когато имената на абстрактните класове си казват, че класовете са абстрактни. Така, само с един поглед разбираш къде е абстракцията, а не, чак когато отвориш въпросните файлове. Но да, това Abstract сякаш седи малко грозно. Данчо препоръча да ползвам формата НещоBase, което май наистина изглежда по-приемливо.
За останалите неща, си напълно прав, че миришат доста :D. Exception съобщенията, си мислех дали да не ги изнеса в отделен статичен клас и да се дърпат от там, при нужда. Това с Enum ToString() метода, не бях сигурен, дали няма да ми върне namespace-a на енумерацията и понеже бързах го направих така :D. Иначе, за Compare-a, не се бях сетил, че членовете на енумерацията си имат default-ни стойности. Определено могат да се ползват за Standard comparer-a. Но, мисля, да оставя йерархията на методите така, понеже ако се направи Non-Standard сравнител, може вече да се ползва switch, който да връща определени стойности за всеки член, например в reversed ред или нещо такова :).
Отново, благодаря, за отделеното време. Much appreciated :).
Поздрави!
Идеята да оставиш Compare метода абстрактен е с цел да намалиш каплинга и да можеш да му подаваш каква да е енумерация, а не само вече създадената. Не бих разчитал на дифолтните стойности на енумерацията - ако им зададеш собствени, примерно 10, 20, 30, 40 - това ти дава възможност да вмъкваш нови между тях - примерно 35 - и по този начин ще зависиш само от зададена threshold константа.
Относно ексепшъните - както казах пак е по-добре енумерация - аз лично избягвам употребата на статични класове. И Наско и Данчо не еднократно са обяснявали защо.
Единственото куцо е, че в C# енумерациите не могат да се наследяват - тук са просто запечатана колекция от константи. В Java примерно не е така - там са си практически отделен клас, в който можеш да добавяш и методи и т.н.
Понеже съм малко назад чак сега го почнах това домашно и се оплетох нещо. Предполагам, че утре като седна по-сериозно, а и огледам на колегата решението ще го направя обаче дали е възможно да направите едно видео с решението на това домашно, както сте правили и с предния випуск (линка по-горе ми казва, че няма такъв ресурс) ? Мисля че ще е полезно за доста хора.