Решение на Четвърта задача от Здравко Стойчев

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

Към профила на Здравко Стойчев

Резултати

  • 0 точки от тестове
  • 0 бонус точки
  • 0 точки общо
  • 0 успешни тест(а)
  • 0 неуспешни тест(а)

Код

REPOSITORY = 'https://github.com/zstoychev/ruby-retrospective-1'
# 1. Документацията трябва да се чете внимателно.
# 2. Поставяне на незадължителен self пред член на класа не спомага към
# четимостта.
# 3. Често each може да бъде заменен от много по-подходящ метод от Enumerable.
# 4. Брой елементи от съвкупност, за които е изпълнено условие = count.
# 5. Когато на всеки елемент от съвкупност по някакво правило се съпоставя
# елемент, с цел да се получи съвкупност от новите елементи, се използва map.
# 6. Използването на немутиращи операции е за предпочитане пред мутиращи,
# когато е възможно. Мутиращите чупят функционалната парадигма и правят
# четенето и писането по-трудни.
# 7. Операторът * извиква Array() върху аргумента си. Едно от местата, в които
# може да бъде използван, е в литерала [] за образуване на част от
# елементите на получения от литерала масив, използвайки елементите на
# върнатия от Array() масив.
# 8. Дизайнът около по-ефективни структури вместо за по-добър и лесно изменяем
# код често е лош.
# 9. Близки класове е добре да бъдат изнесени в един модул.
# 10. Всеки клас трябва да има една ясна цел.
# 11. Когато имаме повече методи в клас, които зависят само от част от данните
# на обектите на класа, може би е добре да се отделят заедно с данните в
# отделен клас.
# 12. Трябва да се намират подходящи начини за избягване повторение на код.
# Един възможен е повтарящият код да се отдели на едно подходящо място
# (например метод), а различния да бъде отделен в подходящи класове и да
# бъде достъпван чрез полиморфизъм.
# 13. Промяната на дадена част от кода трябва да води до необходимост от
# промяна във възможно най-малко места.
# 14. Неща, за които е доста вероятно да бъдат променени, или за които е
# възможно да възникне нужда от различни версии, е добре да се изнесат на
# отделно място с подходящ интерфейс.
# 15. Дълги вериги от извиквания често са признак за лош дизайн на класовете.
# Понякога подходящо решение е делегация.
# 16. Прекалено дългите редове се четат по-лесно когато бъдат разделени на
# отделни изрази, всеки от който се присвои на променливи с подходящи
# имена. Ако това разделяне не е възможно то най-вероятно има дълги вериги
# или друг лош дизайн.
# 17. Когато един метод е дълъг и сложен, то вероятно върши няколко неща, всеки
# от което е по-добре да бъде изведено в отделен метод. Така биха могли дори
# да се обособят методи, които са подходящи за извеждане в отделен клас.
# 18. Съвкупност от ламбди е трудно за четене. Често могат да се заменят с case
# или разделяне в подходящи класове.
# 19. За проверка на предусловия е по-ясно, когато е възможно, да се провери дали
# те са изпълнени, а не дали не са изпълнени, тоест с
# unless условие1 and условие2...
# 20. Сложни операции върху обект, зависещи само от неговото състояние, може да e
# добре да бъдат изнесени като метод на обекта с ясно име. Това би позволило
# и по-голяма независимост на реализацията. Например item.discounted? вместо
# item.discount > 0.

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

Здравко обнови решението на 14.11.2011 16:01 (преди над 12 години)

+REPOSITORY = 'https://github.com/zstoychev/ruby-retrospective-1'
+
+# 1. Документацията трябва да се чете внимателно.
+# 2. Поставяне на незадължителен self пред член на класа не спомага към
+# четимостта.
+# 3. Често each може да бъде заменен от много по-подходящ метод от Enumerable.
+# 4. Брой елементи от съвкупност, за които е изпълнено условие = count.
+# 5. Когато на всеки елемент от съвкупност по някакво правило се съпоставя
+# елемент, с цел да се получи съвкупност от новите елементи, се използва map.
+# 6. Използването на немутиращи операции е за предпочитане пред мутиращи,
+# когато е възможно. Мутиращите чупят функционалната парадигма и правят
+# четенето и писането по-трудни.
+# 7. Операторът * извиква Array() върху аргумента си. Едно от местата, в които
+# може да бъде използван, е в литерала [] за образуване на част от
+# елементите на получения от литерала масив, използвайки елементите на
+# върнатия от Array() масив.
+# 8. Дизайнът около по-ефективни структури вместо за по-добър и лесно изменяем
+# код често е лош.
+# 9. Близки класове е добре да бъдат изнесени в един модул.
+# 10. Всеки клас трябва да има една ясна цел.
+# 11. Когато имаме повече методи в клас, които зависят само от част от данните
+# на обектите на класа, може би е добре да се отделят заедно с данните в
+# отделен клас.
+# 12. Трябва да се намират подходящи начини за избягване повторение на код.
+# Един възможен е повтарящият код да се отдели на едно подходящо място
+# (например метод), а различния да бъде отделен в подходящи класове и да
+# бъде достъпван чрез полиморфизъм.
+# 13. Промяната на дадена част от кода трябва да води до необходимост от
+# промяна във възможно най-малко места.
+# 14. Неща, за които е доста вероятно да бъдат променени, или за които е
+# възможно да възникне нужда от различни версии, е добре да се изнесат на
+# отделно място с подходящ интерфейс.
+# 15. Дълги вериги от извиквания често са признак за лош дизайн на класовете.
+# Понякога подходящо решение е делегация.
+# 16. Прекалено дългите редове се четат по-лесно когато бъдат разделени на
+# отделни изрази, всеки от който се присвои на променливи с подходящи
+# имена. Ако това разделяне не е възможно то най-вероятно има дълги вериги
+# или друг лош дизайн.
+# 17. Когато един метод е дълъг и сложен, то вероятно върши няколко неща, всеки
+# от което е по-добре да бъде изведено в отделен метод. Така биха могли дори
+# да се обособят методи, които са подходящи за извеждане в отделен клас.
+# 18. Съвкупност от ламбди е трудно за четене. Често могат да се заменят с case
+# или разделяне в подходящи класове.
+# 19. За проверка на предусловия е по-ясно, когато е възможно, да се провери дали
+# те са изпълнени, а не дали не са изпълнени, тоест с
+# unless условие1 and условие2...
+# 20. Сложни операции върху обект, зависещи само от неговото състояние, може да e
+# добре да бъдат изнесени като метод на обекта с ясно име. Това би позволило
+# и по-голяма независимост на реализацията. Например item.discounted? вместо
+# item.discount > 0.