Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
"Fat models" cause maintenance issues in large apps. Only incrementally better than cluttering controllers with domain logic, they usually represent a failure to apply the Single Responsibility Principle (SRP). "Anything related to what a user does" is not a single responsibility. Early on, SRP is easier to apply. ActiveRecord classes handle persistence, associations and not much else. But bit-by-bit, they grow. Objects that are inherently responsible for persistence become the de facto owner of all business logic as well. And a year or two later you have a User class with over 500 lines of code, and hundreds of methods in it's public interface. Callback hell ensues. This talk will explore patterns to smoothly deal with increasing intrinsic complexity (read: features!) of your application. Transform fat models into a coordinated set of small, encapsulated objects working together in a veritable symphony. Help us caption & translate this video! http://amara.org/v/FGdK/
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In the presentation "Refactoring Fat Models with Patterns," Bryan Helmkamp discusses the issues caused by "fat models" in Ruby on Rails applications, which violate the Single Responsibility Principle (SRP). As applications grow, models can accumulate excessive complexity, leading to maintenance challenges. This talk highlights patterns to effectively manage this complexity and emphasizes moving towards smaller, encapsulated objects instead of large, unwieldy ones. Key points discussed in the talk include: - **Greenfield vs. Brownfield Applications**: Helmkamp starts by contrasting the ideal state of a greenfield application, where developers can work without legacy issues, with the challenges of brownfield applications, where developers often feel bogged down by legacy code. - **Active Record Pattern**: The presentation explains how the Active Record pattern, while beneficial for simplicity, leads to tightly coupled models which may grow too complex as additional behaviors and requirements are added. - **Fat vs. Skinny Models**: Helmkamp advocates for the concepts of skinny controllers and skinny models, promoting a structure where both controllers and models maintain clarity and limited responsibilities. ### Patterns Introduced: 1. **Value Objects**: Immutable objects focused on a value rather than identity, simplifying code and behavior management. 2. **Service Objects**: Standalone objects representing operations, which reduce the complexity in models. 3. **Form Objects**: Manage multiple models through one form, providing a clean way to validate complex user inputs. 4. **Query Objects**: Encapsulate specific database queries, separating SQL logic from the ActiveRecord models. 5. **View Objects**: Facilitate the display logic related to views, maintaining clarity and separation from the model layer. 6. **Policy Objects**: Focused on encapsulating business rules, enabling easier compliance with notifications and permissions. 7. **Decorators**: Provide additional behavior to objects without altering the core functionality; useful for cases where behavior is conditional. Helmkamp emphasizes using these patterns judiciously; introducing them at the right time can prevent backend chaos while ensuring the application remains manageable. The talk concludes with a reminder that incremental design improvements are crucial to keep pace with application complexity, aligning the architectural evolution with feature growth. In summary, the takeaway from Helmkamp's talk is to refactor fat models into coordinated sets of responsibility-limited objects, which leads to a cleaner, more maintainable codebase. By adopting patterns such as value objects, service objects, and others, developers can effectively manage the increasing complexity of Rails applications.
Suggest modifications
Cancel
