Many call themselves object-oriented programmers; however, it takes time to learn how to practice this art well. In this article, the author offers a few pointers.
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!)
One description that you should never use in a singles profile
Learn how to avoid an all-too-common mistake when writing a singles profile
A few tips on social dance etiquette
New to social dancing? Here are a few pointers to help make the experience a pleasant one.
The Pitfalls of Overusing 'Get' and 'Set' in Object-Oriented Programming
Over-reliance on getter and setter functions in object-oriented programming can undermine the very principles it stands for, such as encapsulation and information hiding. This article explores why excessive use of these functions can be detrimental and offers insights into more effective programming practices.
