Editorials

JSON – Transportable Encapsulated Objects

Let’s face it; we live in a world where object oriented programming has become the predominant technique for writing most code. At least, that is the case for most current tool sets. That being said, I find it interesting that we find ourselves embracing some features of OO, and ignoring others.

For example, I see a lot of dependency injection, which isn’t an OO technique per se, but, is not something you can readily do unless you are using OO tools. On the other hand, the encapsulation of objects seems to be less important. We use data transfer objects, which are anemic, property only tools for transporting data from one system to the next. We expose our inner workings with public properties, because it is easy to transport of an HTTP connection.

In this scenario, I am really in favor of JSON. I hammered on JSON pretty hard yesterday, when talking about including it in SQL Server. That’s because SQL Server doesn’t support JavaScript code execution. At that point, JSON objects are anemic, and used simply to pass data back and forth in a simple mode. It is just another method to pass data to SQL Server, which is not a problem without a better solution.

But, JSON, as a complete object is VERY attractive. You have to ability to provide internal logic and other capabilities built into your object, and still pass it as a string over something as simple as an HTTP port. This is a much more powerful capability that that available in XML. Since JavaScript is implemented on so many devices, a less anemic object, in the form of JSON makes a lot of sense to me. The only downside is that your syntax is readily available. That limits you to using JSON in environments where you don’t care how easily someone can view your code.

What’s your take? Are you a fan of JSON and JavaScript? Do you think TypeScript will take it to the next level? Share your opinion in our comments.

Cheers,

Ben