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

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

Решение на Пета задача от Мария Терзиева

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

Към профила на Мария Терзиева

Резултати

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

Код

REPOSITORY = 'http://github.com/MariaTerzieva/ruby-retrospective-3'
# Двадесет неща, които научих:
#
# Първа задача:
#
# 1. Методите Integer#pred и Integer#succ са по-удобни от self - 1 или self + 1
# съответно, ако трябва да chain-ваме функции или да работим с range-ове, а и
# кодът изглежда по-изчистено.
# 2. Методите String#chars и String#split('') правят едно и също. По-изчистеният
# вариант от двата е String#chars.
# 3. По-добре е да се използва Enumerable#reduce вместо Enumerable#inject, ако
# искаме да намерим сбора на числа в даден интервал, а и Ruby Style Guide-ът го
# предпочита.
# 4. По-изчистено е да се използват референции към методи(в map например) вместо да
# се подава блок. Имам предвид, че map(&:to_i) е по-добро от map { |char| char.to_i }.
# 5. Когато искаме да премахнем елементи с дадено свойство от масив, е по-идиоматично
# да използваме Array#reject вместо Array#select.
# 6. Enumerable#find намира първия елемент, за който подаденият блок се оценява на истина.
# Това е много по-добра алтернатива от това да циклим в range с while.
# 7. Enumerable#each_with_object е по-добър вариант от Enumerable#each, ако искаме да
# пазим в някакъв обект(например хеш) резултати от обхождането и после да
# върнем този обект.
#
# Втора задача:
#
# 8. По-добре е да си дефинираме помощен метод или клас, който се справя с цялата
# логика на нещо(например Parser), отколкото да раздробяваме логиката на един метод
# в няколко метода заради skeptic ограниченията.
# 9. В модулите няма private методи.
# 10. Добре е имплементационните детайли да са скрити от потребителя.
#
# Трета задача:
#
# 11. Alias и alias_method трябва да се дефинират след метода, на който са синоними.
# 12. Когато имаме attr_reader за дадена инстанционна променлива, може да използваме
# него вместо инстанционната променлива за по-голяма прегледност на кода.
# 13. Когато използваме помощни класове, добра практика е да ги сложим като вътрешни
# класове за класа, в който се използват.
# 14. Трябва да се спазва DRY принципа. Може да се ползва наследяване например.
# 15. Трябва да се избягва да се дефинират attr_reader-и за инстанционни променливи,
# които са масиви, защото потребителят много лесно може да ги промени с мутираща
# операция(например Array#<<). Вместо това може да се дефинира each метод например.
#
# Четвърта задача:
#
# 16. Не е добра практика да се ползва define_method в method_missing.
# 17. Ламбдите може да са елементи на масиви и стойности в хешове.
# 18. За да може да се използват инстанционни променливи в ламбди, после трябва да
# използваме instance_exec вместо call.
# 19. Добра практика е неща, подадени като стойности на константи, да се freeze-ват.
# 20. На Hash.new може да се подава блок, който се вика, ако някой иска да достъпи
# несъществуващ ключ в хеша.

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

Мария обнови решението на 19.01.2014 00:12 (преди около 10 години)

