Sometimes a simple idea can have a happy ending. This is the story on how an implementation of Decorating Pattern over Collections can help you to avoid some code smells like feature envy, apply the law of Least Knowledge (Demeter law), and free your codebase of bloated objects. Test? Your suite will gain more isolation, speed and simplicity.
As in love, this will be not easy, you will find some pitfalls while trying to be 'production ready'.
This talk is aimed to encourage a better day to day approach to a higher quality on our code. I think this can be done on small pieces, one of these pieces has two foundations: implementing design patterns and test.
It's documented here and there how to Decorate an object (User being the more representative), but a few on what can we also do against collections, enumerables having their own story and their own way to work.
This will talk will cover the Decorator Pattern using SimpleDelegator, the use case will be based almost exclusively on collections, their specialization and how to test it.
Currently I have this outline:
1) Take a brief tour on why is important to care about our craft, to follow some patterns, how this can be better and not necessarily related to other languages practices (usually we tend to relate patterns with Java. I count myself as part of the group years ago)
2)Talk about what the Demeter Law and why is important, based on the article called ‘Demeter is not only a good Idea, is the law’: http://www.virtuouscode.com/2011/07/05/demeter-its-not-just-a-good-idea-its-the-law/ and the chapter ‘Minimize coupling between modules’ from The Pragmatic Programmer, which covers the Principle of Least Knowledge and the chapter ‘Design using Services’ covering the design of objects behind a well defined interface.
3)Theory on what is the SimpleDelegator, basic example against a common class as a fictitious User or Account class.
Code Session on translate business logic (based on collections) from a class to their own space and boundary using the Decorator Pattern with SimpleDelegator
4)Test the implementation.
5) Document the pitfalls on the implementation.
6)Explain how this can be reused abstracting/changing the engines (ActiveRecord, Sequel, MongoDB).
We as a developers should care about our craft, in fact is the first recommendation we got from Hunt and Thomas on the Pragmatic Programmer, but most of the time we are too busy to figure out how, just need to get the things done. We can’t fix what we did because we are too busy doing new things, new requirements, new products. Looks like a vicious cycle. I’d like to help to break that cycle.
Why is important? It has been told apply KISS. DRY. Reduce Complex. Those principles are not simple, sometimes is not repeatable, and implies more complex. The proposed pattern (Decorator) over Collections looks like a good way to go. I spent a lot of hours studying the bolt and nuts of the implementation, I found it can be good. It can be fast. Maybe not a performance enlightenment, but at the end, simple and powerful enough to make a product reliable, a code more clean and testable.
A Senior Software Engineer now applying Ruby as a daily basis, having a full conversation with datasets, collections and queries all day long. Reviewing code and learning how to debloat the unbloatable. I have been programming on many languages, like ancient xBase (Visual FoxPro), C# and Python; on every change I’ve learn not only the technology behind the language also the culture, I’ve learn how to implement what I have been using on C# and Python into Ruby.