What is encapsulation?

One of the four properties of the object-oriented paradigm is encapsulation. While inheritance, abstraction and polymorphism are widely used in Object Oriented Programming (OOP), especially in Visual Basic, can we say that encapsulation is ever used?

Looking throughout the MSDN Library gives me this definition of encapsulation (from an article entitled the One Minute Terminologist):

The MSDN article Object Oriented Programming in Visual Basic.NET redefines encapsulation (incorrectly) as

I believe the first definition is the true, and valid, pillar of true OOP, yet current design practice rarely builds encapsulated objects in favor of heterogeneous data structures on traditional relational dbms server systems.

Do we encapsulate?

One of the first programming languages I learned was FORTRAN (using JCL on punch cards), and until we learned file I/O we added input via the DATA command at the end of the program. I guess you could say my FORTRAN batch programs were encapsulated. In fact, they were more encapsulated than most of today's object oriented programs, which are rarely, if ever - contain data. My career in the last four years has been far from batch programming. As an n-tiered developer, I have worked in creating web applications and multi-tier client/server network applications that include the use of middle tier objects, component oriented clients in script and compiled code, the extensive use of external data sources.

The last part is what causes me some dissonance. Rather than embodying encapsulation, the progress in the last few years has been toward marrying external objects to traditional relational databases with various piping software (ODBC, JDBC and so on). These objects take the form of COM+ objects (originally MTS), which definitely assist in defining business logic. Certainly, one of Visual Basic's strengths is its readability as a programming language.

Modeling business logic or other systems in VB is infinitely superior to using machine like languages such as C/C++, or trying to use any non-OO scripting language (such as HTML). XML, the godsend of data markup languages, clearly create encapsulation and embody ideas of inheritance - but they have no procedural syntax; and while handy for passing information between machines, are of little use for data architectures of any kind.

Why data encapsulation?

Ok, so that's my criticism: encapsulation is rarely used, if ever, in Visual Basic n-tiered information systems. The next question is more positive. Why should it be used? Let's think about samples…lets say we are building a customer relationship management system, but we want maximum flexibility. We really want to know our customers. In fact, we are so hands on, touchy-feely (think Nordstrom) that we know each customer has different characteristics. The typical relational database response might be to include a "Comments " field in addition to name, address, the usual. So we get records that look like:

Well, that's not a very instructive thing, because it is hardly useable in code and presents problems for select statements, indexing, and so on. More than likely, the 'Comments' field will be input, but never retrieved or used. So what many DBMS tools then do is offer the database designer to add 'custom fields' by relating a table to the customer. For example. The table above becomes.

The custom fields table becomes

So at least, someone who takes the time to look at the custom fields table gets some idea of the types of information that have meaning to this customer. The problem here is the opposite of instance one, every time we have a customer with a special feature, we apply this field to all customers! Now, for my pitch for encapsulation.

Suppose that we keep the database for what it does well - modeling, searching and sorting homogeneous data structures. That is - it covers those things that we all have in common - names, addresses, cities, email addresses. Databases, however, get hung up in the details. My suggestion is that VB.NET COM+ components, for instance, are very good places to store the details - as the properties and methods of individual classes that can be applied down to the individual person (in the case of CRM).

A 'mixed' encapsulated and ado aware class in vb.net that might represent a customer might look like this:

Imports System
Imports Microsoft.VisualBasic

Public Class JohnBailo

    Sub getBasics()

        Dim connSql As SqlConnection
        Dim cmSql As SqlCommand

        Dim dremp As SqlDataReader
        connSql = New SqlConnection( _
            "server=webserver;uid=sa;pwd=;database=license")
        cmSql = New SqlCommand("s_getAllCustInfo", connSql)
        cmSql.commandtype = CommandType.StoredProcedure
        Try
            connSql.Open()
            dremp = cmSql.ExecuteReader()
            Do While dremp.Read()
                Console.WriteLine(dremp("ename").ToString())
            Loop
        Catch err As SqlException
            Console.WriteLine(err.ToString())
        Finally
            connSql.Close()
        End Try

    End Sub

    
    Public Function getFavoriteColor() As String
        Return favoriteColor = "blue"
    End Function


End Class

Where getAllCustInfo is a sproc that retrieves all of the information in a customer table in SQL Server. The beauty of this, is that when we write a client application, we see or expose the getFavoriteColor. This allows heterogeneous data to be part of an individual class, which is also a COM+ component, which can be called or mapped to a unique customer key - but at the same time, not all customers are required to carry that data, if the data is not relevant to the customer! This model would look thus:

In many ways, the .NET Passport idea carries some of this thinking. A user logs on and carries his 'record' with him passing those data fields to an e-commerce or other sites.

To summarize, the little used concept of object data encapsulation, might be a way to help us store and retrieve non-standard, or heterogeneous data.