Update role-object README.md #2119
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Kudos, SonarCloud Quality Gate passed!
|
iluwatar
requested changes
Nov 6, 2022
Comment on lines
+23
to
+77
| ## Applicability | ||
|
|
||
| Like other SecurityPatterns, FacetPattern can be used to improve robustness or safety, even when security per se is not an issue. It may also be useful in some cases to provide a deterministic or purely functional subset of an interface. | ||
|
|
||
| ``` java | ||
| A simple example: | ||
| // A simple Account class to which you might want to add security | ||
| interface MutableAccount { | ||
| void credit(long amount); | ||
|
|
||
| void debit(long amount); | ||
|
|
||
| } | ||
| interface ImmutableAccount { | ||
| long balance(); | ||
|
|
||
| } | ||
| class Account implements MutableAccount, ImmuatbleAccount { | ||
| void credit(long amount) { | ||
| // ... | ||
| } | ||
|
|
||
| void debit(long amount) { | ||
| // ... | ||
| } | ||
| long balance() { | ||
| // ... | ||
| } | ||
| } | ||
| // Create a Context that will determine when its appropriate to use an interface | ||
| class AccountContext extends DefaultContext { | ||
| private Permission accountModificationPermission | ||
| = new AccountPermission(…..); | ||
| public boolean validateInterface(Class interfaceClass) { | ||
| // Perform a security check before allowing any changes to an Account | ||
| if(interfaceClass.equals(MutableAccount.class)) { | ||
| // Security Check, substitute whatever you’d like to use, this uses | ||
| // a simple AccessController check for clarity | ||
| return AccessController.checkPermission(accountModificationPermission); | ||
| } | ||
| // Allow anyone immutable access | ||
| if(interfaceClass.equals(ImmutableAccount.class)) | ||
| return true; | ||
| return super.validateInterface(interfaceClass); | ||
| } | ||
| } | ||
| // Create a Facet that will control access to the Account object at runtime | ||
| Sentry sentry = new DefaultSentry(new AccountContext()); | ||
| Facet f = Facet.create(sentry, new Class[]{ImmutableAccount.class, MutableAccount.class}); | ||
| // Make sure both interfaces are supported | ||
| f = f.narrow(new Class[]{ImmutableAccount.class, MutableAccount.class}); | ||
| // Now f can be used as if it were an ImmutableAccount or ImmutableAccount, except | ||
| // that it will only delegate a method call to the real Account class when the | ||
| // correct permission is available. | ||
| ``` |
There was a problem hiding this comment.
I think this would better fit the explanation section
Comment on lines
+86
to
+90
| * Adapter Pattern | ||
| * Facade Pattern | ||
| * Proxy/Surrogate Pattern | ||
| * Handle Body Pattern | ||
| * Decorator/Wrapper Pattern |
There was a problem hiding this comment.
Add links to https://java-design-patterns.com website
| @@ -0,0 +1,17 @@ | |||
| package main; | |||
|
|
|||
| public interface Context { | |||
There was a problem hiding this comment.
Add JavaDoc explaining the purpose of the interface
| @@ -0,0 +1,56 @@ | |||
| package main; | |||
|
|
|||
| public class Facet { | |||
There was a problem hiding this comment.
Add JavaDoc explaining the Facet class
| @@ -0,0 +1,96 @@ | |||
| ## Name | |||
There was a problem hiding this comment.
The readme is missing the yaml frontmatter. See https://github.com/iluwatar/java-design-patterns/wiki/01.-How-to-contribute for the requirements
Comment on lines
+13
to
+17
| ## Explanation | ||
|
|
||
| Facets are used as a security pattern in CapabilityOrientedProgramming, in order to satisfy the PrincipleOfLeastAuthority. For example, if some client of an object only needs to be able to read information from it, that client should be provided with a read-only facet. | ||
|
|
||
| The facet interface is always a subset of the original interface, and the purpose is to restrict authority rather than to translate between incompatible interfaces. |
There was a problem hiding this comment.
The explanation needs to be refined accoring to https://github.com/iluwatar/java-design-patterns/wiki/02.-Pattern-template. See the other patterns for examples how it should be written.
Comment on lines
+23
to
+42
| ## Explanation | ||
| An object-oriented system is typically based on a set of key abstractions. Each key abstraction is modeled by a corresponding class in terms of abstract state and behavior. This usually works fine for the design of smaller applications. However, once we want to scale up the system into an integrated suite of applications, we have to deal with different clients that need context-specific views on our key abstractions. | ||
|
|
||
| Suppose we are developing software support for the bank’s investment department. One of the key abstractions to be expressed is the concept of customer. Thus, our design model will include a Customer class. The class interface provides operations to manage properties like the customer’s name, address, savings and deposit accounts. | ||
|
|
||
| Let’s assume that the bank’s loan department also needs software support. It seems our class design is inadequate to deal with a customer acting as borrower. Obviously, we must provide further implementation state and operations to manage the customer’s loan accounts, credits, and securities. | ||
|
|
||
| Integrating several context-specific views in the same class will most likely lead to key abstractions with bloated interfaces. Such interfaces are difficult to understand and hard to maintain. Unanticipated changes cannot be handled gracefully and will trigger lots of recompilation. Changes to a client-specific part of the class interface are likely to affect clients in other subsystems or applications as well. | ||
|
|
||
| A simple solution might be to extend the Customer class by adding new Borrower and Investor subclasses which capture the borrower-specific and investor-specific aspects respectively. From an object identity point of view, subclassing implies that two objects of different subclasses are not identical. Thus, a customer acting both as investor and as borrower is represented by two different objects with distinct identities. Identity can only be simulated by an additional mechanism. If two objects are meant to be identical, their inherited attributes must constantly be checked for consistency. However, we will inevitably run into problems in case of polymorphic searches, for example when we want to make up the list of all customers in the system. The same Customer object will appear repeatedly unless we take care of eliminating “duplicates”. | ||
|
|
||
| The Role Object pattern suggests modeling 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 Customer object. | ||
|
|
||
|  | ||
|
|
||
| A key abstraction such as Customer is defined as an abstract superclass. It serves as a pure interface which does not define any implementation state. The Customer class specifies operations to handle a customer’s address and accounts, and defines a minimal protocol for managing roles. The CustomerCore subclass implements the Customer interface. The common superclass for customer-specific roles is provided by CustomerRole, which also supports the Customer interface. The CustomerRole class is abstract and not meant to be instantiated. Concrete subclasses of CustomerRole, for example Borrower or Investor, 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. It defines additional operations to manage the customer’s credits and securities. Similarly, the Investor 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 object plays the role of Borrower. To this end it calls hasRole() with a suitable role specification. For the purpose of our example, let’s assume we can name roles with a simple string. If the 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. |
There was a problem hiding this comment.
Please follow the https://github.com/iluwatar/java-design-patterns/wiki/02.-Pattern-template requirements. There is a specific format that the explanation needs to follow.
Additionally, this really should be in its own pull request since it's a separate issue.
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
stale
bot
added
the
status: stale
|
Closed due to inactivity. Thank you for your contributions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request title
Update role-object README.md and finished the explanation of role-object pattern for issue #590
Implemented Facet Pattern for issue #88
Pull request description
Add an Explanation section to give some practical examples of role-object pattern.
Update Class Diagrams, Applicability and Credits.
Finish the implementation of Facet pattern