Списъци от символи с %i( foo bar baz )

Програмиране с Ruby

Курс във Факултета по Математика и Информатика към СУ

Решение на Пета задача от Светослав Кузманов

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

Към профила на Светослав Кузманов

Резултати

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

Код

REPOSITORY = 'https://github.com/SvetoslavKuzmanov/ruby-retrospective-4'
# Двадесет неща, които научих.
#
# 1. Подреждането и правилната идентация на код са много по важни
# от колкото си мислех. Помагат за четимостта и разбирането.
# 2. При повече от една проверка върху една променлива е по добре
# да се използва case от колкото няколко поредни if команди.
# 3. При писане на достатъчно четим код коментарите са излишни.
# По-добре кодът да говори сам за себе си от колкото да се пишат
# коментари по неясен код.
# 4. Не трябва да се 'превежда' директно от програмен език в друг,
# а да се търси по-лесно и елегантно решение използвайки
# средствата на конкретния език.
# 5. Микро-оптимизациите се правят последно и то само ако е
# необходимо. В повечето случаи ако нещо работи бавно, то е
# заради лош дизайн.
# 6. Когато дадени фунционалнисти се използват от няколко класа
# по-добре е те да се имплементират в един от класовете, а
# останалите да го наследят, отколкото да се изнесе в отделен
# модул който да се добави в класовете.
# 7. По-четимо и по добре изглеждащо е при дефиниране на метод
# без параметри скобите да се изпуснат.
# 8. Подходящите имена на променливите помагат много за
# четимостта на кода. Те трябва да са максимално близки до
# домейна на проблема който решаваме.
# 9. По-добре имплементацията на решението на даден проблем
# да бъде по-проста и лесно четима, от колкото магически работеща
# хитра и малко по-бърза.
# 10. Синонимите на фунции в руби са много хубаво нещо, много
# широко приложение намират, и е хубаво да се използват за да
# може деден руби израз да съвпада с контекста си.
# 11. Всеки метод и всеки клас трябва да имат единствена и
# конкретна задача.
# 12. Хубаво е да хващаме грешки причинени от "околната среда",
# а не грешки причинени от неправилна употреба на парче код.
# 13. Интроспекцията е code smell и трябва да се използва само
# и единствено когато няма друг начин за решаване на даден
# проблем.
# 14. Не трябва да достъпваме инстанционни променливи с метода,
# Object#instance_variable_get, защото по този начин нарушаваме,
# енкапсулацията.

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

Светослав обнови решението на 19.01.2015 16:55 (преди над 9 години)

+REPOSITORY = 'https://github.com/SvetoslavKuzmanov/ruby-retrospective-4'
+
+# Двадесет неща, които научих.
+#
+# 1. Подреждането и правилната идентация на код са много по важни
+# от колкото си мислех. Помагат за четимостта и разбирането.
+# 2. При повече от една проверка върху една променлива е по добре
+# да се използва case от колкото няколко поредни if команди.
+# 3. При писане на достатъчно четим код коментарите са излишни.
+# По-добре кодът да говори сам за себе си от колкото да се пишат
+# коментари по неясен код.
+# 4. Не трябва да се 'превежда' директно от програмен език в друг,
+# а да се търси по-лесно и елегантно решение използвайки
+# средствата на конкретния език.
+# 5. Микро-оптимизациите се правят последно и то само ако е
+# необходимо. В повечето случаи ако нещо работи бавно, то е
+# заради лош дизайн.
+# 6. Когато дадени фунционалнисти се използват от няколко класа
+# по-добре е те да се имплементират в един от класовете, а
+# останалите да го наследят, отколкото да се изнесе в отделен
+# модул който да се добави в класовете.
+# 7. По-четимо и по добре изглеждащо е при дефиниране на метод
+# без параметри скобите да се изпуснат.
+# 8. Подходящите имена на променливите помагат много за
+# четимостта на кода. Те трябва да са максимално близки до
+# домейна на проблема който решаваме.
+# 9. По-добре имплементацията на решението на даден проблем
+# да бъде по-проста и лесно четима, от колкото магически работеща
+# хитра и малко по-бърза.
+# 10. Синонимите на фунции в руби са много хубаво нещо, много
+# широко приложение намират, и е хубаво да се използват за да
+# може деден руби израз да съвпада с контекста си.
+# 11. Всеки метод и всеки клас трябва да имат единствена и
+# конкретна задача.
+# 12. Хубаво е да хващаме грешки причинени от "околната среда",
+# а не грешки причинени от неправилна употреба на парче код.
+# 13. Интроспекцията е code smell и трябва да се използва само
+# и единствено когато няма друг начин за решаване на даден
+# проблем.
+# 14. Не трябва да достъпваме инстанционни променливи с метода,
+# Object#instance_variable_get, защото по този начин нарушаваме,
+# енкапсулацията.

Решенията ти не минават проверката на skeptic ограниченията, не си написал достатъчно неща и си подобрявал само решението на първа задача.

"6. Когато дадени фунционалнисти се използват от няколко класа по-добре е те да се имплементират в един от класовете, а останалите да го наследят, отколкото да се изнесе в отделен модул който да се добави в класовете."

Това не е съвсем така. Наследяването трябва да се ползва внимателно и често не е правилният подход, защото не е това отношението между обектите, които моделираш в кода си. Тоест, ако искаш да споделяш функционалност, се ползват точно модули, които се миксират в класа, или направо отделен клас, реализиращ тази функционалност, който останалия код ползва. Наследяване се ползва само там, където наистина има смисъл да се изрази такова отношение между обектите.

Като цяло, нещата, които си споделил, че си научил, са добри, но не са конкретно отразени в подобрение на решенията ти, каквото беше условието на задачата.