Решение на Пета задача от Петър Костов

Обратно към всички решения

Към профила на Петър Костов

Код

REPOSITORY = 'https://github.com/peperon/ruby-retrospective-2'
# Двадесет неща, които научих
#
# 1. Няма нужда да оставям празен ред след началото и преди края на реда в клас.
# 2. На първа задача, конструирането не fuzzbuzz метода не е достатъчно четимо. По добре е с if..else конструкции.
# 3. Методът densites е сложно написан и count може да се ползва по по-добър начин.
# 4. Методът group_values на първа задача има страничен ефект(ако човек поиска несъществуващ ключ, получава празен
# списък). Може да стане по-добре с each_with_object.
# 5. На първа задача, в метода prime_divisors, вместо 2..abs и 2..Math.sqrt(n) е по-добре да се ползва 2.upto(abs),
# защото е по-четимо.
# 6. При парсването на текста във втора задача е по елегантно да се ползва map, вместо да се бутат нещата в масив.
# Отделно е по-четимо, за параметри на блока да се ползват именовани аргументи.
# 7. За парсването отново, chomp е по-подходящ от strip.
# 8. Когато имаме класов метод в който искаме да създадем инстанция от същия клас, по-елегатно е и по-кратко да го направим като
# извикаме new ..., вместо Collection.new ...
# 9. Глупаво е да се ползва send в методът, който взима уникалните имена на артистите, песните и албумите.
# 10. По добре е проверката дали дадена песен изпълнява определен критерии да бъде в Criterion класът.
# 11. Има смъсъл за по-добра абстракция Criteria да бъде модул и да бъде само интерфейс за създаване на Criterion
# обекти.
# 12. Мисля, че използвам твърде много скоби за втора задача, което е малко безмислено.
# 13. За трета задача, избраната от мен структура не е подходяща. По-добре е да не се вкарва Visitor pattern в задачата,
# защото се усложнява допълнително. Този pattern е по-добър, когато се добавят нови операции и по-лош когато се добавят
# нови изрази.
# 14. В предишната версия на трета задача Expr беше само интерфейс, който създаваше обекти за изразите. В тази съм
# използвал подхода той да бъде началото на йерархията за изразите.
# 15. Конструирането на изразите в Expr.build при старата версия не беше много четливо, този вариант ми се струва по-четлив.
# 16. В старото решение на задачата съм дефинирал конструктури и в наследниците на Unary и Binary, а това не е нужно.
# 17. Нещо което съм изпуснал в старото решение при сравнението на изрази е да проверявам дали са от един клас.
# 18. Изчисляването на изрази в старата версия на места е неприятно импелемнтирано. Например за изчисляването на сума
# или произведение съм използвал inject, а в новата версия не съм и мисля, че така е по-четимо.
# 19. Като цяло научих да не внимавам като правя дизайн на някое решение за даден проблем, защото ми се случва прост
# проблем да го превръщам в сложен с идеята някой ден да се имплементира нова функционалност по-лесно.
# 20. Научих, че в Ruby(и за други езици е подобно в една или друга степен) когато инцидентната сложност започне да
# нараства най-вероятно има проблем с дизайна на кода.

История (1 версия и 0 коментара)

Петър обнови решението на 30.12.2012 17:40 (преди над 11 години)

+REPOSITORY = 'https://github.com/peperon/ruby-retrospective-2'
+
+# Двадесет неща, които научих
+#
+# 1. Няма нужда да оставям празен ред след началото и преди края на реда в клас.
+# 2. На първа задача, конструирането не fuzzbuzz метода не е достатъчно четимо. По добре е с if..else конструкции.
+# 3. Методът densites е сложно написан и count може да се ползва по по-добър начин.
+# 4. Методът group_values на първа задача има страничен ефект(ако човек поиска несъществуващ ключ, получава празен
+# списък). Може да стане по-добре с each_with_object.
+# 5. На първа задача, в метода prime_divisors, вместо 2..abs и 2..Math.sqrt(n) е по-добре да се ползва 2.upto(abs),
+# защото е по-четимо.
+# 6. При парсването на текста във втора задача е по елегантно да се ползва map, вместо да се бутат нещата в масив.
+# Отделно е по-четимо, за параметри на блока да се ползват именовани аргументи.
+# 7. За парсването отново, chomp е по-подходящ от strip.
+# 8. Когато имаме класов метод в който искаме да създадем инстанция от същия клас, по-елегатно е и по-кратко да го направим като
+# извикаме new ..., вместо Collection.new ...
+# 9. Глупаво е да се ползва send в методът, който взима уникалните имена на артистите, песните и албумите.
+# 10. По добре е проверката дали дадена песен изпълнява определен критерии да бъде в Criterion класът.
+# 11. Има смъсъл за по-добра абстракция Criteria да бъде модул и да бъде само интерфейс за създаване на Criterion
+# обекти.
+# 12. Мисля, че използвам твърде много скоби за втора задача, което е малко безмислено.
+# 13. За трета задача, избраната от мен структура не е подходяща. По-добре е да не се вкарва Visitor pattern в задачата,
+# защото се усложнява допълнително. Този pattern е по-добър, когато се добавят нови операции и по-лош когато се добавят
+# нови изрази.
+# 14. В предишната версия на трета задача Expr беше само интерфейс, който създаваше обекти за изразите. В тази съм
+# използвал подхода той да бъде началото на йерархията за изразите.
+# 15. Конструирането на изразите в Expr.build при старата версия не беше много четливо, този вариант ми се струва по-четлив.
+# 16. В старото решение на задачата съм дефинирал конструктури и в наследниците на Unary и Binary, а това не е нужно.
+# 17. Нещо което съм изпуснал в старото решение при сравнението на изрази е да проверявам дали са от един клас.
+# 18. Изчисляването на изрази в старата версия на места е неприятно импелемнтирано. Например за изчисляването на сума
+# или произведение съм използвал inject, а в новата версия не съм и мисля, че така е по-четимо.
+# 19. Като цяло научих да не внимавам като правя дизайн на някое решение за даден проблем, защото ми се случва прост
+# проблем да го превръщам в сложен с идеята някой ден да се имплементира нова функционалност по-лесно.
+# 20. Научих, че в Ruby(и за други езици е подобно в една или друга степен) когато инцидентната сложност започне да
+# нараства най-вероятно има проблем с дизайна на кода.