Fun with interfaces.



  • While working on a winforms project that has forms that need to know if they have changes I was considering how to implement it. I thought back to other projects I'd seen with methods like IsDirty() which would return a bool if the form had unsaved changes. Well I decided to create an interface to implement it and I was trying to come up with what to call it. Like interfaces are supposed to be I prefixed it with "I" and called it "ICanHaveChanges". After looking at that name I decided "CanHaveChanges" isn't accurate and decided since this interface will have the "IsDirty" method I decided with the interface as declared below.

     interface ICanBeDirty
    {

    }

     It wasn't until I looked back at what I had just typed that I couldn't help from laughing.
     



  • ICanHasChangesPls?

     



  • Ha ha, awesome. I think I'd just go with something like IUnsavedChanges, personally. :)



  • As tempting as it is to go into my whole rant against Hungarian notation, I'm just going to make this suggestion:

    interface Modifiable
    {
        boolean isModified();
    }

    No "I" needed.



  • @MattHuntington said:

    While working on a winforms project that has forms that need to know if they have changes I was considering how to implement it. I thought back to other projects I'd seen with methods like IsDirty() which would return a bool if the form had unsaved changes. Well I decided to create an interface to implement it and I was trying to come up with what to call it. Like interfaces are supposed to be I prefixed it with "I" and called it "ICanHaveChanges". After looking at that name I decided "CanHaveChanges" isn't accurate and decided since this interface will have the "IsDirty" method I decided with the interface as declared below.

     interface ICanBeDirty
    {

    }

     It wasn't until I looked back at what I had just typed that I couldn't help from laughing.
     

    How about a method titled "MakeMeDirty" in the Interface ?

     



  • [code]public Class Talk implements ... [/code]



  • @VGR said:

    As tempting as it is to go into my whole rant against Hungarian notation, I'm just going to make this suggestion:

    interface Modifiable
    {
        boolean isModified();
    }

    No "I" needed.

     Even though the "I" might have started with Hungarian notation, it remained as a standard even after todays programers abandoned that notation. Interfaces marked with I is a good practice, as they are not really classes. The C# coding standard and MS can attest to this.



  • ICanHasCheesburger.com



  • IIzInUrCodeRenaminUrVariablz



  • "Interfaces marked with I is a good practice, as they are not really classes." - pitchingchris

    In C# that you mention, methods and classes are named the same way. For that reason, I don't think the C# coding standard is very well designed. Wouldn't it be less bad to confuse classes and interfaces (ie. types) than classes and methods?

    (In any case though, as long as people follow it, it's a whole lot better than C++-esque no standards (or "a thousand standards"), and I'll follow it any day)


  • Considered Harmful

    The naming convention I see most often, and I try to follow, is: IVerbable.  So you could have something like IChangable, IDirtiable, IUpdatable, IModifiable... If you don't like the -able suffix, then you could just drop it: IChange, IDirty, IUpdate, IModify...  But verbs seem to work best with interfaces.



  • @joe.edwards@imaginuity.com said:

    The naming convention I see most often, and I try to follow, is: IVerbable.  So you could have something like IChangable, IDirtiable, IUpdatable, IModifiable... If you don't like the -able suffix, then you could just drop it: IChange, IDirty, IUpdate, IModify...  But verbs seem to work best with interfaces.

    But if your interfaces are all in the Verbable format, why do you need the I?  Wouldn't Verbable for interfaces and Noun for classes be enough?  That's the way I roll. 



  • @bstorer said:

    @joe.edwards@imaginuity.com said:

    The naming convention I see most often, and I try to follow, is: IVerbable.  So you could have something like IChangable, IDirtiable, IUpdatable, IModifiable... If you don't like the -able suffix, then you could just drop it: IChange, IDirty, IUpdate, IModify...  But verbs seem to work best with interfaces.

    But if your interfaces are all in the Verbable format, why do you need the I?  Wouldn't Verbable for interfaces and Noun for classes be enough?  That's the way I roll. 

    For the "interfaces" I use in a perl project, I use Interface::Verbable.

    Enterprise-Perl is the most beautiful, ugly, wonderful, horrible thing I've ever encountered.
     



  • @ahnfelt said:

    In C# that you mention, methods and classes are named the same way. For that reason, I don't think the C# coding standard is very well designed. Wouldn't it be less bad to confuse classes and interfaces (ie. types) than classes and methods?

     

    When could you ever confuse methods with classes? Isn't that always immediately obvious from the (very narrow) context? Can't really think of a good reason how a different coding standard (I guess you're thinking of e.g. using lowerCamelCase for methods and UpeerCamelCase for classes as is customary in Java) could make code more readable readable?



  • @pitchingchris said:

    Even though the "I" might have started with Hungarian notation, it remained as a standard even after todays programers abandoned that notation. Interfaces marked with I is a good practice, as they are not really classes. The C# coding standard and MS can attest to this.

    It's a horrid practice. It's completely throwing away the entire concept of abstraction.

    Hint: you use a class the same way, regardless of whether it's a class or an interface. I'm not a C# guy, I'm a Java guy, so I can only give Java examples: you don't treat a Connection differently just because it's an interface. You don't treat a PrintService differently just because it's an interface. You don't treat a Style or Document differently just because they're interfaces.

    A good, succinct argument about this is here. (I didn't write it.)

    As for the C# coding standard ... it's interesting that, except for starting interfaces with an 'I', Hungarian notation is thoroughly discouraged in all respects (including specifically proscribing starting class names with 'C').



  • @VGR said:

    Hint: you use a class the same way, regardless of whether it's a class or an interface. I'm not a C# guy, I'm a Java guy, so I can only give Java examples: you don't treat a Connection differently just because it's an interface. You don't treat a PrintService differently just because it's an interface. You don't treat a Style or Document differently just because they're interfaces.

      Connection myConnection = new Connection();

     Hey!  Why doesn't that work?  If Connection is an interface and you use it just like you use a class, why does it complain and say I can't create a Connection?

     



  • @VGR said:

    Hungarian notation is thoroughly discouraged in all respects (including specifically proscribing starting class names with 'C').

    @newfweiler said:
    Connection myConnection = new Connection();

    oh snap! 



  • @newfweiler said:

    @VGR said:

    Hint: you use a class the same way, regardless of whether it's a class or an interface. I'm not a C# guy, I'm a Java guy, so I can only give Java examples: you don't treat a Connection differently just because it's an interface. You don't treat a PrintService differently just because it's an interface. You don't treat a Style or Document differently just because they're interfaces.

      Connection myConnection = new Connection();

     Hey!  Why doesn't that work?  If Connection is an interface and you use it just like you use a class, why does it complain and say I can't create a Connection?

    NumberFormat fmt = new NumberFormat();

    Hey! Why doesn't that work?

    Oh, you mean I'm supposed to look at the javadoc for a class before I try to use it?

    An interface is no different from a class with special constructors. For every class, you are supposed to be looking up its usage, including how to construct it. In the case of an interface, as with abstract classes and classes with non-public constructors, you follow the "see also" tags and/or you follow the Use hyperlink at the top.



  • @VGR said:

    @pitchingchris said:

    Even though the "I" might have started with Hungarian notation, it remained as a standard even after todays programers abandoned that notation. Interfaces marked with I is a good practice, as they are not really classes. The C# coding standard and MS can attest to this.

    It's a horrid practice. It's completely throwing away the entire concept of abstraction.

    Hint: you use a class the same way, regardless of whether it's a class or an interface. I'm not a C# guy, I'm a Java guy, so I can only give Java examples: you don't treat a Connection differently just because it's an interface. You don't treat a PrintService differently just because it's an interface. You don't treat a Style or Document differently just because they're interfaces.

    A good, succinct argument about this is here. (I didn't write it.)

    As for the C# coding standard ... it's interesting that, except for starting interfaces with an 'I', Hungarian notation is thoroughly discouraged in all respects (including specifically proscribing starting class names with 'C').

    I'm a C# guy and you DO use a class/interface differently when working with java, can you show me the code to implement an interface and the code to inherit a class.

    In C# it's like this:

    public class MyStream : Stream, IDisposable 



  • public class Lolrus implements IHasABucket



  • An interface is most certainly not the same as a class, in either form or function.

    First of all, a class can only inherit from one class, but it may implement several interfaces. Second, inheriting from a class automatically inherits all of its functionality, whereas implementing an interface simply allows a class to be cast to that interface. Implementing IComparable tells the compiler, "See below for how to compare two instances of this class", not "add the functionality for comparing class instances". More succinctly, inheritance defines what a class is, while interface implementation defines what a class can do.

    When I see that a class implements IDisposable, that means to me that it uses native resources for which I must be aware of the lifetimes. On the other hand, when I see that a class inherits from Control, it tells me only that it is a windows/web control that can be placed on a form (I may still have no idea what it actually does).

    So to say that it is throwing away the concept of abstraction to differentiate classes and interfaces, is wrong. The reason we differentiate them is because they are different kinds of abstractions. I have to know when I see IDispatch that I'm actually required to write the automation code myself - it's not something I can just slap on an object to make it automatable. This is the exact opposite of inherit from ListControl, which literally means that I *don't* have to write any of the List or Control code, just the painting and UI code.

    To the last end-user of a framework, perhaps, there may not always be a big difference (except for not being able to directly instantiate an interface). However, to anybody wishing to extend or build on that framework (and to the programmers of the app/framework itself, come enhancement time), the distinction is extremely important. And if your proposed "better" solution is for everybody to read the Javadoc, my response is that's silly, a well-designed framework such as Java or .NET should make itself as easy as possible to use without reading the documentation, since that is always a drain on developer time.<hints id="hah_hints"></hints>



  • @Aaron said:

    An interface is most certainly not the same as a class, in either form or function.

    First of all, a class can only inherit from one class, but it may implement several interfaces. Second, inheriting from a class automatically inherits all of its functionality, whereas implementing an interface simply allows a class to be cast to that interface. Implementing IComparable tells the compiler, "See below for how to compare two instances of this class", not "add the functionality for comparing class instances". More succinctly, inheritance defines what a class is, while interface implementation defines what a class can do.

    When I see that a class implements IDisposable, that means to me that it uses native resources for which I must be aware of the lifetimes. On the other hand, when I see that a class inherits from Control, it tells me only that it is a windows/web control that can be placed on a form (I may still have no idea what it actually does).

    So to say that it is throwing away the concept of abstraction to differentiate classes and interfaces, is wrong. The reason we differentiate them is because they are different kinds of abstractions. I have to know when I see IDispatch that I'm actually required to write the automation code myself - it's not something I can just slap on an object to make it automatable. This is the exact opposite of inherit from ListControl, which literally means that I don't have to write any of the List or Control code, just the painting and UI code.

    To the last end-user of a framework, perhaps, there may not always be a big difference (except for not being able to directly instantiate an interface). However, to anybody wishing to extend or build on that framework (and to the programmers of the app/framework itself, come enhancement time), the distinction is extremely important. And if your proposed "better" solution is for everybody to read the Javadoc, my response is that's silly, a well-designed framework such as Java or .NET should make itself as easy as possible to use without reading the documentation, since that is always a drain on developer time.<hints id="hah_hints"></hints>

    This is always hard to explain, but I'll try to explain it again anyway.

    They are different in terms of the syntax required to make use of them. They are not different kinds of abstractions. Yes, of course an interface doesn't provide actual methods. Yes, of course Java (and maybe C#?) lets you implement multiple interfaces but only allows you to inherit from one class. But if you want to speak in OO terms like "abstraction" then you ought to recognize that in both cases, your class is taking on the responsibility of honoring the contract of each class or interface. Whether it gets each contract from a superclass or from an interface is relevant to the writer of the class, obviously, because he has to implement the methods of interfaces; but it is not relevant to the users of the class. No one else should care in the least whether it's a class or an interface. Its contract is the same!

    The argument that "the 'I' lets me know it's something I can't directly construct" is pretty flimsy. If we're going to have that attitude, then we should come up with special prefix letters for all the possible construction scenarios:

    • Integer becomes SInteger, to show that it needs a string (or int) to be constructed.
    • ElementIterator becomes DElementIterator, since it needs a Document (or Element) to be constructed.
    • RoundingMode becomes ERoundingMode, since it's an enum.
    • ByteOrder becomes TByteOrder, to show that it's a typesafe enumeration (though not actually a Java enum).
    • All annotations must start with an A.
    • FileChannel becomes OFileChannel, to indicate that an instance must be obtained from an InputStream or OutputStream.

Log in to reply