Neal Ford: Design Patterns in Ruby
Posted by Annalisa Afeltra in
Ruby on Rails -
1 comment
The room is crowded, on the screen appears the book “Design Patterns (the gang of four)’, in this book, Neal says that there are not only references but also valid examples (even if they are not expressed in Ruby)
There are two destinct problems Neal confirms, the patterns in theor theoretical exceptions and their implementation. The dynamic languages have a big advantage when it means impementing patterns in real cases.
Iterator Pattern:
Neal does not appreciate this pattern very much: little tecnical for the technical people and too technical for the non technical people. The pattern provides the ability to access in sequence an array of elements.
Neal asks: what do we need these patterns for compared to a normal iterator .each? in reality even an iterator each apply to a iterator pattern (internal).
Instead the external iterator is a version of this pattern implemented, for example in the cycle for.
Command Patterns:
The command pattern is implemented in Ruby through the blocks. Each block incapsulates a command. In reality this comparison is not 100% true, it will need some modifications to be made to tie in the command pattern to a block.
Strategy Pattern:
This pattern defines a set of algorithms, incapsulates them and makes them interchangeable. It is implemented in traditional ruby with a module that defines an empty function that is overwritten one at a time form the classes that it includes it.
But what will happen if the method in question is maybe “call” (the combination between the strategy and the command pattern)? Each algorithm will be incapsulated in a block and the array of this block shall be implemented from the strategy pattern.
Another possible implementation: to make it in a way that a class extends another dynamically. (choosing which classes should extend instances in question in a way assigned like this methods are diverse to the classes)
Interpreter Pattern:
Supply an interpreter to grammer to interpret a specific language. (JRuby for example is an example of the application in this pattern) With this pattern it is possible to construct DSL (domain specific languages). With Ruby it is very easy to construct DSL in virtue from its flexible syntax.
Adapter Pattern:
Convert an interface into another. The implementation standards in ruby, gives you two classes (round and square), to create a third that in some way transforms the instance of the object of the class A into an object of the class B.
We can dynamically create methods of instances for the instance that we want to modify. But what will happen if in this way we create a conflict of methods? We can dynamically modify the names of the methods to make it in a way that they don’t overwrite the event, then creating a kind of selector to specify each time which method we want to call between those that are available.
Sate Pattern:
Changing the class of the instance to take place a particular event. To implement this pattern we can utilize mixology, a gem that consents us to perform a mixing of modules.
Null Object Pattern:
Utilize an object that impersonates the Null concept. This pattern doesn’t exist in Ruby. It exists directly in the class language that is called NilClass.
Aridifier Pattern:
It is a pattern that is derived from the book “Programmatic Programmers” that aims to make the language more arid, in how much according to the author a language is more arid is for its nature more secure.
Conclusioni:
Neal concludes stating that Patterns are not anything but solutions valid for a common problem.
Annalisa
Comments
Website Design
Posted on June 06