   Good example of an OO Interface ?
  What are the rules on writing in an interface?  The reason I ask is because I'm working with the book 3D Game Engine Programming and in chapter 3 the book has code for an interface.  The author mentions the interface is not viewed by hardcore OO programmers as a correct interface.  This is because the interface contains attributes which apparently should not be defined in the abstract class.Probably a terminology thing, by attributes I'm guessing the author means the HWND m_hWndMain and similiar member variables defined as protected.  Am I right in presuming a true abstract class OO Interface should only have the public virtual functions?The author mentions he puts the member vars in this header file because it saves the derived classes from having a billion attributes?  Is this the most effecient way of going about this or should I actually declare the attributes such as DWORD m_dwHeight in the derived classes?   
  Given a class hierarchy, define members (both variables and functions) as high up in the hierarchy as it makes sense to do so. In Windows, basically every UI element has an HWND, so it makes sense to define an m_hWnd member high up the hierarchy. Conversely, most elements don't need a "get user-entered text" member function, so you would define that in a more specific derived class, like TextBox or whatever.Different people have different philosophies; there really isn't a magical rulebook that says "defining member variables in an abstract base class is Evil" or whatever. Some people think so; others (myself included) think that's a rather silly dogma. Of course, it's important to remember that every language handles OO slightly differently, and what is reasonable in one language may be really bad in another.Remember, OO design rules are there to help you arrive at a clean solution - they cannot possibly provide a clean solution in every case just by following the rules. The real hard part of design is picking the right solution - which often means picking the least bad of several poor options. However, if you find yourself making a lot of icky decisions, it is likely a symptom of a higher-level design issue.   ;  It varies from language to language, and from person to person.In Java, an abstract class can have members and functionality, whilst an interface can only have pure virtual functions (and constants). In C++, there is no language-specification for abstract classes and interfaces, there are only classes, so people have a more wishy-wash view of things. I generally take the Java approach and define interfaces as only having pure virtual functions, whilst abstract classes can have members etc. It definately helps when it comes to multiple inheritance.   ;Quote:Original post by _goatIt varies from language to language, and from person to person...I absolutely agree with _goat. A 'interface' (- class), strictly agreeing with its OO specification, does not contain any member variables, but only pure virtuals. However, I also second _goat's statement that C++ does not have explicit support for interfaces, so you would rather declare interfaces as classes and there is syntactically no difference to abstract or any other type of classes, so the implementation of interfaces with C++ can sometimes be interpreted a little bit different. Though, I think that having member variables within interfaces in C++ is sometimes quite helpful, some people argue that this would be no correct OO design, however...In C# for example the 'inteface' keyword was introduced, which defines a new interface with only function declarations allowed in its body. Java has a seperate keyword, too, as far as I remember, but I've never used Java, so I'm not 100% sure with that.   ;  Yes ideally there are no attributes in interfaces. Like that you can define the properties of an object as interfaces and the structure by using classes.In a clean OO-approach:An interface should have a name Drawable, Movable, Printable or whatever and be completely abstract.A class may use multiple interfaces but have only one class that it is derived from.C++ just does not enforce those guides as rules.What I don't get is why the author calls what he writes an interface. It seems to be a base class not an interface.   ;  As people have already mentioned in this thread, Java has a concept called an "interface" which is kind of like a pure abstract base class - only method signatures, no data, no concrete (implemented) methods. In Java, these are declared using the interface keyword instead of the class keyword.The reason for this, as far as I understand, is to do with the issues with multiple inheritence, a very hotly debated topic. Basically, multiple inheritance can cause problems under certain circumstances. However, most of those circumstances only apply if you're inheriting actual functionality from many different sources at once. If all you're inheriting is method signatures, nearly all of the problems with multiple inheritence no longer apply. That's why Java doesn't allow a class to inherit multiple classes, but it does allow a class to inherit multiple interfaces. Possibly that was what the book was referring to.   ;  Personally I like a halfway house between ApochPig and _goat. My game engine only sees the virtual abstract interface to my Item class but then at the top of the seperate unit that the different Item's are derived is a BasicItem that supplies all the common data members for game items and every other sub-Item type then derives from BasicItem.At least then if I change any of the common data members, my engine unit doesn't have to be recompiled (which is handy on a 500mhz using Borland BCC55).   