Five Tips for Effective Object-oriented Programming in C++

Spurgeon's Law says that 90% of everything is crap. This certainly holds true in the world of software development, and especially when it comes to object-orientation and  C++   programming . This is largely due to the pervasiveness and complexity of C++; it's one of the most commonly used object-oriented languages, and yet few people know how to use it effectively. Couple this with the fact that few programmers truly grasp the object-oriented  programming  philosophy and you have an instant recipe for sloppy code. Volumes can be--and have been--written on how to develop proper object-oriented software designs using C++. Obviously, there won't be space in this article for a truly thorough discussion; however, I would like to present a few quick, simple and effective tips for developing robust C++ software.

1. Work on the class designs first before deciding on the precise sequence of operations. Many programmers fancy themselves as doing object-oriented  programming , but in reality, they use structured  programming  with some external object-oriented trappings. Ideally, one should first select a set of software objects that provide a logical abstraction of the software, then work on the sequence of operations. (This is by no means an absolute rule though, as the process of developing this sequence often reveals ways in which the object design can be refined.)

2. Think in terms of design patterns. Design patterns allow someone to draw on years of problem-solving experience within the computer science community. Instead of reinventing the wheel, why not just pick one off the shelf?

3. Use 'const' objects and 'const' functions whenever possible. If you know that an object's data is never supposed to be modified, then declare the object to be 'const'. This will prevent you--or worse, a naïve colleague--from accidentally modifying its state later on. Of course, one should also declare the appropriate member functions to be 'const' as well, to properly enforce this rule.

4. Avoid using public 'get' and 'set' member functions. Getters and setters are not inherently bad; however, they are often a sign of poor software abstraction. 'Get' and 'set' functions implicitly force the user to think in terms of the object's internal data (i.e. whatever these functions are getting or setting), and such details should ideally be hidden from the object's user. Getters and setters have their place, but please use them sparingly.

5. Avoid double indirection. C programmers are forced to work with pointers, and so they are used to having pointers to pointers throughout their code. This can often lead to confusing code, due to the all-too-familiar problems of NULL references and pointer arithmetic. In contrast, C++ programmers are under no such constraints, due to the built-in support for variable references in C++; that is, one can always use references to pointers instead, which makes the code much easier to understand. (Hint: If a C++ programmer uses double indirection, that's a clear sign that he's still thinking like an inexperienced C hack!)