Volume 34 Number 3
By Michael Desmond | March 2019
Object-oriented programming (OOP) has stood as an aspirational target for developers going back to Alan Kay and his Smalltalk programming language in the 1980s. It’s hard to argue the benefits of an object-oriented approach that features modular, reusable code to speed development, ease maintenance and boost productivity. And over the decades, we’ve seen object orientation adopted by many of the most widely used programming languages and frameworks, from C++ to Java to C#.
But as Ted Neward pointed out in his The Working Programmer column at the beginning of the year (msdn.com/magazine/mt848703), the ultimate promise of OOP remains to an extent unfulfilled. In that column, he introduced Naked Objects (nakedobjects.org), an architectural pattern developed by Richard Pawson that’s dedicated to the concept of behaviorally complete objects. Unlike most mainstream OOP implementations, Naked Objects encapsulates all the business logic as methods on domain entities. The developer doesn’t need to define views or controllers, and the UI is generated automatically from metadata gathered, via reflection, from objects at run time.
“I think every senior developer, once they discover reflection, dreams or imagines building a system like this, which is why I think Naked Objects is so instructive as a model to examine,” Neward says. “It’s far more viable than most developers realize, and I think part of what hurts it is that a lot of folks simply don’t know it exists.”
Naked Objects got its start as a Ph.D. thesis by Pawson, who was inspired to explore deep object orientation after conversations with Alan Kay in the early 1990s. Pawson saw that despite the clear benefits, few commercial systems were being developed in OOP. And, he says, “Those that were doing it weren’t getting the kind of dramatic benefits that OOP promised. I was keen to understand why.”
His conclusion: Theoretical gains from a paradigm based on behaviorally complete objects were offset by all the work needed to create layers of code above and below the domain model in a real application. In short, “the benefit of behaviorally complete domain objects was lost in the added complexity,” Pawson says.
Naked Objects addresses these disconnects, while eliminating the effort of creating and maintaining a UI layer, says Pawson. “You get the benefit of a UI that is completely consistent in its operation, even across a very complex domain model.”
You won’t find a lot of Naked Objects deployments, but they do exist. The Irish Department of Social Protection has built its enterprise systems on Naked Objects since 2004. Pawson says the department has moved through three radically different architectures without any change to the underlying domain code—a Windows Presentation Foundation thick-client model, a thin-client model running on ASP.MVC, and currently a single-page application written in Angular and communicating with the server via a RESTful API.
“Given the complexity of its business model—4,000-plus domain classes!—that’s an extraordinary accomplishment,” he says.
Is Naked Objects likely to be on tap for your next project? Probably not. But as Pawson notes, it offers lessons for developers no matter the engagement.
“Naked Objects makes it a lot easier to adhere to a number of principles of sound software design,” says Pawson. “Domain-driven design, separation of concerns, modularity and, above all, polymorphism.”
Those lessons are sure to be present in Neward’s ongoing Naked Objects series. Be sure to check out his latest in this month’s issue.
Michael Desmond is the Editor-in-Chief of MSDN Magazine.