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

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

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

Резултати

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

Код

REPOSITORY = 'https://github.com/radmanovi4/ruby-retrospective-4'
# 1. Да се съсредоточавам повече върху просто и очаквано решение на проблема, вместо непременно да се стремя да преизползвам обща функционалност.
# 2. В case отделни when случаи, които връщат един и същ резултат, могат да се разделят със запетайки в единичен when случай.
# 3. В case е по-приятно за четене, когато when клаузите са индентирани по-навътре от самия 'case'
# 4. Когато се пресмята рекурсивена редица от сорта на числата на Фибоначи си струва да се погледне дали няма константно решение на проблема (не използвах това решение в новата версия, но все пак е нещо, което научих по темата).
# 5. Не е нужно да се ползва set, когато същото поведение може да се постигне без почти никакви усилия с масив.
# 6. Set сравнява елементите си с .equal? и не е особено удачен избор, когато искаме да сравняваме в колекцията с '==' (като например 6, 6.0 и Rational(6,1))
# 7. Освен с модули, удобно е да се преизползва функционалност и с обикновено наследяване.
# 8. В наследяващия клас използване на super (без скоби) приема параметрите, подадени на метода. В случаите, когато искаме да избегнем това, задължително указваме, че не искаме super да приема аргументи - super().
# 9. Когато дефинираме метод, приемащ единствен аргумент обект от същия клас, много четимо е да кръстим този аргумент "other".
# 10. Когато искаме да ограничим дължината на ред при дълги логически операции (и, или, ...), най-добре е да пренасяме на нов ред директно след символа за логическата операция.
# 11. Когато дефинираме each (например в клас, включващ Enumerable модула), и в класа имаме дефинирана колекция, която имплементира each, може просто да извикаме each на тази колекция с аргумент (&block). Излишно е да проверяваме ръчно дали е подаден блок и след това да итерираме по вътрешната колекция и да yield-ваме един по един нейните елементи.
# 12. По-гъвкаво е при initialize, в който обикновено създаваме празна вътрешна за класа колекция, да сложим аргумент за колекцията, към която ще създадем референция от класа, и тя по подразбиране да бъде празна такава, вместо да не оставяме възможност за добавяне на аргументи и всеки път да създаваме единствено празна колекция.
# 13. Да си прочитам условието пак преди предаване, с внимание към corner case-ове. :)
# 14. Когато има два (или повече) хеша, точно един от които съдържа търсен клчю, е по-елегантно вместо if - else да се ползва <хеш1>[<ключ>] || <хеш2>[<ключ>] || ...
# 15. Когато искам да взема подмасив на масив по определено начало и дължина е по-удобно да използвам <масив>[<начало>...<начало+дължина>], вместо <масив>[<начало>..<начало+дължина> - 1].
# 16. Ако два или повече класа използват стринг, на базата на който (по идентичен начин) попълват свои променливи, по-чисто е да се дефинира отделен клас конкретно за рязането на стринга и връщането на необходимите подстрингове и въпросните класове да си парсват наготово подстринговете. Целта е класът за рязането да пази състоянието на стринга вътрешно, вместо двата (или повече) класа един по един да режат от него и да си го предават. :)
# 17. Методът ljust (rjust) се използва за заемане на определна ширина от стринг (и запълване на остатъка с интервали или каквото му кажем).
# 18. Ако искам да изпълня (и евентуално върна) стойността на блок, подаден на функция, може да се ползва instance_eval.
# 19. Ако ще се дефинират 5-6 или повече класа, струва си да се помисли кои от тях каква обща функционалност имат и общите функционалности да се изнесат в отделни класове, от който да се наследява.
# 20. Да започвам задачите навреме. :)

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

Александър обнови решението на 18.01.2015 09:58 (преди над 9 години)

+REPOSITORY = 'https://github.com/radmanovi4/ruby-retrospective-4'
+
+# 1. Да се съсредоточавам повече върху просто и очаквано решение на проблема, вместо непременно да се стремя да преизползвам обща функционалност.
+# 2. В case отделни when случаи, които връщат един и същ резултат, могат да се разделят със запетайки в единичен when случай.
+# 3. В case е по-приятно за четене, когато when клаузите са индентирани по-навътре от самия 'case'
+# 4. Когато се пресмята рекурсивена редица от сорта на числата на Фибоначи си струва да се погледне дали няма константно решение на проблема (не използвах това решение в новата версия, но все пак е нещо, което научих по темата).
+
+# 5. Не е нужно да се ползва set, когато същото поведение може да се постигне без почти никакви усилия с масив.
+# 6. Set сравнява елементите си с .equal? и не е особено удачен избор, когато искаме да сравняваме в колекцията с '==' (като например 6, 6.0 и Rational(6,1))
+# 7. Освен с модули, удобно е да се преизползва функционалност и с обикновено наследяване.
+# 8. В наследяващия клас използване на super (без скоби) приема параметрите, подадени на метода. В случаите, когато искаме да избегнем това, задължително указваме, че не искаме super да приема аргументи - super().
+# 9. Когато дефинираме метод, приемащ единствен аргумент обект от същия клас, много четимо е да кръстим този аргумент "other".
+# 10. Когато искаме да ограничим дължината на ред при дълги логически операции (и, или, ...), най-добре е да пренасяме на нов ред директно след символа за логическата операция.
+# 11. Когато дефинираме each (например в клас, включващ Enumerable модула), и в класа имаме дефинирана колекция, която имплементира each, може просто да извикаме each на тази колекция с аргумент (&block). Излишно е да проверяваме ръчно дали е подаден блок и след това да итерираме по вътрешната колекция и да yield-ваме един по един нейните елементи.
+# 12. По-гъвкаво е при initialize, в който обикновено създаваме празна вътрешна за класа колекция, да сложим аргумент за колекцията, към която ще създадем референция от класа, и тя по подразбиране да бъде празна такава, вместо да не оставяме възможност за добавяне на аргументи и всеки път да създаваме единствено празна колекция.
+
+# 13. Да си прочитам условието пак преди предаване, с внимание към corner case-ове. :)
+# 14. Когато има два (или повече) хеша, точно един от които съдържа търсен клчю, е по-елегантно вместо if - else да се ползва <хеш1>[<ключ>] || <хеш2>[<ключ>] || ...
+# 15. Когато искам да взема подмасив на масив по определено начало и дължина е по-удобно да използвам <масив>[<начало>...<начало+дължина>], вместо <масив>[<начало>..<начало+дължина> - 1].
+# 16. Ако два или повече класа използват стринг, на базата на който (по идентичен начин) попълват свои променливи, по-чисто е да се дефинира отделен клас конкретно за рязането на стринга и връщането на необходимите подстрингове и въпросните класове да си парсват наготово подстринговете. Целта е класът за рязането да пази състоянието на стринга вътрешно, вместо двата (или повече) класа един по един да режат от него и да си го предават. :)
+
+# 17. Методът ljust (rjust) се използва за заемане на определна ширина от стринг (и запълване на остатъка с интервали или каквото му кажем).
+# 18. Ако искам да изпълня (и евентуално върна) стойността на блок, подаден на функция, може да се ползва instance_eval.
+# 19. Ако ще се дефинират 5-6 или повече класа, струва си да се помисли кои от тях каква обща функционалност имат и общите функционалности да се изнесат в отделни класове, от който да се наследява.
+# 20. Да започвам задачите навреме. :)