Jump to content
  • Advertisement
  • entries
    146
  • comments
    436
  • views
    198530

Object Oriented Programming

Sign in to follow this  
Washu

177 views

It seems to me that there are a few people who aren't to sure of what OOP really means. So, I've decided to attempt to focus the next few entries on OOP and some of its core principles. I will frequently attempt to provide googling terms, but I won't guarantee that.

Why you should fear RFIV
Your design is rotting. Well, maybe your's isn't, but I can guarantee that someones is. So how can you tell if your design is rotting? You will typically find many different symptoms indicating that your design is rotting, but here are the most common ones:

  • Rigidity
    You find indications of this when you attempt to make a small change and find that it ends up cascading through several modules. Very much like a recursive function, you keep having to move from module to module making changes to accommodate for your one original change. Like a dog chasing it's tail, you continuously find yourself moving from module to module. This typically crops up when you need to add new features, or when you need to make a small change to fix a bug.

  • Fragility
    This one is tightly related to rigidity. This particular symptom crops up when you make a minor change and find that other modules break as a result of the change. Quite often you will find that the code will break in areas that seem completely unrelated to the change in question. Fixes that are applied to solve the breakage will typically increase the fragility of the software, hence making it even harder to change and keep working.

  • Immobility
    Code that is immobile is code that cannot be reused. This doesn't just mean code that cannot be reused in other projects, but even local project reuse. A programmer may find that he needs to do something similar to what one module does, but that he can't use that module due to dependencies that have snuck their way into the other module. This code no longer can be reused (if it ever was) and hence makes for duplicated code elsewhere. This tends to increase the chances of bugs, and makes the software more rigid and fragile in the process.

  • Viscosity
    You will find a high viscosity in code when you cannot make a design preserving change more easily than a hack. Hacks inheritly break the design of the code, they also tend to increase immobility and fragility. Viscosity can also be an environmental factor. For instance a large C++ project will typically have long compile times, which can account for slow development (and debugging) thus contributing to a high viscosity in the environment.



Why is your design rotting?
The most prevalent cause for design rot is the case of changing requirements. Changes that were not initially predicted have been requested. Since the changes were requested at an inopportune time they took place rapidly, and tend to violate the principles of the original design. While the changes work, they contribute to the increasing entropy in the code. As these changes accumulate over time, the entropy continues to increase and the design continues to rot. Eventually the code bites back and things cease to work anymore. Welcome to hell.

The cause of all of this rot, and increase in code entropy, is a failure to properly account for your dependencies. Unnecessary dependencies are introduced. As each module becomes more dependent upon the other, changes to one cause others to break, and when those are fixed, they in turn cause other modules to break. Each fix introduces a new dependency, and hence increases the rigidity and fragility of the software.
Sign in to follow this  


2 Comments


Recommended Comments

You're design is rotting. Well, maybe your's isn't, but I can guarantee that someones ...

==>

Your design is rotting. Well, maybe yours isn't, but I can guarantee that someone's ...


Yes, I'm applying to the grammar nazi squad, why? :)

Share this comment


Link to comment
Excellent Post =)

Very reflective of the situations I've had to face in commercial development.

The management never likes to hear...

"This change will require us to rethink the design of the program, and may potentialy result in large changes to insure everything works properly."

They ususaly just want the change to be instantanious, as if it was there from the get-go =/

Given that they don't understand software development, it is easy for them to expect automagic re-design =/

So as a result, it comes down to "Implement feature X as fast as you can." which ususaly results in the dirtiest hack imaginable.

Ahh. =/

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!