Work with abstractions instead of concrete classes.

[andreygfranca]

Expected Behavior
Hello, first of all, nice work you guys are doing,
That being said it would be very interesting to be able to expose some classes as interfaces so that we can create our own implementation and then the respective repositories would not be coupled to any concrete class (current behavior), as we would be working with abstractions. For example, the following classes could be interfaces:

• RegisteredClient
• OAuth2AuthorizationConsent
• OAuth2Authorization

Current Behavior
We have the repositories/services coupled to concrete classes instead of abstractions: OAuth2AuthorizationService, OAuth2AuthorizationConsentService, and RegisteredClientRepository.

Context
I'm implementing the domain entities with JPA, but the services and repositories are coupled with concrete classes which makes it difficult for me to extend the current behavior

[sjohnr]

@andreygfranca thanks for your interest in the project!

Please see this comment, which states:

Interfaces allow for multiple implementations but RegisteredClient is not intended to have multiple implementations. However, you'll notice that RegisteredClient has a protected constructor as well as the Builder, allowing for extension outside of the framework. At this point, I don't see more than one implementation of RegisteredClient within the framework.

Furthermore, RegisteredClient is a domain-specific model and is not intended to serve as a one-to-one mapping to an entity model. I personally don't like to mix domain model with entity model. The underlying implementation that manages the RegisteredClient ( the RegisteredClientRepository) would be responsible for mapping the domain object to an entity object suitable for the datastore, eg. JPA, Redis (key-value store), etc.

Also, see the following github gists for examples of how to do this:

• JpaOAuth2AuthorizationService
• JpaRegisteredClientRepository
• JpaOAuth2AuthorizationConsentService

We are also working on two additional efforts that you may be interested in. The above gists are being incorporated into a how-to guide. See #545 for a rough draft of the guide. Also, see #558 for discussion on supporting transformations to/from JSON, and #588 for a possible solution that could also provide support for JPA implementations.

As I don't believe it is our intention to switch these classes to interfaces, I'm going to close this issue for now. But we do appreciate the feedback, and welcome thoughts on the above links which may be of interest to you.