+REPOSITORY = 'http://github.com/MariaTerzieva/ruby-retrospective-3'
+
+# Двадесет неща, които научих:
+#
+# Първа задача:
+#
+# 1. Методите Integer#pred и Integer#succ са по-удобни от self + 1 или self - 1
+# съответно, ако трябва да chain-ваме функции или да работим с range-ове, а и
+# кодът изглежда по-изчистено.
+# 2. Методите String#chars и String#split('') правят едно и също. По-изчистеният
+# вариант от двата е String#chars.
+# 3. По-добре е да се използва Enumerable#reduce вместо Enumerable#inject, ако
+# искаме да намерим сбора на числа в даден интервал, а и Ruby Style Guide-ът го
+# предпочита.
+# 4. По-изчистено е да се използват референции към методи(в map например) вместо да
+# се подава блок. Имам предвид, че map(&:to_i) е по-добро от map { |char| char.to_i }.
+# 5. Когато искаме да премахнем елементи с дадено свойство от масив, е по-идиоматично
+# да използваме Array#reject вместо Array#select.
+# 6. Enumerable#find намира първия елемент, за който подаденият блок се оценява на истина.
+# Това е много по-добра алтернатива от това да циклим в range с while.
+# 7. Enumerable#each_with_object е по-добър вариант от Enumerable#each, ако искаме да
+# пазим в някакъв обект(например хеш) резултати от обхождането и после да
+# върнем този обект.
+#
+# Втора задача:
+#
+# 8. По-добре е да си дефинираме помощен метод или клас, който се справя с цялата
+# логика на нещо(например Parser), отколкото да раздробяваме логиката на един метод
+# в няколко метода заради skeptik ограниченията.
+# 9. В модулите няма private методи.
+# 10. Добре е имплементационните детайли да са скрити от потребителя.
+#
+# Трета задача:
+#
+# 11. Alias и alias_method трябва да се дефинират след метода, на който са синоними.
+# 12. Когато имаме attr_reader за дадена инстанционна променлива, може да използваме
+# него вместо инстанционната променлива за по-голяма прегледност на кода.
+# 13. Когато използваме помощни класове, добра практика е да ги сложим като вътрешни
+# класове за класа, в който се използват.
+# 14. Трябва да се спазва DRY принципа.
+# 15. Трябва да се избягва да се дефинират attr_reader-и за инстанционни променливи,
+# които са масиви, защото потребителят много лесно може да ги промени с мутираща
+# операция(например Array#<<). Вместо това може да се дефинира each метод например.
+#
+# Четвърта задача:
+#
+# 16. Не е добра практика да се дефинира метод в method_missing.
+# 17. Ламбдите може да са елементи на масиви и стойности в хешове.
+# 18. За да може да се използват инстанционни променливи в ламбди, после трябва да
+# използваме instance_exec вместо call.
+# 19. Добра практика е неща, подадени като стойности на константи, да се freeze-ват.
+# 20. На Hash.new може да се подава блок, който се вика, ако някой иска да достъпи
+# несъществуващ ключ в хеша.

Мария обнови решението на 19.01.2014 12:23 (преди около 10 години)

REPOSITORY = 'http://github.com/MariaTerzieva/ruby-retrospective-3'
# Двадесет неща, които научих:
#
# Първа задача:
#
# 1. Методите Integer#pred и Integer#succ са по-удобни от self + 1 или self - 1
# съответно, ако трябва да chain-ваме функции или да работим с range-ове, а и
# кодът изглежда по-изчистено.
# 2. Методите String#chars и String#split('') правят едно и също. По-изчистеният
# вариант от двата е String#chars.
# 3. По-добре е да се използва Enumerable#reduce вместо Enumerable#inject, ако
# искаме да намерим сбора на числа в даден интервал, а и Ruby Style Guide-ът го
# предпочита.
# 4. По-изчистено е да се използват референции към методи(в map например) вместо да
# се подава блок. Имам предвид, че map(&:to_i) е по-добро от map { |char| char.to_i }.
# 5. Когато искаме да премахнем елементи с дадено свойство от масив, е по-идиоматично
# да използваме Array#reject вместо Array#select.
# 6. Enumerable#find намира първия елемент, за който подаденият блок се оценява на истина.
# Това е много по-добра алтернатива от това да циклим в range с while.
# 7. Enumerable#each_with_object е по-добър вариант от Enumerable#each, ако искаме да
# пазим в някакъв обект(например хеш) резултати от обхождането и после да
# върнем този обект.
#
# Втора задача:
#
# 8. По-добре е да си дефинираме помощен метод или клас, който се справя с цялата
# логика на нещо(например Parser), отколкото да раздробяваме логиката на един метод
-# в няколко метода заради skeptik ограниченията.
+# в няколко метода заради skeptic ограниченията.
# 9. В модулите няма private методи.
# 10. Добре е имплементационните детайли да са скрити от потребителя.
#
# Трета задача:
#
# 11. Alias и alias_method трябва да се дефинират след метода, на който са синоними.
# 12. Когато имаме attr_reader за дадена инстанционна променлива, може да използваме
# него вместо инстанционната променлива за по-голяма прегледност на кода.
# 13. Когато използваме помощни класове, добра практика е да ги сложим като вътрешни
# класове за класа, в който се използват.
# 14. Трябва да се спазва DRY принципа.
# 15. Трябва да се избягва да се дефинират attr_reader-и за инстанционни променливи,
# които са масиви, защото потребителят много лесно може да ги промени с мутираща
# операция(например Array#<<). Вместо това може да се дефинира each метод например.
#
# Четвърта задача:
#
# 16. Не е добра практика да се дефинира метод в method_missing.
# 17. Ламбдите може да са елементи на масиви и стойности в хешове.
# 18. За да може да се използват инстанционни променливи в ламбди, после трябва да
# използваме instance_exec вместо call.
# 19. Добра практика е неща, подадени като стойности на константи, да се freeze-ват.
# 20. На Hash.new може да се подава блок, който се вика, ако някой иска да достъпи
# несъществуващ ключ в хеша.

