Home/ Questions/Q 902795
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T15:46:31+00:00

Is it right by saying it’s common to have some interface members not implemented

  • 0

Is it right by saying it’s common to have “some” interface members not implemented for certain classes simply because in certain circumstances they don’t apply so you throw a non-implemented error in the method body?

For example lets say I create an interface IAPIAuthentication that servers as a contract for classes that will perform authentication requests to 3rd party APIs such as Facebook for example and others also that we’ll be implementing later on.

So my IAPIAuthentication Interface would have the following properties possibly:

// The URI that the auth HTTP Request will go to (minus any querystring values, this is just the base)
AuthenticationURI (property)

// unique ID for your API account with whatever API you are using (Facebook, Picasa, whatever)
ClientID  (property)

// unique secret code also obtained when you sign up for an API account and used in auth calls
ClientSecret (property)

// a confirmation code sent back from the 
AuthenticationVerificationCodeID (method)

// a boolean property set to true if an AuthenticationVerificationID was received back after an Auth request
AuthenticationWasSuccessful (property)

// sends the actual HTTP Request to the specified Uri
SendRequest()

Ok so in many cases, other APIs require the same info during their auth process (such as PhotoBucket, etc.)

Ok so I created this interface that will be used for various implementations when I create wrappers for these APIs and the whole point of this is to create some good commonality in terms of structure and reuse when I start to create features using some of the wrappers I will build off these generic Interfaces here. These are the basic building blocks for most NVP APIs so what I put in these interfaces will usually all be used no matter what API I’m implementing or at least 90% of the values in any Interface that I’m creating here.

So I will create a class for example FacebookAuth that implements that Interface. All find and dandy. Ok, next time I work on a new project I say hey, I’m going to also implement that interface keeping with the team standard/pattern for creating third party wrapper projects) and I know that I’m going to need lets say all those properties but maybe minus one or two because that provider doesn’t require that piece in information during their auth process. Lets say it’s just one that it doesn’t need.

So my question(s) are these:

  1. Is my approach making sense for the goal of reuse and consistency when I start to create all these 3rd party API wrapper projects later on?

  2. Ok in general with Interfaces as you know, you can dodge implementing a certain Interface method by just throwing at least in .NET a non implemented exception if someone tries to use that method in your subclass. I’m not sure about for properties…how you’d ignore any of them if you absolutely had to (rare one-offs). So is it “normal” to expect that your interface is never going to be “perfect” in terms that all members will always be used across the board 100%? I mean one could say only put in the elements that will be used 100%. Ok fine but it depends…because some APIs will use all in this case most of the time..just a few one-offs won’t…so to me it still makes sense to include some that may not be used in others.

I just want some input based on experience out there…developers who are much more experienced with Interfaces than I at this point. I have not used interfaces much..I get what they are (contract, yada yada) but I’m trying to figure out the best use for them and I really think this is a good use. I’ll also have Abstract classes…just a few so I know the difference between the two. I just want to know is it acceptable to have non-perfect Interfaces so to say. I guess that’s why they version APIs right? But even in an existing version you’re going to have some classes that do not fully implement ALL members of an interface but implements that interface for consistency and reuse regardless overall in your app or wrapper…

I hope I did not ramble too much. Let me know if I’m not clear. And keep in my ind my above example is not really complete but gets the point across.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It is generally not desirable to have partially implemented interfaces.

    My advice is to separate your concerns, i.e. separate your interface into several interfaces so that implementations can be complete and autonomous.

    But, there are cases where the benefit of a unified interface outweighs separation of concerns, IMHO there are very few of these, but they certainly exist. One example is in the .NET BCL, where some ICollection classes are read-only and hence do not support Add, Remove, and Clear. To avoid using exceptions for control flow, ICollection provides an IsReadOnly property to indicate that these methods are not supported.

    And if you still decide to keep a single interface for all your codes, throw NotSupportedException rather than NotImplementedException, making your choice of not implementing that operation explicit.

    • 0