John Wood

Is OOP Bad for Business?

You know data is a very valuable thing. The more data is exposed, the more potential information we can use to make informed decisions. There is rarely a case when it is a good thing not to know about data. Knowing how to use it is entirely different, as is knowing how to correctly categorize, structure and group that data. But for any reason hiding data impedes our ability to build intelligent services. Full disclosure should be the top priority of building an enterprise application.

Now, these days many enterprise applications are written using object oriented programming (OOP) languages, such as Java or C#. There are probably many reasons why this is, not least because the majority of programmers are experienced in OOP languages and the best development environments and tools are for OOP languages. They're also typically general purpose languages so you can re-use your skills in a variety of different domains.

But the problem is that a lot of the features of OOP languages aren't really the type of language features you would look for in order to build the business logic of a business application.

For one, OOP focuses on creating agents that encapsulate data, rather than exposing and enhancing data accessibility.  When this data is business data, building objects around the data is akin to adding unnecessary bureaucratic red tape to an otherwise simple process. 

Object orientation was designed for creating abstractions, and it's especially useful for creating layers of abstractions. It's very good at it. These layers are typically built using a feature of object orientation called 'encapsulation' that allows us to hide the details of one layer in order to create a new layer with new functionality and a different interface. General purpose object oriented languages can be used for most anything (hence general purpose) and so of course the ability to create layers of abstractions would be important. General purpose languages are generic tools.

The people who know your business really aren't going to understand, or want to understand, how to develop abstractions. They won't care what a fragile base class is, what a singleton is, and why he needs to instantiate a factory class to even begin querying his invoices. All he will care about is data and the calculations he can run on that data. Bridging the gap between those who know your business and the application itself is the key to the success of your application.

In most business applications there are really just two layers.

1. There is the domain (or model). This is the data you need to solve your problem and services to retrieve and interact with that data, and...

2. The services layer. This is the business logic that you develop on top of that domain. This represents the application-specific calculations on that data.

Building a business solution should not involve creating any new layers, just expanding your services layer.

And user interfaces don't count. If I receive an invoice, viewing that invoice involves at most picking up a pair of glasses and reading. Viewing data is not really a business function. If the data is there and fully exposed, taking a peek doesn't require any abstractions. Making the data look pretty is purely an exercise in knowing how to locate stuff and draw it, so I don't consider that a layer.

And then there are those who think that encapsulation is required in order to protect data.  Protecting data for referential integrity, security and accidental change is important, but doesn't require encapsulation. Field level permissioning and model-level constraints are usually enough to protect your data, and these constraints should be controlled through business rules - logic written in the business domain, not database constraints that have no knowledge of the business. These business rules can 'watch' the transactions changing the data much like a supervisor. If they see you changing something that doesn't make sense, or if you're not allowed, then they will be able to jump in and stop you.

So I repeat, "building a business solution should not involve creating any new layers". 

This means that, for developing business logic, creating abstractions is not required. This means that encapsulation is not important. And this means that data hiding is not only not important, it's actually detrimental to your application.

Many of the features of OOP languages are just not needed in business applications once the domain model is in place. They are actually overkill for business applications. They give you too much power and in many ways encourage you to make data less accessible. So if someone argues you must use an object oriented language to develop business logic, there are plenty of reasons to disagree with them.

But if you're not going to use OOP languages for your business logic, what choice do you have? The problem is actually the lack of business oriented languages, at least the lack of modern business oriented languages seeing as there were some, but they were developed in the 70s and do little to make business application development any easier.

I hope we will see the emergence of some new languages, domain specific languages, that focus on data and not on constructing abstractions. And no, COBOL is not the answer.