Решение на Четвърта задача от Борис Русев

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

Към профила на Борис Русев

Резултати

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

Код

REPOSITORY = 'https://github.com/borchy/ruby-retrospective-1'
# Първа задача
# 1. Не ползвай self, когато няма смисъл от него (тоест не добавя
# към четимостта)
# 2. Не ползвай return ... виж 1.
# 3. За предпочитане е да се ползва yield...което на мене не ми
# изглежда по-четимо, но може и да има аргументи в негова защита,
# за които да не се сещам
#
# Втора задача
# 1. Не добавяй атрибути, които не са част от state-a на обекта
# 2. Старай се да правиш обектите си immutable
# 3. Съхранявай променливи и/или параметри, които са част от
# state-a на обекта, дори и да не са предадени директно на
# конструктора
# 4. Каквото няма да е нужно на потребителя на класа, или ако нещо
# разкрива имплементационен детайл, скрий го. Важи за state и
# behavior
# 5. Избягвай имплементации, които зависят от типа на някой от
# параметрите. Това предполагам е защото Руби е duck-typing и ние
# се интересуваме от интерфейса на обекта, а не от имплементацията
# 6. Ползвай select вместо res = [] arr.each { |el| res << el if
# bla }
# 7. Ползвай Array() вместо return elem.kind_of? Array ? elem :
# [elem]
# 8. String#lines е unexplored territory. От една страна низовете
# съдържат \n, а от друга можело да поема и блок като аргумент
# 9. Indices are for pussies my friend (russianaccent)
# 10. Резултата от това да се престараваш е същият, като от това
# да не се стараеш достатъчно. Механиката е различна, тогава се
# получава едно зациклящо забиване в детайли, което ти пречи да
# излезеш от рамката и да видиш, че the big picture не е добра
# 11. След като прочетеш документацията на най-ползваните класове
# си напиши задачата, и я прочети отново. Проблемът е, че когато
# четеш нещо, е много трудно да го запомниш ако не му видиш
# приложение, тоест конкретен твой проблем, който то решава.
# Но това не означава, че няма смисъл да се чете преди задачата.
# Предварителният прочит е важен дори и в случаите, когато не се
# вижда директно приложение, защото по този начин се подготвя
# съзнанието за потенциални проблеми и решения. Не важат
# оправдания от сорта на "Ще го прочета, когато ми потрябва, няма
# нужда да го помня наизуст", защото няма да прочетеш нищо, ако
# не знаеш че го има. Имплементацията не е важно да се помни, но
# е важно да се знае че инструмента съществува
#
# Трета задача
# 1. Припомни си грешките от всички предходни домашни
# 2. Кръщавай си променливите, така че да е ясен типа им
# 3. Внимавай как си конструираш dependency-тата между класовете # например няма нужда в Inventory да се съхранява hash, който
# за съответното име да връща промоция, по-добре е да е array,
# който да пази промоции
# 4. Внимавай с разпределението на responsibility-тата на
# класовете. Както продукта си е отговорен за собственото име и
# цена в съотвеният магазин, също така си отговаря и за
# промоцията, на която е пуснат. Валидацията да се прави от този
# клас който е отговорен за тези данни, а не от този който го
# използва
# 5. Factory-тата е хубаво да се ползват само веднъж, а именно
# при инициализацията на обекта, а не да се викат всеки път
# когато искаме да го ползваме. Ако това се налага е по-добре
# да се използва lazy factory

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

Борис обнови решението на 14.11.2011 10:46 (преди над 12 години)

+REPOSITORY = 'https://github.com/borchy/ruby-retrospective-1'
+
+# Първа задача
+# 1. Не ползвай self, когато няма смисъл от него (тоест не добавя
+# към четимостта)
+# 2. Не ползвай return ... виж 1.
+# 3. За предпочитане е да се ползва yield...което на мене не ми
+# изглежда по-четимо, но може и да има аргументи в негова защита,
+# за които да не се сещам
+#
+# Втора задача
+# 1. Не добавяй атрибути, които не са част от state-a на обекта
+# 2. Старай се да правиш обектите си immutable
+# 3. Съхранявай променливи и/или параметри, които са част от
+# state-a на обекта, дори и да не са предадени директно на
+# конструктора
+# 4. Каквото няма да е нужно на потребителя на класа, или ако нещо
+# разкрива имплементационен детайл, скрий го. Важи за state и
+# behavior
+# 5. Избягвай имплементации, които зависят от типа на някой от
+# параметрите. Това предполагам е защото Руби е duck-typing и ние
+# се интересуваме от интерфейса на обекта, а не от имплементацията
+# 6. Ползвай select вместо res = [] arr.each { |el| res << el if
+# bla }
+# 7. Ползвай Array() вместо return elem.kind_of? Array ? elem :
+# [elem]
+# 8. String#lines е unexplored territory. От една страна низовете
+# съдържат \n, а от друга можело да поема и блок като аргумент
+# 9. Indices are for pussies my friend (russianaccent)
+# 10. Резултата от това да се престараваш е същият, като от това
+# да не се стараеш достатъчно. Механиката е различна, тогава се
+# получава едно зациклящо забиване в детайли, което ти пречи да
+# излезеш от рамката и да видиш, че the big picture не е добра
+# 11. След като прочетеш документацията на най-ползваните класове
+# си напиши задачата, и я прочети отново. Проблемът е, че когато
+# четеш нещо, е много трудно да го запомниш ако не му видиш
+# приложение, тоест конкретен твой проблем, който то решава.
+# Но това не означава, че няма смисъл да се чете преди задачата.
+# Предварителният прочит е важен дори и в случаите, когато не се
+# вижда директно приложение, защото по този начин се подготвя
+# съзнанието за потенциални проблеми и решения. Не важат
+# оправдания от сорта на "Ще го прочета, когато ми потрябва, няма
+# нужда да го помня наизуст", защото няма да прочетеш нищо, ако
+# не знаеш че го има. Имплементацията не е важно да се помни, но
+# е важно да се знае че инструмента съществува
+#
+# Трета задача
+# 1. Припомни си грешките от всички предходни домашни
+# 2. Кръщавай си променливите, така че да е ясен типа им
+# 3. Внимавай как си конструираш dependency-тата между класовете # например няма нужда в Inventory да се съхранява hash, който
+# за съответното име да връща промоция, по-добре е да е array,
+# който да пази промоции
+# 4. Внимавай с разпределението на responsibility-тата на
+# класовете. Както продукта си е отговорен за собственото име и
+# цена в съотвеният магазин, също така си отговаря и за
+# промоцията, на която е пуснат. Валидацията да се прави от този
+# клас който е отговорен за тези данни, а не от този който го
+# използва
+# 5. Factory-тата е хубаво да се ползват само веднъж, а именно
+# при инициализацията на обекта, а не да се викат всеки път
+# когато искаме да го ползваме. Ако това се налага е по-добре
+# да се използва lazy factory