mirror of
https://github.com/tiennm99/java-design-patterns.git
synced 2026-05-14 20:58:35 +00:00
k1w1dev
ef42e169b9
* Remove unused member which was also causing a false positive sonar issue. Fixes sonar issue https://sonarcloud.io/project/issues?open=AY3gHwu5DIZTZkppqVEG&id=iluwatar_java-design-patterns * Fixes sonar issue https://sonarcloud.io/project/issues?open=AXK0OzDA-CiGJS70dLki&id=iluwatar_java-design-patterns related to "Refactor the code of the lambda to not have multiple invocations throwing the same checked exception." Also, updated the code to use Instant and Duration to deal with time instead of int. Added the awaitility library to perform assertions in test which is more reliable than using Thread.sleep directly to wait for events to happen. * checkstyle fix * Add sneaky throws to fix sonar lint issue. This is fine as the newFile method is not being tested but instead the new SimpleFileWriter(...) is. * The first booking needs to happen outside the assertions. Fixed other warnings * Use records to pass around related objects instead of using a large number of individual params, which sonar did not like. * Checkstyle fixes * checkstyle fixes * Remove complexity to keep sonar happy. * Split into different methods to reduce complexity. Could be broken down even further but currently Sonar is happy. * Move files to correct package * Add valid assertions to tests * rename constants to avoid confusion * Sonar warning related to cognitive complexity can be suppressed as the methods are quite generic and not functional enough to be separated out. * Use constants to keep Sonar happy * Use correct constant naming conventions * Use correct constant naming conventions * Use lombok to define noargsconstructor * Use a single method to do the logging * Remove unused constructor and redundant method * Use a reusable method for logging
title, category, language, tag
| title | category | language | tag | |
|---|---|---|---|---|
| Role Object | Structural | en |
|
Also known as
Post pattern, Extension Object pattern
Intent
Adapt an object to different client’s needs through transparently attached role objects, each one representing a role the object has to play in that client’s context. The object manages its role set dynamically. By representing roles as individual objects, different contexts are kept separate and system configuration is simplified.
Class diagram
Applicability
Use the Role Object pattern, if:
- You want to handle a key abstraction in different contexts and you do not want to put the resulting context specific interfaces into the same class interface.
- You want to handle the available roles dynamically so that they can be attached and removed on demand, that is at runtime, rather than fixing them statically at compile-time.
- You want to treat the extensions transparently and need to preserve the logical object identity of the resultingobject conglomerate.
- You want to keep role/client pairs independent from each other so that changes to a role do not affect clients that are not interested in that role.