The code inside a method is called the implementation. Sometimes it is also called behavior, as it is this code that actually makes the object do useful work. For instance, you might have an Age property as part of the object's interface. Within that method, you might have code similar to the following:
Public Readonly Property Age() As Integer
In this case, the code is returning a value directly out of a variable, rather than doing something better, such as calculate the value based on a birth date. However, this kind of code is often written in applications, and it seems to work fine for a while.
The key point is to understand that client applications can use the object even if you change the implementation, as long as you do not change the public interface. If the method name and its parameter list and return data type remain unchanged, then you can change the implementation any way you want.
The code necessary to call the Age property would look something like this:
theAge = myObject.Age
The result of running this code is that you get the Age value returned. While the client application will work fine, you will soon discover that hard-coding the age into the application is a problem, so at some point you'll want to improve this code. Fortunately, you can change the implementation without changing the client code:
Private _BirthDate As Date
Public Readonly Property Age() As Integer Get
Return CInt(DateDiff(DateInterval.Year, _BirthDate, Now)) End Get End Property
You have changed the implementation behind the public interface, effectively changing how it behaves without changing the interface itself. Now, when you run the client application, the Age value returned is accurate over time, whereas in the previous implementation it was not.
Additionally, to implement this change you've moved from one of the new features of Visual Basic 2010 — auto-implemented properties, to a traditional property with a backing field implementation. Much of the existing .NET code you'll see in Visual Basic will use a backing field for properties because up until this release that was the only way to implement a property.
Keep in mind that encapsulation is a syntactic tool — it enables the code to continue to run without change. However, it is not semantic, meaning that just because the code continues to run, that does not mean it continues to do what you actually want it to do.
In this example, the client code may have been written to overcome the initial limitations of the implementation in some way, and thus the client code might both rely on being able to retrieve the Age value, and count on the result of that call being a fixed value over time.
The update to the implementation won't stop the client program from running, but it may very well prevent it from running correctly.
Was this article helpful?