Some Rare but Invaluable Java Patterns 🧵 1) Null Object Pattern Avoid null checks by using a no-op object that implements expected behavior. It keeps code clean by avoiding conditionals around method calls (e.g., if (obj != null) everywhere). Use when returning null leads…

theskilledcoder's tweet image. Some Rare but Invaluable Java Patterns 🧵

1) Null Object Pattern

Avoid null checks by using a no-op object that implements expected behavior. 

It keeps code clean by avoiding conditionals around method calls (e.g., if (obj != null) everywhere).

Use when returning null leads…

2) Parameter Object Pattern Bundle related parameters into a single object. You can pass the parameter object around different layers, ensuring consistency. Use when methods have too many related args.

theskilledcoder's tweet image. 2) Parameter Object Pattern

Bundle related parameters into a single object. 
You can pass the parameter object around different layers, ensuring consistency.

Use when methods have too many related args.

3) Fluent Interface / Method Chaining Chain method calls for better readability. Communicates intent clearly (especially in builder-like objects). Use in builders or config-style setups.

theskilledcoder's tweet image. 3) Fluent Interface / Method Chaining

Chain method calls for better readability. 
Communicates intent clearly (especially in builder-like objects).

Use in builders or config-style setups.

4) Execute Around Method Pattern Abstract setup/teardown around an operation. Prevents resource leaks by always handling teardown properly. Use for resource management (e.g. opening/closing files/DB).

theskilledcoder's tweet image. 4) Execute Around Method Pattern

Abstract setup/teardown around an operation. 
Prevents resource leaks by always handling teardown properly.

Use for resource management (e.g. opening/closing files/DB).

5. Initialization-on-Demand Holder (a variant of Singleton) Lazy-load a singleton safely without synchronized. Use when you want performant, thread-safe singleton.

theskilledcoder's tweet image. 5. Initialization-on-Demand Holder (a variant of Singleton)

Lazy-load a singleton safely without synchronized. 

Use when you want performant, thread-safe singleton.

Use no-op objects with caution as they just pretend to be real values. But they do not. In your sample, NullPayment::pay(), does nothing but the payment processor thinks the payment is completed. It 's better to use Optionals in most of the cases...


NullPayment should be renamed to NoopPayment.


IMHO, somehow we must know if an object is null to know how we should proceed.


At line # 5, it doesn't avoid a conditional; only it is transformed, but not avoided. In certain cases, I think is necessary to check if an object is null; so, conditionals couldn't be avoided.

AbelardoIT's tweet image. At line # 5, it doesn't avoid a conditional; only it is transformed, but not avoided.
In certain cases, I think is necessary to check if an object is null; so, conditionals couldn't be avoided.

Bro... this is just hard to watch. Just use Kotlin already.


United States 趋势
Loading...

Something went wrong.


Something went wrong.