Object Oriented-ness

Object Oriented Programming is a religion! But to be a true follower, one must truly understand its whats and, most importantly, its whys. It is easy to follow something blindly; but to truly understand the reason behind it is the true path to bliss. Anyway, enough with the gibberish. Now I'll serve the techila.

Most design pattens stem from the following basic OOPs principles, which if remembered, simplify a coder's daily life to a great extent -

1. Encapsulate what varies

By encapsulating what varies, you can make your application more flexible and easy to change.

2. Code to an interface rather than an implementation

Coding to an interface makes your software easier to extend by reducing dependencies between different parts of your application. In simpler words, you can change the implementation of a particular module without having to change the rest.

3. Each class in your application should have only one reason to change

Cohesion measures the degree of connectivity among the elements of a single module, class or object. The higher the cohesion of your software, the more well-defined and related the responsibilities or each individual class in your application. Each class should have a very specific set of closely related actions it performs making it easy to change, without changing the other classes.

4. Classes are about behaviour and functionality

Books can be written about this (and I'm sure there are lots.) But just a short ending note here - OOP simplifies design by relating code to real life. Just as your brain isolates one physical object from another based on its unique attributes and behaviour, OOP enables us to cleanly break our big complex code into smaller manageable modules.

P.S.: Most of these principles are picked up from the highly recommended book - O'Reilly's Head First Object Oriented Analysis and Design.

Crazy compilers

"When you try to delete a derived class object through a base class pointer and the base class has a nonvirtual destructor, the results are undefined. That means compilers may generate code to do whatever they like: reformat your disk, send suggestive mail to your boss, fax source code to your competitors, whatever. (What often happens at runtime is that the derived class's destructor is never called.)"

-Scott Meyer in Effective C++

Moral of the Story :
The next time your email client's sent folder shows a funny email to your boss that you don't remember sending him, be sure to check your code for non-virtual destructors! :-)