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

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

Решение на Четвърта задача от Георги Събев

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

Към профила на Георги Събев

Резултати

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

Код

REPOSITORY = 'https://github.com/gsabev/ruby-retrospective-1'
# 1. Методът each_cons може да е ползен при имплементирането на алгорими върху редици
# 2. Методът tap може да бъде полезен ако искаме да направимнещо с обекта преди да го върнем.
# По принцип правенето на 2 неща на 1 ред не е най-чистото нещо, но в руби оставянето на
# 1 ред със съдържание проментлива изглежда малко тъпо. С tap можем да напишем
# def a
# hash.tap { |h| h['a'] = 1}
# end
#
# вместо
#
# def a
# hash['a'] = 1
# hash
# end
# Това напомня за монадите донякъде и предполагам че е валиден подход. На мен ми изглежда по-красиво.
# 3. Добре е да преизползваме това, което вече имаме - често човек не забелязва че може да използва вече
# дефиниран свой метод, защото мисли в термините на стандартните библиотеким а не в термините на проблемната
# област.
# 4. Функционалните елементи са яки! Мисля че доста научих за техното приложение напоследък. На практика почти
# елиминират нуждата от цикли. В руби е грозно да видиш for или while.
# 5. Масивите могат да се държат почти като множества - предефинират операциите с множества и имат uniq метод.
# 6. Keep it simple - винаги е добра идея да използваме възможно най-простата конструкция, която ни върши работа.
# Дори да виждаме някакви (преодолими) органичения. По този начин е най-лесно на по-късен етап да адаптираме
# кода към някои ограничения, за които дори не подозираме в самото начало. Не е добре да правим overengineering
# Така кода става по-сложен и често от гъвкавостта, която сме заложили в решението няма смисъл, а се налагат
# други непредвидени разширения.
# 7. Едновременното присвояване в руби е яко - спестява място, кодът не става по-малко четим от това. Понякога
# използвайки едновременно присвояване можем да си спестим употтребата на временни променливи, което определено
# прави кода по-четим.
# 8. Не трябва да се прекалява с употребата на яки конструкции. Трябва да се набляга да четимостта на кода.
# 9. Подробният спек е от жизнено важно значение за лесно рефакториране на кода. Руби е доста по удобен за
# Test Driven Development от езиците като Java, които се компилират.
# 10. Налседяването в руби е почти ненужно - има duck typing и mixins - трябва да се прави само когато наистина носи ползи
# 11. Декларирането на методите за достъп в началото на класа с attr_accessor или attr_reader прави кода доста
# по-кратък и по-четим.
# 12. Методите all? и any? за колекция са доста полезени - преди да ги открия ползвах inject, което е доста...
# обстоятелствено.
# 13. Методите Array и String на Kernel могат да спестят някои досадни проверки. Липсата на досадни проверки
# прави кода по-четим
# 14. Класовете трябва да са малки и да имат 1 ясна цел. Това иначе доста ясно твърдение от ООП теорията добива нов
# смисъл в динамичните езици като руби. Класовете са наистина кратки без купчините декларации на променливи
# и типове и без купчините гетъри и сетъри, които не носят никаква информация на четящия кода.
# 15. NullObjectPattern - бях чувал за този патърн, но бях забравил за него. Примера с купоните и намаленията
# доста добре илюстрира плзата от него.
# 16. Операцията * за String в руби може да е много удобна когато рисуваме таблици в конзолата.
# 17. Ако част от 1 клас използва твърде голяма част от вътрешното състояние на друг клас, значи нещо не е наред.
# Трябва да отделим тази част и да я сложим в другия клас.
# 18. Когато приемаме нещо на входа в един формат, а трябва да го пазим в друг формат е добре ясно да дефинираме
# границата между тези два формата. Хубаво е да я изберем така че да се минимизират преобразуванията. Иначе
# стават спагети и е много трудно да променим нещо в този код.
# 19. Ако един клас започне да става твърде голям или сложен - т.е започнем да използваме за вътрешното му представяне
# прекалено сложни типове или прекалено сложни операции - значи можем да отделим част от този клас в отделен клас.
# Той най-вероятно прави повече от 1 нещо.
# 20. Кодът на руби трябва да има ниска степен на вложение. Трябва да изглежда декларативно. Ако често ни се налага
# да минаваме по-навътре вероятно бъркаме някъде или пропускаме нещо.

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

Георги обнови решението на 13.11.2011 17:33 (преди над 12 години)

