Jump to content
  • Advertisement
Sign in to follow this  
keyforge

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

This topic is 2612 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,
I'm currently working on a project and it's using OO, which I'm comfortable with to an extent, and I'm wondering what is the best practice- to keep your abstract classes declaration and implementation in separate files (ex. IGameState.hpp, IGameState.cpp), or just keep it in the header file.

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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":

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!