Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36395 > unrolled thread

Reuse naming *Provider in other classes

Back to article view | Back to comp.lang.java.programmer

Contents

  Reuse naming *Provider in other classes mike <mikaelpetterson@hotmail.com> - 2017-03-10 04:24 -0800
    Re: Reuse naming *Provider in other classes Andreas Leitgeb <avl@logic.at> - 2017-03-10 12:37 +0000
      Re: Reuse naming *Provider in other classes mike <mikaelpetterson@hotmail.com> - 2017-03-10 05:29 -0800
    Re:Reuse naming *Provider in other classes omegajunior <omegajunior@protonmail.com> - 2017-04-03 23:21 -0400
      Re: Reuse naming *Provider in other classes lewbloch@gmail.com - 2017-04-06 02:44 -0700

#36395 — Reuse naming *Provider in other classes

Hi,

We have XXProvider,YYYProvider interfaces in our application. They all extend the same interface called Provider that extends interface A.

Now we have another interface B that provides functionality but it cannot extend class A.


These are the option I can come up with:

1. Still call it BProvider but not extend Provider
2. Use other naming, BSupplier 


Comments? Other options?

br,

//mike

[toc] | [next] | [standalone]

#36396

mike <mikaelpetterson@hotmail.com> wrote:
> We have XXProvider,YYYProvider interfaces in our application.
> They all extend the same interface called Provider that extends
> interface A.
> Now we have another interface B that provides functionality
> but it cannot extend class A.
> These are the option I can come up with:
> 1. Still call it BProvider but not extend Provider
> 2. Use other naming, BSupplier 

Option 3:
Let Provider *not* implement A, and add an AProvider with the same
methods as your current Provider extending A and the new Provider.
Let XX- and YYProvider extend AProvider.

Option 4:
If too much code depends on Provider extending A, then create a 
BaseProvider interface that doesn't extend A and includes all non-A
dependent stuff of Provider, and let Provider extend BaseProvider,
A and have any A-specific methods. BProvider then extends BaseProvider 
and B. The documentation then would explain, that Provider is really
an AProvider, but ... "hysterical raisins".

Of course without seeing real code, any suggestions may or may not fit.

[toc] | [prev] | [next] | [standalone]

#36397

Den fredag 10 mars 2017 kl. 13:40:28 UTC+1 skrev Andreas Leitgeb:
> mike <mikaelpetterson@hotmail.com> wrote:
> > We have XXProvider,YYYProvider interfaces in our application.
> > They all extend the same interface called Provider that extends
> > interface A.
> > Now we have another interface B that provides functionality
> > but it cannot extend class A.
> > These are the option I can come up with:
> > 1. Still call it BProvider but not extend Provider
> > 2. Use other naming, BSupplier 
> 
> Option 3:
> Let Provider *not* implement A, and add an AProvider with the same
> methods as your current Provider extending A and the new Provider.
> Let XX- and YYProvider extend AProvider.
> 
> Option 4:
> If too much code depends on Provider extending A, then create a 
> BaseProvider interface that doesn't extend A and includes all non-A
> dependent stuff of Provider, and let Provider extend BaseProvider,
> A and have any A-specific methods. BProvider then extends BaseProvider 
> and B. The documentation then would explain, that Provider is really
> an AProvider, but ... "hysterical raisins".
> 
> Of course without seeing real code, any suggestions may or may not fit.


Input greatly appreciated!

[toc] | [prev] | [next] | [standalone]

#36427

mike <mikaelpetterson@hotmail.com> Wrote in message:
> Hi,
> 
> We have XXProvider,YYYProvider interfaces in our application. They all extend the same interface called Provider that extends interface A.
> 
> Now we have another interface B that provides functionality but it cannot extend class A.
> 
> 
> These are the option I can come up with:
> 
> 1. Still call it BProvider but not extend Provider
> 2. Use other naming, BSupplier 
> 
> 
> Comments? Other options?
> 
> br,
> 
> //mike
> 

Why is interface B unable to extend Provider? 
  
If B is more of an abstract implementation, make it an abstract
 class, implementing Provider, and have sub classes extend B.
 
  
I tend to prefix interface classes with I, and abstract ones with
 A. I've seen JDK and JRE classes suffixed Impl if they are an
 implementing sub class. 
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#36429

On Monday, April 3, 2017 at 8:22:00 PM UTC-7, omegajunior wrote:
> I tend to prefix interface classes with I, and abstract ones with
>  A. I've seen JDK and JRE classes suffixed Impl if they are an
>  implementing sub class. 

Those prefixes do not conform to the Java naming conventions. The Java API itself uses `Abstract` as a prefix for abstract classes, which has the virtue of conforming to the camel-case, compound-word convention. The suggested standard for interfaces is to use simple nouns or adjectives, like `List` or `Comparable`. Sometimes slightly more compound words are indicated, like `SortedSet`, but the names are still very type-like.

-- 
Lew

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web