We had the opportunity to talk to @sandimetz at the last meeting at @ruby_gdl. She is without a doubt, an inspiring person for all of us that work as developers in all kind of projects.
We gathered some interesting questions from people in the group and we talked about a few of those with Sandi.
Here is a link to see all the questions
The link for the Google Hangout is here so you can check it together with the questions below:
Writing a book will change your life – Sandi Metz
Is there any scenario where you would prefer using other programming paradigm different than OO?
….I’m not really the best person to answer that question because I always found that OOP has helped to solve the software problems that I faced…
When is best time to use Modules in Ruby? to share abstract code in composition or just to separate the behavior for a given domain?
…don’t use them to pretend that your class is smaller than it is, basically if you have a set of feature that needs to be shared across different classes, then that’s the very best scenario
What exercises do you recommend for practicing OO principles
Is hard to tell, since I never really did any, but I tried exercism.io by Katrina Owen… reading some books like refactoring to patterns (Book example) or http://designpatternsinruby.com/
…write code, lots of code. Talk to people about the code your wrote…
When a method in a class contains “super” is this a common symptom to refactor or abstract to template design pattern?
...as long as you have one level hierarchy is ok to avoid calling super using the template pattern design…
…you gotta pay attention when you have to leave it, and don’t let it be a terrible habit…
Additional to TRUE, DRY and SOLID what are additional attributes, practices or principles that good OOD should consider?
…what else can be added to that list? perhaps patterns? authors of GOOS book http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627
Principles of the Goos Book:
- Loosely coupled
- Highly cohesive
- Eassily composable
- Context independent
Design good OO is not easy. It’s like writing good poetry. But an additional big problem is the communication/understanding gap between the domain experts and the developers. The most expansive liability is to build the wrong thing.
What is your advice regarding how to bridge this gap?
…is inevitable that people that wants you to write software gets misunderstood…
…assume that you misunderstood each other, write the code to resolve what is misunderstood as soon as possible…
…make domain experts watch the end users use your software in small increments so you can have smaller gaps…
Do you think ruby will endure beyond web development?
...dev ops in ruby, chef-puppet thing, is a good example of people doing things with outside of web development…
…write a lof of code and tell to your friends about it…
Another book recommendation Design Patterns
And of course here book about Ruby: Practical Object Oriented Design in Ruby