SoftSlang

In the beginning, engineer created computer. And the computer was cold and bare. And so engineer brought computer programmer and separated hardware from software. Computer programmer looked at software and saw that it is fine and good. And computer programmer divided data and programs from the software. The data held values such as numbers, descriptions and dates. The programs held algorithms that told the computer what to do with the values. The computer could add, subtract and square root at speeds that nobody had seen before. All was happy and good in the kingdom of the computer and both engineer and computer programmer were happy with their creation. Then one day, more computer programmers came and there was big software with lots of values and lots of programs. Programs from one side were changing values on the other side. And programs from the other side were adding and subtracting values which no longer made sense. There was chaos in the values and programs grew more complicated and the programmers tried to fix them. Sometimes they would fix one side and break another. The engineer was angry and yelled at the programmers to stop breaking the beautiful creation made in his own image named computer. Fearing the wrath of the engineer, a group of smart computer programmers got together and invented a new programming paradigm named – Object Oriented Programming hoping, dreaming and praying that they would be spared the tongue lashing in the future.
The fundamental tenant of Object Oriented Design is the idea of surrounding data with functionality. Data is never on its own separated from the functionality that manipulates it, instead each logical island of data is encapsulated inside the functionality that understands what to do with it.

I have been both blessed and cursed. Early on in my career as a computer programmer I had to program in a pure object oriented language called Smalltalk. I was a perfectly happy computer programmer, completely content with the programming languages that I knew at the time, C, Fortran and others. And then Smalltalk crossed my path

Applying Object Oriented Design concepts is difficult in .NET. This is due to the fact that the .NET Framework and tooling has been (along with prior Microsoft dev languages, frameworks, & tools) focused largely on what I call a forms-based approach to developing applications. The .NET developer customer base comes largely from VB and ASP worlds, where applications were large conglomerations of forms (or pages) with a bunch of code inline in the forms that serve to access and save some data from/to a database. The introduction of .NET as an “object-oriented” platform didn’t magically make all of that go away (and with good reason). So although .NET has object-oriented concepts built in, most of the tooling and a lot of the features of the languages and frameworks were and are targeted at those same kinds of applications.

This isn’t to pass negative judgment on Microsoft or all the extremely bright folks that work at that company. They had and have valid business needs to keep targeting this kind of development, partly because it really is RAD (rapid application development), and their primary dev customer base was (and is) used to that kind of development. I myself have developed using .Net for years, and simply got used to and accepted the .Net constructs.

.NET enables developers to have OOD constructs (classes, polymorphism, encapsulation, for example), but even with that, even with “class library” projects in the dev toolkit, it is still fairly difficult to develop OOD applications. Visual Studio 2008 has made it a bit easier and better with the class designer DSL (domain-specific language), but it is still fundamentally limited by the nature of .NET itself, and it is all too easy to fall into a way of developing applications that only pays lip service to OOD, one that uses things like classes, accessibility modifiers, properties, and methods, but is essentially forms-based and data-driven. I can’t think of anything that is more contrary to Object Oriented Design than using a DataSet to retrieve a bunch of data from a database and then binding the DataSet to a grid to display the information to the user and later to save it back to the database. Yet that is the easiest way to get things done in .Net and I myself have used it on many occasions, because resistance is futile and getting assimilated made my life less painful.
By “data-driven,” I mean that the average .NET developer (myself included) is so tempted to think in terms of database entities—to think primarily in terms of an object’s attributes (a.k.a., properties), i.e., its data members. Developers are encouraged to do so by many things. For most, their training and experience tells them to do this, and pretty much all of the purportedly OOD tools on the market today (including LINQ) do this—they all want to generate objects based on databases. Finally, there’s the simple fact that most enterprise business applications involve showing data to users and letting them modify it, so it is easy to fall into the data-driven mentality.

So the question I am asking myself is this. Is it possible to use OOD in the real world? And how to practically apply it?

In: Joy of Programming | | #