+REPOSITORY = 'https://github.com/gsabev/ruby-retrospective-1'
+
+# 1. Методът each_cons може да е ползен при имплементирането на алгорими върху редици
+# 2. Методът tap може да бъде полезен ако искаме да направимнещо с обекта преди да го върнем.
+# По принцип правенето на 2 неща на 1 ред не е най-чистото нещо, но в руби оставянето на
+# 1 ред със съдържание проментлива изглежда малко тъпо. С tap можем да напишем
+# def a
+# hash.tap { |h| h['a'] = 1}
+# end
+#
+# вместо
+#
+# def a
+# hash['a'] = 1
+# hash
+# end
+# Това напомня за монадите донякъде и предполагам че е валиден подход. На мен ми изглежда по-красиво.
+# 3. Добре е да преизползваме това, което вече имаме - често човек не забелязва че може да използва вече
+# дефиниран свой метод, защото мисли в термините на стандартните библиотеким а не в термините на проблемната
+# област.
+# 4. Функционалните елементи са яки! Мисля че доста научих за техното приложение напоследък. На практика почти
+# елиминират нуждата от цикли. В руби е грозно да видиш for или while.
+# 5. Масивите могат да се държат почти като множества - предефинират операциите с множества и имат uniq метод.
+# 6. Keep it simple - винаги е добра идея да използваме възможно най-простата конструкция, която ни върши работа.
+# Дори да виждаме някакви (преодолими) органичения. По този начин е най-лесно на по-късен етап да адаптираме
+# кода към някои ограничения, за които дори не подозираме в самото начало. Не е добре да правим overengineering
+# Така кода става по-сложен и често от гъвкавостта, която сме заложили в решението няма смисъл, а се налагат
+# други непредвидени разширения.
+# 7. Едновременното присвояване в руби е яко - спестява място, кодът не става по-малко четим от това. Понякога
+# използвайки едновременно присвояване можем да си спестим употтребата на временни променливи, което определено
+# прави кода по-четим.
+# 8. Не трябва да се прекалява с употребата на яки конструкции. Трябва да се набляга да четимостта на кода.
+# 9. Подробният спек е от жизнено важно значение за лесно рефакториране на кода. Руби е доста по удобен за
+# Test Driven Development от езиците като Java, които се компилират.
+# 10. Налседяването в руби е почти ненужно - има duck typing и mixins - трябва да се прави само когато наистина носи ползи
+# 11. Декларирането на методите за достъп в началото на класа с attr_accessor или attr_reader прави кода доста
+# по-кратък и по-четим.
+# 12. Методите all? и any? за колекция са доста полезени - преди да ги открия ползвах inject, което е доста...
+# обстоятелствено.
+# 13. Методите Array и String на Kernel могат да спестят някои досадни проверки. Липсата на досадни проверки
+# прави кода по-четим
+# 14. Класовете трябва да са малки и да имат 1 ясна цел. Това иначе доста ясно твърдение от ООП теорията добива нов
+# смисъл в динамичните езици като руби. Класовете са наистина кратки без купчините декларации на променливи
+# и типове и без купчините гетъри и сетъри, които не носят никаква информация на четящия кода.
+# 15. NullObjectPattern - бях чувал за този патърн, но бях забравил за него. Примера с купоните и намаленията
+# доста добре илюстрира плзата от него.
+# 16. Операцията * за String в руби може да е много удобна когато рисуваме таблици в конзолата.
+# 17. Ако част от 1 клас използва твърде голяма част от вътрешното състояние на друг клас, значи нещо не е наред.
+# Трябва да отделим тази част и да я сложим в другия клас.
+# 18. Когато приемаме нещо на входа в един формат, а трябва да го пазим в друг формат е добре ясно да дефинираме
+# границата между тези два формата. Хубаво е да я изберем така че да се минимизират преобразуванията. Иначе
+# стават спагети и е много трудно да променим нещо в този код.
+# 19. Ако един клас започне да става твърде голям или сложен - т.е започнем да използваме за вътрешното му представяне
+# прекалено сложни типове или прекалено сложни операции - значи можем да отделим част от този клас в отделен клас.
+# Той най-вероятно прави повече от 1 нещо.
+# 20. Кодът на руби трябва да има ниска степен на вложение. Трябва да изглежда декларативно. Ако често ни се налага
+# да минаваме по-навътре вероятно бъркаме някъде или пропускаме нещо.