Object Oriented Programming

From Mark Weiman's Wiki
Jump to navigation Jump to search

Introduction

Object oriented programming (OOP) can be a useful tool for organizing data within a program. The issue with it, as with many things in this field, people tend to take it to its extreme where every part of the program must be part of an object class.

Abstractions Galore

A nasty habit that many OOP programmers tend to get into is creating abstractions for things that do not need them. This gives us code where one of the following can happen:

  • Classes with no properties except one function.
  • Classes with needless classes defined in them (nested classes)
  • Classes that abstract trivial concepts.

In general, I do not see the point in separating code off into individual objects just for the sake of doing so. Functions should be able to live by themselves, variables too.

A classic example is with programming a linked list. Lots of examples create a LinkedList class with a Node class inside of LinkedList. I think this is needlessly complicated as you can just point a LinkedList instance to another LinkedList. This is what I do in C for example in libbodhi.

Structure Issues

OOP has an annoying tendency of producing spaghetti code. This makes it very hard to:

  • Understand the code
  • Debug the code
  • Update the code

Naming Conventions

OOP usually is accompanied by the horrible camel case naming technique. Camel case is terrible for reading and refactoring code.

When To Use Objects

You should only use objects or classes in your code when its convenient. Any time you are looking to create a new objects just for the sake of creating new objects, you aren't doing you or a reader of your code any favors. You are also probably making a problem where object dependencies cause you to blow up your computer's memory or create mega-stacktraces (where this function called this function that called this function that called this function ...).