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

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

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

Резултати

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

Код

REPOSITORY = 'https://github.com/KonstantinDobrev/ruby-retrospective-1'
# Двадесетте неща, които научих:
#
#1. Не е необходимо да използвам стандартния each за каквито и да е операции.
#2. Как да използвам each_cons като удобен начин за съставяне на подмасиви от изходящ.
#3. Аргумент на count може да бъде масив, а не само единична стойност.
#4. Не е препоръчително да идентирам с цели табове, защото стандартът е два интервала.
#5. Как и къде да използвам map(&:action) вместо map { |el| el.action }
#6. Обхождането на елементи на дадена структура може да се извърши с cycle вместо с each.
#7. Задаването на стойност по подразбиране, която да бъде връщана от кеш, може да става директно в конструктора, вместо с Hash.default
#8. Многократната проверка за типова съвместивост може да се избегне чрез просто конвертиране (Array(string)).
#9. Използването на функции като all? и any? (Enumerable) могат значително да подобрят яснотата на кода.
#10. Как и кога трябва да ограничавам достъпа до определени методи в даден клас.
#11. Използването на Enumerable може да сведе до минимум необходимостта от дефинирането на нови методи за обработка на данни.
#12. Форматирането на данните в дадена променлива е по-добре да се извършва при присвояване, а не допълнително след това чрез "опасни" методи.
#13. Дефинирането на attr_accessor-и трябва да се прави само когато е наложително.
#14. Дефинирането на повече класове вместо структури е по-добър вариант при обектно-ориентираните езици като Ruby.
#15. Многократната проверка за наличието на обект може да се избегне чрез дефинирането на клас, описващ липсата му (като NoPromotion).
#16. Проверката за валидни стойности на променливи може да се извърши в отделен, създаден специално за тази цел, клас (class Checker).
#17. Принтирането на данни също може да се извършва в отделен клас, вместо в класа, съдържащ тези данни.
#18. За многократното използването на едни и същи данни могат да се дефинират константи (Border).
#19. Препоръчително е обработката на данните на даден клас да се извършва в него, а не в други класове.
#20. Дефинирането на допълнителни подметоди към главни подобрява четливостта и улеснява евентуалното им редактиране (class Printer).

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

Константин обнови решението на 14.11.2011 15:42 (преди около 13 години)

+REPOSITORY = 'https://github.com/KonstantinDobrev/ruby-retrospective-1'
+
+# Двадесетте неща, които научих:
+#
+#1. Не е необходимо да използвам стандартния each за каквито и да е операции.
+#2. Как да използвам each_cons като удобен начин за съставяне на подмасиви от изходящ.
+#3. Аргумент на count може да бъде масив, а не само единична стойност.
+#4. Не е препоръчително да идентирам с цели табове, защото стандартът е два интервала.
+#5. Как и къде да използвам map(&:action) вместо map { |el| el.action }
+#6. Обхождането на елементи на дадена структура може да се извърши с cycle вместо с each.
+#7. Задаването на стойност по подразбиране, която да бъде връщана от кеш, може да става директно в конструктора, вместо с Hash.default
+#8. Многократната проверка за типова съвместивост може да се избегне чрез просто конвертиране (Array(string)).
+#9. Използването на функции като all? и any? (Enumerable) могат значително да подобрят яснотата на кода.
+#10. Как и кога трябва да ограничавам достъпа до определени методи в даден клас.
+#11. Използването на Enumerable може да сведе до минимум необходимостта от дефинирането на нови методи за обработка на данни.
+#12. Форматирането на данните в дадена променлива е по-добре да се извършва при присвояване, а не допълнително след това чрез "опасни" методи.
+#13. Дефинирането на attr_accessor-и трябва да се прави само когато е наложително.
+#14. Дефинирането на повече класове вместо структури е по-добър вариант при обектно-ориентираните езици като Ruby.
+#15. Многократната проверка за наличието на обект може да се избегне чрез дефинирането на клас, описващ липсата му (като NoPromotion).
+#16. Проверката за валидни стойности на променливи може да се извърши в отделен, създаден специално за тази цел, клас (class Checker).
+#17. Принтирането на данни също може да се извършва в отделен клас, вместо в класа, съдържащ тези данни.
+#18. За многократното използването на едни и същи данни могат да се дефинират константи (Border).
+#19. Препоръчително е обработката на данните на даден клас да се извършва в него, а не в други класове.
+#20. Дефинирането на допълнителни подметоди към главни подобрява четливостта и улеснява евентуалното им редактиране (class Printer).