This document discusses applying design patterns in Rails applications. It introduces challenges in updating an existing multi-step form to a single-step form with draft-saving capabilities. It proposes applying several design patterns including the single responsibility principle (SRP), facade, composite, and presenter patterns to address these challenges. The facade and composite patterns could be used to simplify validation handling. A presenter pattern would keep view and controller logic clean and encapsulate model-specific logic for testing. Previewing draft events may require using defaults. In conclusion, facades should not be overused and composites and presenters are preferable to helpers for certain tasks.

1. Design Patterns in Rails
A kweek case study

2. 1. Introduction to the idea
“Meet the parents”

4. Old school

5. Old School
- code smell
- design smell

6. 2. Challenge
“Meet the Fockers”

7. Challenge
- new design is a one step form vs the 3 step
on the old design
- save as draft implies no validations
- preview will suffer from the new “draft”
feature
- publish will invoke validations

8. 3. Where to start?
??

9. SRP
- Add Form - to update the model with data
- Validation “Contract” - validate the model
- Publish Facade
- Presenter - to preview the event

10. Add Form
Avdi Grimm describes form objects as boarder guards. They validate
and verify that all data coming into the system is correct.
Once the data moves past the checkpoint it is not checked again.
- a single place to handle input coercion
- virtus model
- validations

11. Facade
“The Facade Pattern is simply a formalization of the idea that if you
cannot avoid complexity, then the next best thing to do is to isolate it, to
keep it from contaminating your whole system” -- Russ Olsen
- simplifies access to the object being wrapped or the subsystem
- opposite to the decorator
- they are not meant to hide anything

12. Facade

13. Facade and Friends
- adapters exist to hide the fact that we are stuck using an object
that has the wrong interface
- a proxy stands between the user of an object and the object
itself and somehow controls access to the object
- decorators add functionality to an object

14. Validations on steroids
Remember the contract?
What if you want to validate certain contracts at a certain time?
What if you don’t want to validate a contract at a certain point?
- separate the contracts
- group them together based on your needs
- validate them…?

15. Validations on steroids
Wikipedia says : The composite pattern describes that a group of
objects is to be treated in the same way as a single instance of an object

16. Validations on steroids

17. Presenter
Bordei Cristian
- is a way to keep your view and controller logic
as clean as possible by having a Ruby class serve
as the interface between your model and the
view/controller.

18. Presenter

19. Presenter

20. Presenter vs Helper
Why not Helper you say?
- have logic specific to your models that you need encapsulated
- something you can test
- something you can extend

21. Preview event
- Saving something as a draft can
be a b***h
- To preview, you would need
defaults

22. 4. Conclusions
“Little Fockers”

23. Conclusions
- Facades are fun and easy but are not an excuse for adding
features to a subsystem
- If you want to make several types of coffee with different coffee
machines, use a composite
- Presenters make you think helpers are like a compliment that you
don't want to give, but feel obligated to: "Yeah, I mean, well, you
tried, and that's what counts, right?"

24. QUESTIONS?!