Adding new Attribute Interfaces to java-api.

[Cantor, Scott]

On 9/24/13 4:01 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

>So I had the same discussion with Chad.  That's a pretty accurate basic
>summary.  His reasoning to me was basically: if you're only ever going
>to have 1 impl of the interface, then there's no value in the additional
>complexity of interface + impl, vs just a concrete.  That's pretty much
>what it boils down to.

The issue in my mind is not if *we* will ever do this, the issue is
whether anybody else can without any changes to the IdP.

You can sometimes do this with classes, but it constrains the hierarchy of
that implementer's code, which is because of Java, it's just a limitation
of the language.

> One specific thing he asked me to do was get rid of (in his view) the
>"unnecessary" interface usage in the new messaging API, and so I did.

I don't have a problem with that so much because the extension model there
is clearly meant to be different.

I'm really talking about functional components. But that said, I can live
with it primarily because of SWF. The only code that really calls into the
resolver, filter, etc. is meant to be a flow action. So all you have to do
to replace the component outright is build a different flow action that
operates with the same input/output convention in the context tree.

Where it's not as comfortable IMHO are the various plug points inside the
resolver and filter. I still think they should be interfaces.

-- Scott