You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's a good style in Java to keep classes immutable if possible. This prevents accidential changes and makes them thread safe by design.
The "Options" classes like "DeleteStreamOptions" are currently mutable, which is kind of unexpected. It looks like a builder, but mutates the content of the instance:
DeleteStreamOptions opts = DeleteStreamOptions.get(); // Default
opts.softDelete(); // Now soft
opts.hardDelete(); // Now hard
I would suggest to create a real builder that returns an immutable instance.
It's a good style in Java to keep classes immutable if possible. This prevents accidential changes and makes them thread safe by design.
The "Options" classes like "DeleteStreamOptions" are currently mutable, which is kind of unexpected. It looks like a builder, but mutates the content of the instance:
I would suggest to create a real builder that returns an immutable instance.
Here is a short example of how the builder pattern would look like:
https://github.com/EventStore/EventStoreDB-Client-Java/compare/trunk...michael-schnell:issue-148?diff=split
If you think this is a good idea, I can create a pull request to discuss this further in detail in the PR.
The text was updated successfully, but these errors were encountered: