Suggest modification to this talk

Title

Description

This video was recorded on http://wrocloverb.com. You should follow us at https://twitter.com/wrocloverb. See you next year!

"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.

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 titled "Refactoring Fat Models with Patterns," Bryan Helmkamp discusses the challenges posed by "fat models" in Rails applications, emphasizing the importance of adhering to the Single Responsibility Principle (SRP). He highlights that as applications evolve, complexity increases and often leads to models that become overwhelmed with responsibilities, resulting in a tangled codebase. To address these issues, Helmkamp introduces seven patterns for managing complexity in the domain layer, aiming to refactor fat models into manageable, smaller objects.

Key points discussed include:  
- **Greenfield vs. Brownfield Development**: Initially starting with ideal conditions in new projects (Greenfield) often leads to complexity and technical debt over time as requirements change.  
- **ActiveRecord Overview**: ActiveRecord simplifies adding new models and CRUD behaviors but can lead to tightly coupled domains and bloated models.  
- **Value Objects**: These encapsulated objects manage complexity by focusing on value rather than identity, allowing for better organization of code. For instance, encapsulating rating logic into a dedicated `Rating` object helps streamline functionality.  
- **Service Objects**: By encapsulating standalone operations, these objects help keep models lean and organized. For example, separating authentication logic into dedicated service objects can clarify code and reduce the complexity found in a user model.  
- **Form Objects**: Useful for handling forms that interact with multiple models, they simplify validations and state management, ensuring that users are taken through processes without directly manipulating ActiveRecord objects.  
- **Query Objects**: Enabling encapsulation of database queries, these objects prevent overly complex class methods, allowing for cleaner, more maintainable code.  
- **View Objects**: These handle the logic related to the presentation layer, which should not be intermixed with models, thereby clarifying the separation of concerns.  
- **Policy Objects**: Useful for encapsulating business rules, these objects help maintain clarity regarding the logic behind conditions like sending user notifications based on specific criteria.  
- **Decorators**: These provide the capability to enhance objects with new behaviors, such as conditionally triggering notifications while keeping the core model simpler.

Helmkamp emphasizes that while growth in complexity is inevitable, structured refactoring with these patterns can maintain manageable, effective applications without over-engineering. He concludes with reminders about using appropriate patterns to prevent unnecessary complexity in evolving software projects.

Cancel