Saturday, March 7, 2009

Programming: Closed/Open principle

Sounds confusing but its not.
Actually it is a great strategy when you apply it while coding.

It goes like this: when you write a class to do a particular job. Keep in mind that you do not want anybody to make changes to this class. Hence it is closed for any modifications.

However you should allow other programmers to add new features or change the flow of the behavior by extending the class. So you give away your class as black box to programmers with documentation. Then they extend your class and add actions to its method. Hence it is opened for extension.

Here is an example of a core class (pseudo code) written to switch off all the lights at your house. It is installed and wired with all your house lights.

Public Class TurnOffLights

Public Sub TurnOff()

// Some Code
End Sub

End Class

Now you want to add some behavior to this class to prompt you before switching off the light! You cannot modify the class but you can extend (inherit) it.

So we'll write another class.

Public Class TurnOffLightPrompt Extends TurnOffLights

Public Sub Overrides TurnOff()

//I Don't know what code is written up there in the base class but I can add my own

if (MsgBox("Are you sure?",vbYesNo") == vbNo) Then Exit Sub
MyBase.TurnOff () //Call the original turnoff


End Sub

End Class

You may want to read Head First Design Patterns, it just makes you fall in love with Object Oriented.

4 comments:

  1. Yes, OOP is all about abstract classes that can be used by others through a documented interface without having to know the exact implementation and methods of the class.

    You do not need to know, for instance, the metallurgical components of an I-beam in order to use it in the construction of a building. You just presume that it will work.

    As to the book Head First Design Patterns, it really is a good book. It not only talks about OOP but also how OOP could be used efficiently. The book about design patterns by "The Gang of Four (GoF)" is also a good one.

    BTW, that VBish pseudocode is a nice way to illustrate the point. ;)

    Happy polymorphing! :)

    ReplyDelete
  2. Thanks for the comment Pragma, (I really want to know your real name)

    I read the Head First Design book then I bought the GOF.

    GOF is more like a pattern catalog you can refer to easily.

    LoL Yes I know I wrote it in VB I guess I have to avoid saying a pseudocode :p

    you might guessed that am a vb fan

    ReplyDelete
  3. The Head First Series is great, in my opinion. It is also true that the GOF is more of a reference of patterns that you can reuse.

    As to VB and pseudocode, there is nothing wrong in calling VB code, pseudocode. In fact, that is the strength of VB. It is high level enough and closer to the problem domain than other languages that you do not have to do much after you have determined the pseudocode. Pseudocode to VB language statement is almost a one-to-one correspondence.

    This is unlike low level languages where you have to break a pseudocode statement into many language specific statements. In short:

    pseudocode statement ≅ VB statement.

    As to being a VB fan, that's great. VB is an amazing language and is good for a lot of problem domains. Anyhow, it is always a wise idea to use the highest level language that the problem set allows.

    I also played with VB when it was still in version 4; although I lean more towards Delphi—not because it's better or something, but because I was using Turbo Pascal 7 in my engineering days. :p

    -Cody

    ReplyDelete
  4. thanks Cody for your valuable comment,
    yes both are similar.

    Yes it depends on what you are familiar with.

    ReplyDelete

Share your thoughts