Мария обнови решението на 21.01.2014 20:09 (преди около 10 години)

REPOSITORY = 'http://github.com/MariaTerzieva/ruby-retrospective-3'
# Двадесет неща, които научих:
#
# Първа задача:
#
# 1. Методите Integer#pred и Integer#succ са по-удобни от self + 1 или self - 1
# съответно, ако трябва да chain-ваме функции или да работим с range-ове, а и
# кодът изглежда по-изчистено.
# 2. Методите String#chars и String#split('') правят едно и също. По-изчистеният
# вариант от двата е String#chars.
# 3. По-добре е да се използва Enumerable#reduce вместо Enumerable#inject, ако
# искаме да намерим сбора на числа в даден интервал, а и Ruby Style Guide-ът го
# предпочита.
# 4. По-изчистено е да се използват референции към методи(в map например) вместо да
# се подава блок. Имам предвид, че map(&:to_i) е по-добро от map { |char| char.to_i }.
# 5. Когато искаме да премахнем елементи с дадено свойство от масив, е по-идиоматично
# да използваме Array#reject вместо Array#select.
# 6. Enumerable#find намира първия елемент, за който подаденият блок се оценява на истина.
# Това е много по-добра алтернатива от това да циклим в range с while.
# 7. Enumerable#each_with_object е по-добър вариант от Enumerable#each, ако искаме да
# пазим в някакъв обект(например хеш) резултати от обхождането и после да
# върнем този обект.
#
# Втора задача:
#
# 8. По-добре е да си дефинираме помощен метод или клас, който се справя с цялата
# логика на нещо(например Parser), отколкото да раздробяваме логиката на един метод
# в няколко метода заради skeptic ограниченията.
# 9. В модулите няма private методи.
# 10. Добре е имплементационните детайли да са скрити от потребителя.
#
# Трета задача:
#
# 11. Alias и alias_method трябва да се дефинират след метода, на който са синоними.
# 12. Когато имаме attr_reader за дадена инстанционна променлива, може да използваме
# него вместо инстанционната променлива за по-голяма прегледност на кода.
# 13. Когато използваме помощни класове, добра практика е да ги сложим като вътрешни
# класове за класа, в който се използват.
-# 14. Трябва да се спазва DRY принципа.
+# 14. Трябва да се спазва DRY принципа. Може да се ползва наследяване например.
# 15. Трябва да се избягва да се дефинират attr_reader-и за инстанционни променливи,
# които са масиви, защото потребителят много лесно може да ги промени с мутираща
# операция(например Array#<<). Вместо това може да се дефинира each метод например.
#
# Четвърта задача:
#
-# 16. Не е добра практика да се дефинира метод в method_missing.
+# 16. Не е добра практика да се ползва define_method в method_missing.
# 17. Ламбдите може да са елементи на масиви и стойности в хешове.
# 18. За да може да се използват инстанционни променливи в ламбди, после трябва да
# използваме instance_exec вместо call.
# 19. Добра практика е неща, подадени като стойности на константи, да се freeze-ват.
# 20. На Hash.new може да се подава блок, който се вика, ако някой иска да достъпи
# несъществуващ ключ в хеша.

