This post advocates for using Ruby's built-in features, specifically Struct, to create value objects. It argues against using gems like Virtus or hand-rolling complex classes, emphasizing simplicity and performance. The author demonstrates how Struct provides concise syntax for defining immutable attributes, automatic equality comparisons based on attribute values, and a convenient way to represent data structures focused on holding values rather than behavior. This approach aligns with Ruby's philosophy of minimizing boilerplate and leveraging existing tools for common patterns. By using Struct, developers can create lightweight, efficient value objects without sacrificing readability or conciseness.
This blog post by Allaboutcoding details the preferred, or idiomatic, method for creating Value Objects within the Ruby programming language. It begins by defining Value Objects, explaining that they represent concepts based on their data, not their identity. Two Value Objects with the same data are considered equal, regardless of whether they are the same instance in memory. This contrasts with Entities, which are defined by their identity. The post uses the example of a Money object: $5 is $5, regardless of the specific bills or coins representing it.
The article then outlines the traditional approach for creating Value Objects in Ruby, which involves overriding the == method to compare attributes. This approach, while functional, can become cumbersome when multiple attributes are involved, leading to repetitive and potentially error-prone code.
The post then introduces the recommended idiomatic approach using the Struct class. Struct provides a concise way to define classes with predefined accessor methods for the specified attributes. By inheriting from Struct, one can easily create a Value Object with automatic attribute readers and a built-in implementation of equality based on attribute values. This significantly simplifies the creation of Value Objects and reduces the amount of boilerplate code required.
The post demonstrates this with the Money example, showing how a Money Value Object can be concisely defined using Struct.new(:amount, :currency). It further explains that this method inherently provides the desired equality comparison based on the amount and currency attributes.
The author then highlights the advantages of using Struct for Value Objects. These include improved code readability and maintainability due to its brevity, automatic generation of accessor methods, and the built-in, correct implementation of equality comparison, which eliminates the need for manual overriding of the == method and reduces the risk of introducing errors.
Finally, the post concludes by reiterating that the use of Struct is the recommended and idiomatic way to create Value Objects in Ruby, encouraging readers to adopt this approach for its conciseness and built-in functionalities that perfectly align with the requirements of Value Objects. It emphasizes that this method simplifies the process and makes the code easier to understand and maintain.
Summary of Comments ( 2 )
https://news.ycombinator.com/item?id=43421324
HN commenters largely criticized the article for misusing or misunderstanding the term "value object." They argued that true value objects are defined by their attributes and compared by value, not identity, using examples like
5 == 5even if they are different instances of the integer5. They pointed out that the author's use ofComparableand overriding==based on specific attributes leaned more towards a Data Transfer Object (DTO) or a record. Some questioned the practical value of the approach presented, suggesting simpler alternatives like using structs or plain Ruby objects with attribute readers. A few commenters offered different ways to implement proper value objects in Ruby, including using theValuesgem and leveraging immutable data structures.The Hacker News post titled "How to create value objects in Ruby – the idiomatic way" has generated several comments discussing various aspects of value objects in Ruby and alternative approaches.
One commenter points out that using
Structfor value objects can be problematic when dealing with inheritance, particularly when attributes are added to subclasses. They suggest usingData.defineas a potential solution to this issue, as it creates immutable objects by default. This commenter also mentions that theComparablemodule provides a more concise way to define equality and comparison methods based on the value object's attributes. They provide a code example illustrating this approach.Another commenter questions the necessity of the article's approach, suggesting that a simple class with an initialize method and attribute readers would suffice in many cases. They argue against over-engineering simple value objects, emphasizing the importance of readability and maintainability. This commenter also raises the potential for performance implications when using modules like
Comparable, suggesting benchmarking to determine the actual impact.A different user focuses on the use of
::newin the original article's example, explaining that it's not required and is likely a stylistic choice. They point out that using just.newwould be the more common and concise approach in Ruby.The conversation then shifts towards a discussion of the benefits and drawbacks of using
Structversus defining a custom class. One commenter highlights thatStructcan be handy for quick prototyping or when the value object is extremely simple. However, they acknowledge the limitations ofStruct, such as difficulties with inheritance and the inability to easily add custom methods. Another commenter mentions usingOpenStructas an alternative, but acknowledges its own set of trade-offs, particularly regarding performance.Finally, a commenter draws attention to the
dry-structgem from thedry-rbecosystem, advocating for its use in creating more robust and feature-rich value objects. They specifically mention the gem's ability to handle type coercion and validation, making it a suitable option for more complex scenarios. Another comment chimes in endorsingdry-structand adding that using it is generally superior to relying onStruct. They mentiondry-struct's ability to specify types, which aids in catching errors early.