@ -36,25 +36,26 @@ import static com.iluwatar.roleobject.Role.*;
* 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 Customer object.
* The common superclass for customer-specific roles is provided by CustomerRole,
* which also supports the Customer interface.
* 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 CustomerRole class is abstract and not meant to be instantiated.
* Concrete subclasses of CustomerRole, for example Borrower or Investor,
* 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 Borrower class defines the context-specific view of Customer objects as needed by the loan department.
* 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 Investor class adds operations specific
* 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 CustomerCore class, using the interface class
* Customer, or with objects of concrete CustomerRole subclasses. Suppose the loan application knows a particular
* Customer instance through its Customer interface. The loan application may want to check whether the Customer
* 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 hasRole() with a suitable role specification. For the purpose of
* 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 Customer object can play the role named “Borrower,” the loan application will ask it to return a reference to the corresponding object.
* 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 {