- Code Reuse
This might be the original reason objects were used in programming. The basic idea is that once a programmer figured out the code to do something, like calculate an interest payment or display a graphic, there was no real reason why anyone else should write that same code again if they could just find and use the original programmer's code. OOP is a very organized way to do this.
I've mentioned that the .NET Framework is just a huge collection of objects. The "code reuse" benefit of OOP means that Microsoft and thousands of other programmers are creating software for you to use.
In your own systems development, teamwork is a lot easier to manage with OOP. (The top-end version of Visual Studio .NET is called, "Team System".) The only thing you need to know about another team's objects is the interface. And that brings us to our next advantage.
- System Integration Through Standard Interfaces
One thing you don't need to know with .NET objects is what programming language they're coded in. Because all .NET objects use a standard interface, you can use C#, VB.NET or other languages together, in the same system, with no special code required. Even previous technologies like COM can be used as objects (although there are a few special requirements for them) because COM objects at least have a standard interface of their own.
- Translation of Requirements Into Code
We've talked about how objects are like everyday things in the real world. That's a great way to understand objects but there's another benefit. The fact that real world objects and software objects are really very much alike makes it easier to program real world objects using OOP concepts. All you have to do is figure out what a real world object does and what information it needs and you're well on your way to writing code for it.
- Information Is Tied to Function
One of the big problems with old-fashioned procedural code was that information could be changed anywhere in a program. Some people think this is an advantage instead of a "problem" and, in fact, it's not obvious why. Shouldn't that flexibility make things easier? Here's an example.
Consider a theoretical accounting system. If "LoanPackage" is an object and a property of that object is "InterestRate" then with OOP, the system could be programmed so that the only way to change InterestRate is with a method like "ChangeInterestRate(NewRate)". This gives programmers a clear way to make sure the program is only doing what it's supposed to be doing. If InterestRate changes, then the programmer knows that it could only have happened one way.
But suppose InterestRate could be changed by simply assigning a new value anywhere in the program. Beginners often think this is great. (Many professional programmers thought so for years.) But the actual effect is that how and where the interest rate is changed isn't clear anymore. If your customer reports that there is a bug because the wrong interest rate is being used, it can be very confusing to figure out when and how the interest rate actually gets changed in a "spaghetti coded" program. (Trust me on this. I did it for years.)
- Objects Are More Maintainable
Going back to the interest rate example, suppose you're a programmer assigned to change the interest rate used in customer loans. As we just discussed, the problem of just finding exactly how the rate is determined can be a huge issue. But it gets worse. Remember that each of perhaps hundreds of programs might have their own interest rate calculations. Changing the way the rate is calculated might involve changing, testing and implementing every one of those programs independently. But with OOP, if the calculation is in just one object, then you only have to change that one object and replace it in the library where it can be used by all the other objects that use it. With polymorphism and inheritance, it's entirely possible for one base object to have the flexibility to do exactly that.
Objects in Visual Basic .NET Express
The fact that you can think of your whole world as just a collection of objects should help to convince you that the object concept is a very powerful and flexible idea. But as a programmer, you need to understand how to use these concepts in code.
But first, one clarification about "OOP" and VB.NET code. Using .NET doesn't automatically make your code OOP. It's easy to code a VB.NET Class object so that it violates the "encapsulation" rule, for example. (Just create Class member variables as Public.) And not all classes in VB.NET are coded as objects. Some might be there just to organize your program a little bit better.
The reverse is true as well. We could write fully OOP code in Visual Basic 6, even though it wasn't as easy and well supported as it is in VB.NET. So, just because the VB.NET language rules let you write something, that doesn't guarantee that it's good object oriented code.
On the next page, we cover how to code an OOP Class in VB.NET.
