Tuesday, January 18, 2005

The dark side of Visual Basic

I have been looking into Object Orientated programming in Visual Basic 6 . Why look for something that isnt there, you might say. But you will be kinda surprised, as I was. There is support for Object Oriented programming in VB6 as opposed to popular belief. You can have encapsulation, polymorphism and inheritance (to some particular extend, as I will explain now).
To support encapsulation VB has a class module where you can group some data and methods which act on the data. Access control can be enforced using keywords Public, Private and Friend. Usage of this feature is highly recommended. While I am at it, I would like you to know that there is no support for static methods or data (methods and data belonging to the class as opposed to those belonging to an object of a class). That is restrictive to quite some extend, I agree.
Before speaking of inheritance we can group inheritance into 2 categories based on a single criteria - implementation inheritance and interface inheritance. In implementation inheritance, the derived class inherits all the implementation of the base class while in interface inheritance only the signature of the base class is recieved by the derived class. VB natively supports only interface inheritance. The keyword Implements is used to show that a class inherits the interface of another class. I have found that there is way to simulate implementation inheritance in VB by using composition. We can keep a private member object of the base class and delegate methods to that object if we dont want to implement any particular inherited method.
Support for polymorphism is rooted partly in this interface inheritance. That said, I would like to say there are 2 types of polymorphisms here. One happens when we have a base class and subclasses implementing the interface of the base class. We can refer to derived class objects using a reference variable of base class type and use it to achieve polymorphic calls to methods. The second way is when we keep object references as type Object (we can keep reference to objects of any class in a variable to type Object). Why I would like to differentiate between these two is because, in the first way, compiler can verify whether the object actually implements a particular interface thus preventing runtime error when method resolution fails. In the second way there is no way compiler can know if the object referred to by the Object variable actually has a particular method until runtime, when it is too late. I would suggest that whenever possible we should go for the first type of polymorphic calls.

The support for object orientation is not upto the mark (actually a bit too below the mark, I should say), but it is there all the same, as you can see. But VB.NET changes all these. Its a fully objected oriented language and very loveable ;-)
I had plans to include some code here, but I feeling sleepy and lazy :-)

1 Comments:

Anonymous Anonymous said...

These have been discussed in the inheritance vs composition debates. Also, a variant of the Adapter pattern from GoF book uses a techqiue like this.

But, consider a case like this:

public interface Foo {
  public Foo meth1();
  public void meth2();
}

public class FooImpl implement Foo {
  public Foo meth1() {
  // .. do something
  return this;
  }

  public void meth2() {
  // .. do something
  }
}

If I had implementation inheritance, I could do:

public class BarImpl1 extends Foo {
  public void meth2() {
  super.meth2();
  // .. do something extra
  }
}

If you use composition for this, you end up with:

public class BarImpl2 implements Foo {
  private Foo f = null; // .. initalized somewhere

  public void meth2() {
  f.meth2();
  // .. do something extra
  }

  public Foo meth1() {
  return f.meth1(); // DICEY!
  }
}

Bar2 looks OK, except until some client calls:
  bar.meth1().meth2();

The "extra" stuff you added in Bar2 would not be invoked! In general, to use this technique the base class should not pass itself outside.

In general, I have noticed that,
1. composition is more useful than inheritance
2. interface inheritance is often more appropriate than implementation inheritance

Good Luck on your project!

Cheerio,
Binil :-)

PS: How do I format code, besides resorting to clunky en-bee-es-pee's? This app needs to provide a help link on comment entry page!

1/19/2005 06:43:00 AM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home