Мария обнови решението на 21.01.2014 20:14 (преди около 10 години)

REPOSITORY = 'http://github.com/MariaTerzieva/ruby-retrospective-3'
# Двадесет неща, които научих:
#
# Първа задача:
#
-# 1. Методите Integer#pred и Integer#succ са по-удобни от self + 1 или self - 1
+# 1. Методите Integer#pred и Integer#succ са по-удобни от self - 1 или self + 1
# съответно, ако трябва да chain-ваме функции или да работим с range-ове, а и
# кодът изглежда по-изчистено.
# 2. Методите String#chars и String#split('') правят едно и също. По-изчистеният
# вариант от двата е String#chars.
# 3. По-добре е да се използва Enumerable#reduce вместо Enumerable#inject, ако
# искаме да намерим сбора на числа в даден интервал, а и Ruby Style Guide-ът го
# предпочита.
# 4. По-изчистено е да се използват референции към методи(в map например) вместо да
# се подава блок. Имам предвид, че map(&:to_i) е по-добро от map { |char| char.to_i }.
# 5. Когато искаме да премахнем елементи с дадено свойство от масив, е по-идиоматично
# да използваме Array#reject вместо Array#select.
# 6. Enumerable#find намира първия елемент, за който подаденият блок се оценява на истина.
# Това е много по-добра алтернатива от това да циклим в range с while.
# 7. Enumerable#each_with_object е по-добър вариант от Enumerable#each, ако искаме да
# пазим в някакъв обект(например хеш) резултати от обхождането и после да
# върнем този обект.
#
# Втора задача:
#
# 8. По-добре е да си дефинираме помощен метод или клас, който се справя с цялата
# логика на нещо(например Parser), отколкото да раздробяваме логиката на един метод
# в няколко метода заради skeptic ограниченията.
# 9. В модулите няма private методи.
# 10. Добре е имплементационните детайли да са скрити от потребителя.
#
# Трета задача:
#
# 11. Alias и alias_method трябва да се дефинират след метода, на който са синоними.
# 12. Когато имаме attr_reader за дадена инстанционна променлива, може да използваме
# него вместо инстанционната променлива за по-голяма прегледност на кода.
# 13. Когато използваме помощни класове, добра практика е да ги сложим като вътрешни
# класове за класа, в който се използват.
# 14. Трябва да се спазва DRY принципа. Може да се ползва наследяване например.
# 15. Трябва да се избягва да се дефинират attr_reader-и за инстанционни променливи,
# които са масиви, защото потребителят много лесно може да ги промени с мутираща
# операция(например Array#<<). Вместо това може да се дефинира each метод например.
#
# Четвърта задача:
#
# 16. Не е добра практика да се ползва define_method в method_missing.
# 17. Ламбдите може да са елементи на масиви и стойности в хешове.
# 18. За да може да се използват инстанционни променливи в ламбди, после трябва да
# използваме instance_exec вместо call.
# 19. Добра практика е неща, подадени като стойности на константи, да се freeze-ват.
# 20. На Hash.new може да се подава блок, който се вика, ако някой иска да достъпи
# несъществуващ ключ в хеша.

Много добро решение! Освен, че получаваш пълен брой точки, ти давам и бонус точки за начина, по който си си направила git историята, както и за това, че предаде първа решението си :)

И малко бележки по нещата:

  • Относно 15 - това важи не само за масиви, а за всякакви обекти, които предлагат мутиращи методи -- хешове, низове и прочее.
  • Относно 17 - не само анонимните функции, но и всички обекти в Ruby могат да са елементи на масиви или стойности в хешове :)