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

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

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

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

Към профила на Марио Даскалов

Резултати

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

Код

REPOSITORY = 'https://github.com/hahcho/ruby-retrospective-3'
# Двадесет неща, които научих.
# 1. Използването на upto пред .. , подобрява четимоста на кода.
# 2. Използването на предикати пред обикновенни сравнения също.
# 3. map, select и т.н. могат да се chain-ват с други енумератори при нужда от
# допълнителна информация свързана с колекцията.
# 4. each_with_object удобен начин да спестим кофти конструкция от типа
# reduce({}) ... и напълни хеша с информация.
# 5. Hash има богат набор от конструктори, удовлетворяващи доста случей.
# 6. Удобен начин да подаваме аргументите си е чрез разпъване на масиви,
# също така удобен начин за прехвърляне на дани като наредени н-торки.
# 7. Struct e удобен начин да спестим малко boilerplate code.
# 8. Struct e Enumerable, лоша идея да се използва при обекти извършващи
# някакъв вид прокси дейност.
# 9. Добра практика е константите да се "замразяват" с цел лесно откриване на
# бъгове свързани с тях.
# 10.Няма смисъл да се разширява употребата на обекта повече от предвиденото.
# Пример - излишно имплементиране на <=> оператор с цел наличието на повече
# функционалност от Enumerable module при липса на адекватно сравнение за
# обекта.
# 11.Използването на operator [] върху self e изчистен начин да се взимат
# член-дани от обектите посредством символ.
# 12.Често няма смисъл от допълнителни променливи.
# 13.Предпочетане на public_send пред send
# 14.Еднотипни присвояване имаме възможност да извършваме на един ред.
# 15.Използване на alias за създаване на синоними
# 16.Мета - програмирането е интересно, но носи много лоши и трудни
# бъгове.
# 17.Научих за наличието на Object#tap.
# 18.attr_reader, attr_accessor и т.н. спестяват boilerplate.
# 19.По-ясното именуване на променливите подобрява четимоста.
# 20.При претоварване с методи на клас, разбиването на по-малки такива улеснява работата с него.

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

Марио обнови решението на 22.01.2014 17:26 (преди почти 11 години)

+REPOSITORY = 'https://github.com/hahcho/ruby-retrospective-3'
+
+# Двадесет неща, които научих.
+# 1. Използването на upto пред .. , подобрява четимоста на кода.
+# 2. Използването на предикати пред обикновенни сравнения също.
+# 3. map, select и т.н. могат да се chain-ват с други енумератори при нужда от
+# допълнителна информация свързана с колекцията.
+# 4. each_with_object удобен начин да спестим кофти конструкция от типа
+# reduce({}) ... и напълни хеша с информация.
+# 5. Hash има богат набор от конструктори, удовлетворяващи доста случей.
+# 6. Удобен начин да подаваме аргументите си е чрез разпъване на масиви,
+# също така удобен начин за прехвърляне на дани като наредени н-торки.
+# 7. Struct e удобен начин да спестим малко boilerplate code.
+# 8. Struct e Enumerable, лоша идея да се използва при обекти извършващи
+# някакъв вид прокси дейност.
+# 9. Добра практика е константите да се "замразяват" с цел лесно откриване на
+# бъгове свързани с тях.
+# 10.Няма смисъл да се разширява употребата на обекта повече от предвиденото.
+# Пример - излишно имплементиране на <=> оператор с цел наличието на повече
+# функционалност от Enumerable module при липса на адекватно сравнение за
+# обекта.
+# 11.Използването на operator [] върху self e изчистен начин да се взимат
+# член-дани от обектите посредством символ.
+# 12.Често няма смисъл от допълнителни променливи.
+# 13.Предпочетане на public_send пред send
+# 14.Еднотипни присвояване имаме възможност да извършваме на един ред.
+# 15.Използване на alias за създаване на синоними
+# 16.Мета - програмирането е интересно, но носи много лоши и трудни
+# бъгове.
+# 17.Научих за наличието на Object#tap.
+# 18.

Марио обнови решението на 22.01.2014 17:29 (преди почти 11 години)

REPOSITORY = 'https://github.com/hahcho/ruby-retrospective-3'
# Двадесет неща, които научих.
# 1. Използването на upto пред .. , подобрява четимоста на кода.
# 2. Използването на предикати пред обикновенни сравнения също.
# 3. map, select и т.н. могат да се chain-ват с други енумератори при нужда от
# допълнителна информация свързана с колекцията.
# 4. each_with_object удобен начин да спестим кофти конструкция от типа
# reduce({}) ... и напълни хеша с информация.
# 5. Hash има богат набор от конструктори, удовлетворяващи доста случей.
# 6. Удобен начин да подаваме аргументите си е чрез разпъване на масиви,
# също така удобен начин за прехвърляне на дани като наредени н-торки.
# 7. Struct e удобен начин да спестим малко boilerplate code.
# 8. Struct e Enumerable, лоша идея да се използва при обекти извършващи
# някакъв вид прокси дейност.
# 9. Добра практика е константите да се "замразяват" с цел лесно откриване на
# бъгове свързани с тях.
# 10.Няма смисъл да се разширява употребата на обекта повече от предвиденото.
# Пример - излишно имплементиране на <=> оператор с цел наличието на повече
# функционалност от Enumerable module при липса на адекватно сравнение за
# обекта.
# 11.Използването на operator [] върху self e изчистен начин да се взимат
# член-дани от обектите посредством символ.
# 12.Често няма смисъл от допълнителни променливи.
# 13.Предпочетане на public_send пред send
# 14.Еднотипни присвояване имаме възможност да извършваме на един ред.
# 15.Използване на alias за създаване на синоними
# 16.Мета - програмирането е интересно, но носи много лоши и трудни
# бъгове.
# 17.Научих за наличието на Object#tap.
-# 18.
+# 18.attr_reader, attr_accessor и т.н. спестяват boilerplate.
+# 19.По-ясното именуване на променливите подобрява четимоста.
+# 20.При претоварване с методи на клас, разбиването на по-малки такива улеснява работата с него.

Решенията ти са прилични.

Имам следните бележки по нещата, написани от теб тук:

  • По т. 1 бих добавил "в определени случаи, например при итерация." Но не винаги.
  • По т. 5 - "случаи", а не "случей" :)
  • По т. 7 - принципно, не съм голям фен на създаването на Struct и наследяването от него, вместо да се опишат атрибутите с attr*. Намирам attr* за по-прост и разбираем вариант. Struct има смисъл, когато нямаме клас. Още повече, както казваш в т. 8, добавя често ненужни за класа неща (като енумерация по атрибутите). Реферирам към т. 10, написана от теб :)

Ще се въздържа от бонус точки, защото имаш твръде много изядени букви и правописни грешки в тези 30 реда текст... :) Иначе се надявам да си доволен от наученото.