ConcordionBuilder v ConcordionExtender

[Tim Wright]

Hi everyone,

I just noticed that we have an interface ConcordionExtender interface that contains some of the methods of ConcordionBuilder - but not all of them. ConcordionBuilder is the only implementation of ConcordionExtender in our repository (others might implement it).

I was wondering what our design guidelines are for when we put methods into the ConcordionExtender class and when we don't? Or do we need some guidelines?

Tim

--

Tim

021 251 5593

http://www.linkedin.com/in/drtimwright 

[Nigel Charman]

Hi Tim

On 26/02/16 18:19, Tim Wright wrote:

I just noticed that we have an interface ConcordionExtender interface that contains some of the methods of ConcordionBuilder - but not all of them. ConcordionBuilder is the only implementation of ConcordionExtender in our repository (others might implement it).

Where have you been ;) ConcordionExtender is the key interface exposed for extensions to hook into Concordion.

I was wondering what our design guidelines are for when we put methods into the ConcordionExtender class and when we don't? Or do we need some guidelines?

The guidelines are to add methods into ConcordionExtender if they are likely to be used by extensions. However, if the methods are only likely to be used by classes that directly call ConcordionBuilder (eg. custom runners, .NET runner), then we shouldn't add them to ConcordionExtender since we want to keep the API as small and manageable as possible.

Is that enough of a guideline, or are there points we should elaborate further. Once the guidelines are agreed, we should add as a comment to ConcordionExtender - possibly even with a link to the Github issues page if users want additional methods added?

Nigel.