Good quality Object orientated programming?
Where can I find examples of good object orientated programming? and in general how to go about designing programmers?
Well, in general, when you look at any OO code, there are the following possibilities:
1. You understand the code
1A. it's simple to comprehend and it works, and is a good illustration of OO programming
1B. it's simple, but is actually an example of generic programming or some other paradigm
2. You don't understand the code
2A. because you don't have the technical background to understand it yet
2B. because the design pattern is too complex/baroque
if you are just starting out, 2A. is a good possibility
if you are looking at real-life code, 2B. has a good chance of happening, due to evolving specs
with a multi-paradigm language like C++, 1B. is a good possibility in real-life code
of course, you want 1A., but if you are a beginner, you need to jump back and forth between 1A. and 2A. (studying to understand 2A.)
years ago, when C++ just came out, there were very few resources for good examples of OO - so few, in fact, that I went to Smalltalk first, before coming back to C++, which helped tremendously
these days, you can find plenty of examples through googling - but make sure you practice while doing it
imho, it's extremely difficult to "train" a good OO programmer - probably due to the fact that at some level, it's not even a matter of technical skill
rather, you need some sense of good taste, and you need to abhor ugly, complex code - you need to constantly refactor your code to make it cleaner and less tightly coupled
it's even hard to interview for a good OO programmer - usually, one of the best ways is to look at real code from a real project that he/she has written and ask him/her to explain the code
1. You understand the code
1A. it's simple to comprehend and it works, and is a good illustration of OO programming
1B. it's simple, but is actually an example of generic programming or some other paradigm
2. You don't understand the code
2A. because you don't have the technical background to understand it yet
2B. because the design pattern is too complex/baroque
if you are just starting out, 2A. is a good possibility
if you are looking at real-life code, 2B. has a good chance of happening, due to evolving specs
with a multi-paradigm language like C++, 1B. is a good possibility in real-life code
of course, you want 1A., but if you are a beginner, you need to jump back and forth between 1A. and 2A. (studying to understand 2A.)
years ago, when C++ just came out, there were very few resources for good examples of OO - so few, in fact, that I went to Smalltalk first, before coming back to C++, which helped tremendously
these days, you can find plenty of examples through googling - but make sure you practice while doing it
imho, it's extremely difficult to "train" a good OO programmer - probably due to the fact that at some level, it's not even a matter of technical skill
rather, you need some sense of good taste, and you need to abhor ugly, complex code - you need to constantly refactor your code to make it cleaner and less tightly coupled
it's even hard to interview for a good OO programmer - usually, one of the best ways is to look at real code from a real project that he/she has written and ask him/her to explain the code
Thanks, I had my confidence knocked down because my project was badly organised (due to bad planning too) and I haven't seen the right way to actually plan.
Last edited on
Early on the only planning you should really be concerned about is error handeling. This is because when you are learning the language and establishing habits this is going to be one of the most important.
Once you release a program no one is going to say "Boy that Blessman11 sure has a nice application here; but I don't like the way he passed those variables on line 123,456." If they do, I think it's in the Unwritten Rule Book that you get to punch them in the stomach.
Once you release a program no one is going to say "Boy that Blessman11 sure has a nice application here; but I don't like the way he passed those variables on line 123,456." If they do, I think it's in the Unwritten Rule Book that you get to punch them in the stomach.
one bottom up approach is unit-testing (I use googletest):
http://code.google.com/p/googletest/
in the beginning, unit-testing will first help you ensure that you write a correct program (one that behaves the way you want)
once you have a program that works, you can refactor (re-organize your code) for cleaner code
this approach is coined "Extreme Programming" by Kent Beck, or more recently, agile programming
http://www.extremeprogramming.org/
this applies to C++ and any other project - it's a good way to keep you from over-planning functionality that you don't really need - it also helps you write reliable loosely coupled code (the fewer inter-dependencies the better)
typically, if you don't adapt some kind of programming paradigm you risk breaking your project when it reaches a certain number of lines of code - it becomes chaotic as you can't crush new bugs or your own code becomes hard to understand because there is too much of it or it becomes disorganized
extreme and agile programming try to keep you on track and away from these issues
http://code.google.com/p/googletest/
in the beginning, unit-testing will first help you ensure that you write a correct program (one that behaves the way you want)
once you have a program that works, you can refactor (re-organize your code) for cleaner code
this approach is coined "Extreme Programming" by Kent Beck, or more recently, agile programming
http://www.extremeprogramming.org/
this applies to C++ and any other project - it's a good way to keep you from over-planning functionality that you don't really need - it also helps you write reliable loosely coupled code (the fewer inter-dependencies the better)
typically, if you don't adapt some kind of programming paradigm you risk breaking your project when it reaches a certain number of lines of code - it becomes chaotic as you can't crush new bugs or your own code becomes hard to understand because there is too much of it or it becomes disorganized
extreme and agile programming try to keep you on track and away from these issues
Topic archived. No new replies allowed.