Quote:Original post by Konfusius

Quote:Original post by snk_kid

Quote:Original post by ArmchairArmada
I shouldn't try to program something until I will actually need it. I need to keep this in mind.

Keep it Simple, Stupid.
Keep it Simple, Stupid.
Keep it Simple, Stupid.

QFE.

He said he ain't gonna need it. [smile]

Quote:Original post by ArmchairArmada
In my experience writing code in C++ seems to be, more than any other language, a puzzling and difficult challenge. It's not only that you have to figure out how to implement functionality but also how to make it fit into the intricately design software architecture. In C, for example, everything is basically flat and globally accessible. In C++ it seems easy to wind up in a situation where what you need is locked away where you can't use it.

To complicate matters more I have read many comments on various programming practices which should be avoided (perhaps rightfully so), but it is not always entirely clear what better alternatives should be used.

I'm having a hard time picturing what good OOP looks like. Individual classes and objects are simple enough, but what about the whole grand overall structure of the software? If both singletons and globals should be avoided, what would be the best way of having access to functionality from anywhere it might be needed? Is everything that is needed suppose to be passed down the chain of function calls? I don't know.

I would like to hear a little from experienced C++ programmers their philosophies on designing software. What does the overall structure of a well designed game look like? How do the systems interact with each other?

I know a reasonable amount about C++ the language, but I find I often paint myself into corners when it comes to the overall structure of software projects. Can anybody offer any advice on how to write well designed C++ source code? What principles should be kept in mind while programming? What guidelines should be followed?

Thanks.

Honestly, no replies written to this one thread are going to leave you understanding large scale OOP architecture. It takes years of practice, making mistakes, finding what works.. until you are able to kind of just 'feel' it out.. just like any other hard to learn skill in life.. and even once you get the hang of it, you still eventually realize how much you used to suck...

I'd suggest forgetting about complicated solutions and start small... start with a smaller project and expand on it making it bigger, refactoring as you go along.. and eventually you will get the hang of it.. The best OOP code is short & sweet & easy to read...

just my 2 cents, didn't read through everyone elses replies so sorry if I repeated someone else..

When I first encountered all these "object-oriented principles" like SRP, etc., I was looking for a single place where they were all documented for my reference. There is a single book that pieces all of this together, with case studies and example code along the way:

Agile Principles, Patterns, and Practices in C# by Robert C. Martin, Micah Martin.

This single book will guide you through the object oriented design principles and why they matter. It will also guide you through good unit testing practices that will help you write correct code quicker. It will also introduce you to some design patterns. All of these ideas work well together, although you could tackle them in isolation. I feel the ideas work better when used together, however. The book's example code is in C#, but don't let that put you off. Very little in the book is language specific and C# is close enough to C++ that you should have very little trouble. Just think "class containing only pure virtual methods" when they say "interface".

Clean Code by the same author is also a good read which discusses these principles in how they fit into writing easy to read and maintain code. It uses Java and has some java specific stuff, but overall the book translates well into any OOP enabled language.