Seperate Header and Implementation files for Interface (Abstract) Classes?

The standard rules for organizing C++ files apply.

Generally for me, I like to keep abstract classes in a header only unless it has a lot of base functionality then I'd have both .h and .cpp.

Also, if anyone has any good articles on OO design, please post them here. Thanks!

The general process for coming up with an OO design is you analyze a system as it exists in the real world then come up with the classes (objects) in it, it's collaborators & the classes responsibilities. It's extremely boring and you're better off just having fun & programming/learning as you go.

Don't want to listen to me? Then I recommend Object Oriented Design & Patterns by Cay Hortsman title. But I'm telling you, if you don't fully understand how you should be splitting your code across headers & source files, or what the difference between the two is, you aren't ready.

And save yourself some headaches, and until you fully understand the difference, always put implementations in .cpp files & definitions in .h files.

The general process for coming up with an OO design is you analyze a system as it exists in the real world then come up with the classes (objects) in it, it's collaborators & the classes responsibilities. It's extremely boring and you're better off just having fun & programming/learning as you go.[/quote]

I disagree - breaking a problem down into an OO design is something I not only find rather enjoyable, but also necessary. Maybe I'm slightly OCD but with some projects I have scrapped all my work to begin from scratch... because a poor design essentially backs you into a corner and causes more trouble than it's worth. It is potentially an interesting problem space, and in that vein, I would recommend the Gang of Four Design Patterns book. Also, please do brush up on object orientation if you're only comfortable with it "to an extent" - it is something a little too fundamental to neglect.

OOP debates notwithstanding, I would separate the implemented methods from the declaration. That's what header files are there for

If it is an interface it usually doesn't need a source file, the only function it implements will be its virtual destructor, which I would do inline.

As for articles, I like the articles on the SOLID object oriented principles from "objectmentor":

• Single Responsibility Principle
  
• Open Closed Principle
  
• Liskov Substitution Principle
  
• Interface Segregation Principle
  
• Dependancy Inversion Principle
  

The general process for coming up with an OO design is you analyze a system as it exists in the real world [...]

Anecdotally, real-world-to-OO 'translations' rarely work out that well. It's better, IMO, to seek the underlying polymorphism in a system and work your way up to a full program from there. If it turns out that the system eventually mirrors real-world entities, so be it, but I don't think it's necessarily a good starting point.