Мартина обнови решението на 19.01.2015 16:36 (преди почти 10 години)
+REPOSITORY = 'https://github.com/martaradeva/ruby-retrospective-4'
+
+# 20 неща, които научих за Ruby (и не само)
+
+# За Git
+
+# 1. Kак да разрешавам merge conflicts.
+# 2. Как да sync-вам fork през command line git
+
+# Задача 2.
+
+# 3. За да мога да chain-вам методи (метод сам на себе си), трябва методът ми да връща self.
+# 4. Наследяването на класове прави методите на родителя достъпни в детето. Методите | и & дефинирам само във Filter, като SignFilter и TypeFilter (ги) наследяват от него.
+# 5. С context 'context_name' {#block_of_tests} в RSpec можем да разделяме различните тестове според вида на функционалността, която тестват. По-удобно подреждане на резултатите. Вероятно могат и да се настройват специфични за контекста условия.
+
+# Задача 3.
+
+# 6. Открих си грешка (?) във file parse -> направила го бях да работи само за String. Сега работи за всички типове данни.
+# 7. Когато се дефинира lambda с -> параметъра се изкарва пред скобите на блока в кръгли скоби. ()
+# 8. String#delete! изтрива всичко, което match-не на параметъра, с който се извиква. от всяка част на стринга.
+# 9. Hash#merge! е начинът да добавиш нов хеш към съществуващ. Презаписва повтарящите се ключове.
+# 10. При извикване на класовите методи от контекста на самия клас името на класа може да се пропусне (self се подразбира)
+# 11. Наличие на опционални аргументи (wildcard arguments) в метод става с
+# def my_method (*args)
+# args.length > 0 #true, ако са подадени, false ако не са
+# args[0] #true ако са подадени, nil ако не са
+# args #true винаги, защото не е nil
+# end
+# 12. размисли по ООП - отделянето на някаква логика в отделен клас (модул, метод) се случва (1).когато тази логика видимо се повтаря на няколко места, или (2). когато се усетиш, че обменът на информация с останалата част от класа(модула) става през относително ясен интерфейс.
+
+# Задача 4.
+# 13. При извикването на класовите методи от контекста на самия клас self може да се пропусне и се викат направо с name_of_method(args) - т.е. с подразбиращ се получател.
+# 14. За дефинираните от мен класове е добре да си дефинирам и метод inspect или to_s, за да мога по-лесно да дебъгвам с puts.
+# 15. Добрата архитектура на една задача е ОК да се търси итеративно. Работещото решение може да се рафинира краен брой пъти, като се вдига нивото на абстракция и се подобрява структурата на кода.
Добри наблюдения! Малко бележки по тях:
- По 7. - може и без скоби, както и при другите методи, т.е.:
-> x { x * x }
или->(x) { x * x }
- По 8. и 9. - тези две версии мутират обекта, над който са извикани; обикновено се предпочитат немутиращите версии, т.е. тези без
!
в края. - По 11 - трябва да отбележа само, че
args[0]
може и да не се оцени на истина в случая наmy_method(nil)
. - Точка 13 се повтаря с т. 10.
- 14 - още по-удобно за debug е
p
(работи горе-долу така:def p(obj) { puts(obj.inspect); obj }
). - 15 - не винаги по-високо ниво на абстракция е добра идея. Абстракциите внасят усложнение.