tiennm99/java-design-patterns
1
0
Fork 0
mirror of https://github.com/tiennm99/java-design-patterns.git synced 2026-05-15 03:01:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Java 11 migrate remaining q-r (#1121)

Browse Source 
* Moves queue-load-leveling to Java 11

* Moves reactor to Java 11

* Moves reader-writer-lock to Java 11

* Moves repository to Java 11

* Moves resource-acquisition-is-initialization to Java 11

* Moves retry to Java 11

* Moves role-object to Java 11
This commit is contained in:
Anurag Agarwal
2020-01-04 22:13:12 +05:30
committed by Ilkka Seppälä
parent cd2a2e7711
commit 20ea465b7f
52 changed files with 424 additions and 554 deletions
Download Patch File Download Diff File Expand all files Collapse all files
role-object/src/main/java/com/iluwatar/roleobject/ApplicationRoleObject.java
+26 -32
View File
@@ -30,37 +30,31 @@ import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* The Role Object pattern suggests to model context-specific views
* of an object as separate role objects which are
* dynamically attached to and removed from the core object.
* We call the resulting composite object structure,
* consisting of the core and its role objects, a subject.
* A subject often plays several roles and the same role is likely to
* be played by different subjects.
* As an example consider two different customers playing the role of borrower and
* investor, respectively. Both roles could as well be played by a single {@link Customer} object.
* The common superclass for customer-specific roles is provided by {@link CustomerRole},
* which also supports the {@link Customer} interface.
* The Role Object pattern suggests to model context-specific views of an object as separate role
* objects which are dynamically attached to and removed from the core object. We call the resulting
* composite object structure, consisting of the core and its role objects, a subject. A subject
* often plays several roles and the same role is likely to be played by different subjects. As an
* example consider two different customers playing the role of borrower and investor, respectively.
* Both roles could as well be played by a single {@link Customer} object. The common superclass for
* customer-specific roles is provided by {@link CustomerRole}, which also supports the {@link
* Customer} interface.
*
* <p>The {@link CustomerRole} class is abstract and not meant to be instantiated.
* Concrete subclasses of {@link CustomerRole}, for example {@link BorrowerRole}
* or {@link InvestorRole}, define and implement the interface for specific roles. It is only
* these subclasses which are instantiated at runtime.
* The {@link BorrowerRole} class defines the context-specific view of {@link Customer}
* objects as needed by the loan department.
* It defines additional operations to manage the customer’s
* credits and securities. Similarly, the {@link InvestorRole} class adds operations specific
* to the investment department’s view of customers.
* A client like the loan application may either work with objects of the {@link CustomerRole}
* class, using the interface class {@link Customer}, or with objects of concrete
* {@link CustomerRole} subclasses. Suppose the loan application knows a particular
* {@link Customer} instance through its {@link Customer} interface. The loan application
* may want to check whether the {@link Customer} object plays the role of Borrower.
* To this end it calls {@link Customer#hasRole(Role)} with a suitable role specification. For
* the purpose of our example, let’s assume we can name roles with enum.
* If the {@link Customer} object can play the role named “Borrower,” the loan application will
* ask it to return a reference to the corresponding object.
* The loan application may now use this reference to call Borrower-specific operations.
* Concrete subclasses of {@link CustomerRole}, for example {@link BorrowerRole} or {@link
* InvestorRole}, define and implement the interface for specific roles. It is only these subclasses
* which are instantiated at runtime. The {@link BorrowerRole} class defines the context-specific
* view of {@link Customer} objects as needed by the loan department. It defines additional
* operations to manage the customer’s credits and securities. Similarly, the {@link InvestorRole}
* class adds operations specific to the investment department’s view of customers. A client like
* the loan application may either work with objects of the {@link CustomerRole} class, using the
* interface class {@link Customer}, or with objects of concrete {@link CustomerRole} subclasses.
* Suppose the loan application knows a particular {@link Customer} instance through its {@link
* Customer} interface. The loan application may want to check whether the {@link Customer} object
* plays the role of Borrower. To this end it calls {@link Customer#hasRole(Role)} with a suitable
* role specification. For the purpose of our example, let’s assume we can name roles with enum. If
* the {@link Customer} object can play the role named “Borrower,” the loan application will ask it
* to return a reference to the corresponding object. The loan application may now use this
* reference to call Borrower-specific operations.
*/
public class ApplicationRoleObject {
@@ -72,13 +66,13 @@ public class ApplicationRoleObject {
* @param args program arguments
*/
public static void main(String[] args) {
Customer customer = Customer.newCustomer(Borrower, Investor);
var customer = Customer.newCustomer(Borrower, Investor);
logger.info(" the new customer created : {}", customer);
boolean hasBorrowerRole = customer.hasRole(Borrower);
var hasBorrowerRole = customer.hasRole(Borrower);
logger.info(" customer has a borrowed role - {}", hasBorrowerRole);
boolean hasInvestorRole = customer.hasRole(Investor);
var hasInvestorRole = customer.hasRole(Investor);
logger.info(" customer has an investor role - {}", hasInvestorRole);
customer.getRole(Investor, InvestorRole.class)