Posts Tagged ‘SoftwareDesign’
[DevoxxPL2022] Are Immortal Libraries Ready for Immutable Classes? • Tomasz Skowroński
At Devoxx Poland 2022, Tomasz Skowroński, a seasoned Java developer, delivered a compelling presentation exploring the readiness of Java libraries for immutable classes. With a focus on the evolving landscape of Java programming, Tomasz dissected the challenges and opportunities of adopting immutability in modern software development. His talk provided a nuanced perspective on balancing simplicity, clarity, and robustness in code design, offering practical insights for developers navigating the complexities of mutable and immutable paradigms.
The Allure and Pitfalls of Mutable Classes
Tomasz opened his discourse by highlighting the appeal of mutable classes, likening them to a “shy green boy” for their ease of use and rapid development. Mutable classes, with their familiar getters and setters, simplify coding and accelerate project timelines, making them a go-to choice for many developers. However, Tomasz cautioned that this simplicity comes at a cost. As fields and methods accumulate, mutable classes grow increasingly complex, undermining their initial clarity. The internal state becomes akin to a data structure, vulnerable to unintended modifications, which complicates maintenance and debugging. This fragility, he argued, often leads to issues like null pointer exceptions and challenges in maintaining a consistent state, particularly in large-scale systems.
The Promise of Immutability
Transitioning to immutability, Tomasz emphasized its role in fostering robust and predictable code. Immutable classes, by preventing state changes after creation, offer a safeguard against unintended modifications, making them particularly valuable in concurrent environments. He clarified that immutability extends beyond merely marking fields as final or using tools like Lombok. Instead, it requires a disciplined approach to design, ensuring objects remain unalterable. Tomasz highlighted Java records and constructor-based classes as practical tools for achieving immutability, noting their ability to streamline code while maintaining clarity. However, he acknowledged that immutability introduces complexity, requiring developers to rethink traditional approaches to state management.
Navigating Java Libraries with Immutability
A core focus of Tomasz’s presentation was the compatibility of Java libraries with immutable classes. He explored tools like Jackson for JSON deserialization, noting that while modern libraries support immutability through annotations like @ConstructorProperties, challenges persist. For instance, deserializing complex objects may require manual configuration or reliance on Lombok to reduce boilerplate. Tomasz also discussed Hibernate, where immutable entities, such as events or finalized invoices, can express domain constraints effectively. By using the @Immutable annotation and configuring Hibernate to throw exceptions on modification attempts, developers can enforce immutability, though direct database operations remain a potential loophole.
Practical Strategies for Immutable Design
Tomasz offered actionable strategies for integrating immutability into everyday development. He advocated for constructor-based dependency injection over field-based approaches, reducing boilerplate with tools like Lombok or Java records. For RESTful APIs, he suggested mapping query parameters to immutable DTOs, enhancing clarity and reusability. In the context of state management, Tomasz proposed modeling state transitions in immutable classes using interfaces and type-safe implementations, as illustrated by a rocket lifecycle example. This approach ensures predictable state changes without the risks associated with mutable methods. Additionally, he addressed performance concerns, arguing that the overhead of object creation in immutable designs is often overstated, particularly in web-based systems where network latency dominates.
Testing and Tooling Considerations
Testing immutable classes presents unique challenges, particularly with tools like Mockito. Tomasz noted that while Mockito supports final classes in newer versions, mocking immutable objects may indicate design flaws. Instead, he recommended creating real objects via constructors for testing, emphasizing their intentional design for construction. For developers working with legacy systems or external libraries, Tomasz advised cautious adoption of immutability, leveraging tools like Terraform for infrastructure consistency and Java’s evolving ecosystem to reduce boilerplate. His pragmatic approach underscored the importance of aligning immutability with project goals, avoiding dogmatic adherence to either mutable or immutable paradigms.
Embracing Immutability in Java’s Evolution
Concluding his talk, Tomasz positioned immutability as a cornerstone of Java’s ongoing evolution, from records to potential future enhancements like immutable collections. He urged developers to reduce mutation in their codebases and consider immutability beyond concurrency, citing benefits in caching, hashing, and overall design clarity. While acknowledging that mutable classes remain suitable for certain use cases, such as JPA entities in dynamic domains, Tomasz advocated for a mindful approach to code design, prioritizing immutability where it enhances robustness and maintainability.
Links:
[ScalaDaysNewYork2016] Domain-Driven Design and Onion Architecture in Scala
Wade Waldron, a senior consultant at Lightbend and co-author of Applied Akka Patterns, presented a compelling case for combining Domain-Driven Design (DDD) and Onion Architecture at Scala Days New York 2016. Using the relatable example of frying an egg, Wade illustrated how these methodologies enhance code clarity, maintainability, and portability, leveraging Scala’s expressive features to model complex domains effectively.
Defining the Core Domain
Wade Waldron introduced DDD as a methodology that prioritizes the core domain—the sphere of knowledge central to a system—over peripheral concerns like user interfaces or databases. Using the egg-frying case study, Wade demonstrated how Scala’s case classes and traits enable rapid prototyping of domain models, such as eggs, frying pans, and cooking processes. By focusing on domain rules rather than technology, developers can create stable, reusable code. Wade emphasized that DDD does not require CQRS or event sourcing, though these patterns complement it, allowing flexibility in implementation.
Leveraging Onion Architecture
Onion Architecture, Wade explained, organizes code into concentric layers, with the domain model at the core and infrastructure, like databases, at the outer layers. This structure ensures portability by isolating the domain from external dependencies. In the egg-frying example, repositories and services abstract interactions with external systems, allowing seamless swaps of databases or APIs without altering the core logic. Wade showcased how Scala’s concise syntax supports this layering, enabling developers to maintain clean package structures and focus on business logic.
Enhancing Portability and Testability
A key benefit of combining DDD with Onion Architecture, as Wade highlighted, is the ability to refactor implementations without impacting consumers. By defining clear APIs and using repositories, developers can switch databases or rewrite domain models transparently. Wade shared real-world examples where his team performed live migrations and database swaps unnoticed by users, thanks to the abstraction layers. This approach also simplifies testing, as in-memory repositories can mimic real data stores, enhancing test efficiency and reliability.
Engaging Stakeholders with Domain Language
Wade stressed the importance of using a ubiquitous language in DDD to align developers and stakeholders. In the egg-frying scenario, terms like “fry” and “cook” bridge technical and non-technical discussions, ensuring clarity. However, Wade acknowledged challenges in large organizations where stakeholders may focus on technical details. He advised persistently steering conversations back to the domain level, fostering a shared understanding that drives effective collaboration and reduces miscommunication.