View source for Naked objects

{{Short description|Concept in software engineering}}
'''Naked objects''' is an [[Architectural pattern (computer science)|architectural pattern]] used in [[software engineering]]. It is defined by three principles:

{{ordered list | list_style_type=decimal | start=1
|
All [[business logic]] should be encapsulated onto the [[business object (computer science)|domain objects]]. This principle is not unique to naked objects; it is a strong commitment to [[information hiding|encapsulation]].
|
The [[user interface]] should be a direct representation of the domain objects, with all user actions consisting of creating, retrieving, or invoking [[method (computer science)|methods]] on domain objects. This principle is not unique to naked objects: it is an interpretation of an [[object-oriented user interface]]. 
}}

The naked object pattern's innovative feature arises by combining the {{ordinal|1}} and {{ordinal|2}} principles into a {{ordinal|3}} principle:

{{ordered list | list_style_type=decimal | start=3
|
The user interface shall be entirely automatically created from the definitions of the domain objects. This may be done using [[Reflection (computer science)|reflection]] or [[source code generation]].
}}

The naked objects pattern was first described formally in Richard Pawson's PhD thesis<ref name="pawson">{{cite thesis |degree=Ph.D. |last=Pawson |first=Richard |date=June 2004 |title=Naked objects |url=http://downloads.nakedobjects.net/resources/Pawson%20thesis.pdf |publisher=[[Trinity College Dublin]]}}</ref> which includes investigation of antecedents and inspirations for the pattern including, for example, the [[Morphic (software)|Morphic]] user interface.

The first complete [[open source]] framework to have implemented the pattern was named Naked Objects.<ref name="nof">[https://github.com/NakedObjectsGroup/NakedObjectsFramework Naked Objects Framework]</ref> In 2021, Pawson announced that he had subsequently applied the same pattern to the [[Functional Programming]] programming paradigm, as an alternative to the [[object-oriented programming]] paradigm, creating a variant of the Naked Objects framework called Naked Functions.<ref name="dzone">[https://dzone.com/articles/from-naked-objects-to-naked-functions From Naked Objects to Naked Functions]</ref>

==Benefits==
Pawson's thesis<ref name="pawson">{{cite thesis |degree=Ph.D. |last=Pawson |first=Richard |date=June 2004 |title=Naked objects |url=http://downloads.nakedobjects.net/resources/Pawson%20thesis.pdf |publisher=[[Trinity College Dublin]]}}</ref> claims four benefits for the pattern:

#'''A faster development cycle''', because there are fewer layers to develop. In a more conventional design, the developer must define and implement three or more separate layers: the domain object layer, the presentation layer, and the task or process scripts that connect the two. (If the naked objects pattern is combined with [[object-relational mapping]] or an [[object database]], then it is possible to create ''all'' layers of the system from the domain object definitions alone;  however, this does not form part of the naked objects pattern ''per se''.) The thesis includes a case study comparing two different implementations of the same application: one based on a conventional '4-layer' implementation; the other using naked objects.
#'''Greater agility''', referring to the ease with which an application may be altered to accommodate future changes in business requirements. In part this arises from the reduction in the number of developed layers that must be kept in synchronisation.  However the claim is also made that the enforced 1:1 correspondence between the user presentation and the domain model, forces higher-quality [[object model]]ling, which in turn improves the agility.
#'''A more empowering style of user interface'''.  This benefit is really attributable to the resulting [[object-oriented user interface]] (OOUI), rather than to naked objects per se, although the argument is made that naked objects makes it much easier to conceive and to implement an OOUI.
#'''Easier requirements analysis'''.  The argument here is that with the naked objects pattern, the domain objects form a common language between users and developers and that this common language facilitates the process of discussing requirements  -  because there are no other representations to discuss.  Combined with the faster development cycle, it becomes possible to prototype functional applications in real time.

==Use==
The [[Department of Social Protection]] (DSP) (formerly known as the Department for Social and Family Affairs) in Ireland has built a suite of enterprise applications using the naked objects pattern. As part of its Service Delivery Modernisation (SDM) programme, the DSP designed a new enterprise architecture both to meet its planned new business requirements and to provide greater agility over the longer term. The naked objects pattern forms a key element of the SDM architecture.<ref name="sdm">Department of Social and Family Affairs - Guide to the Functions & Records of the Department, [http://www.welfare.ie/EN/OperationalGuidelines/sect15/Pages/part5.aspx#5.13 DSFA website  -  Freedom Of Information] {{Webarchive|url=https://web.archive.org/web/20121019194350/http://www.welfare.ie/EN/OperationalGuidelines/sect15/Pages/part5.aspx#5.13 |date=2012-10-19 }}</ref> In November 2002, the DSP went live with a new application to replace its existing system for the administration of child benefit. This is believed to be the first operational application of the naked objects pattern, anywhere. The DSP's experience in building this first application, including the reactions of users to the radical user interface is documented extensively in Pawson's thesis,<ref name="pawson"/> and more recently in a presentation at QCon London 2011.<ref name="qcon">Case Study: Large-scale Pure OO at the Irish Government [http://www.infoq.com/presentations/Large-scale-Pure-OO-Irish-Government QCon London 2011]</ref>

One of the more striking aspects of the DSP experience was the way that the Naked Objects technique permitted re-use very actively.  Once a domain object, such as a Customer, had been defined for one 'application' it could be (has been) readily adapted with the minimum of tweaking and addition for use elsewhere.  This suggests that the approach could become a favourite in government circles, where re-use is seen as a powerful technique for breaking down siloed systems.  The UK 'Transformational Government' policy is particularly keen to see re-use become a standard requirement of new government systems, both consuming other governmental system components and making new ones available for others to use.  This re-use is often seen in terms of services, but objects could be an equally powerful approach.

The DSP's initial 'Naked Object Architecture' was developed by an external contractor,<ref name="fujitsu">Fujitsu, Case Study: The Department of Social and Family Affairs [http://www.fujitsu.com/ie/casestudies/dsaf.html Fujitsu website] {{webarchive|url=https://web.archive.org/web/20071129213502/http://www.fujitsu.com/ie/casestudies/dsaf.html |date=2007-11-29 }}</ref> but the architecture was subsequently redeveloped around the [https://github.com/NakedObjectsGroup/NakedObjectsFramework/ Naked Objects Framework] which now forms the basis for future application development, as confirmed in the request for tenders for a four-year programme of further applications to be built using naked objects.<ref name="rft">Department of Social & Family Affairs, The ongoing development of the Department's Service Delivery Modernisation programme, 2007, [https://archive.today/20120724155036/http://www.e-tenders.gov.ie/Search/Search_Show.aspx?id=APR082087 e-tenders website]</ref>

==Relationship to other ideas==

The naked objects pattern has relevance to several other disciplines and/or trends, including:

{{glossary begin}}

{{term|term= Object storage mechanisms }}
{{defn|defn=
<p>[[Object-relational mapping]], [[object database]]s, and [[object persistence]] are all concerned with eliminating the need to write a conventional [[Data access layer]] underneath the domain objects. These patterns are complementary and potentially synergistic with the naked objects pattern, which is concerned with eliminating the need to write layers above the domain objects.</p>
}}

{{term|term= [[Agile software development]] }}
{{defn|defn=
<p>Naked objects is compatible with the trend towards agile development methodologies in many different ways, but especially to fine-grained iterative development.  The DSP experience (described above) was probably also the largest application of agile software development techniques within a public-sector organization, worldwide.<ref name="PawsonWade2003">{{cite conference |last1=Pawson |first1=Richard |last2=Wade |first2=Vincent |title=Agile Development Using Naked Objects |series=[[Lecture Notes in Computer Science|LNCS]] |volume=2675 |conference=XP'03 |book-title=Extreme Programming and Agile Processes in Software Engineering |year=2003 |pages=97–103 |issn=0302-9743 |doi=10.1007/3-540-44870-5_13}}</ref></p>
}}

{{term|term= [[Domain-driven design]] }}
{{defn|defn=
<p>Domain-driven design is the idea that an evolving domain (object) model should be used as a mechanism to help explore requirements rather than vice versa. The fact that a naked object system forces direct correspondence between the user interface and the domain model makes it easier to attempt domain-driven design, and makes the benefits more visible.<ref name="book.haywood">Haywood, D., [http://www.pragprog.com/titles/dhnako/domain-driven-design-using-naked-objects Domain-Driven Design using Naked Objects], 2009, Pragmatic Programmers</ref></p>
}}

{{term|term= [[Model-driven architecture]] (MDA) }}
{{defn|defn=
<p>Although naked objects does not conform to the strict definition of MDA, it shares many of the same goals. Dan Haywood has argued that naked objects is a more effective approach to achieving those goals.<ref name="mda">Haywood, D (2004) [http://www.theserverside.com/tt/articles/article.tss?l=MDA_Haywood MDA: Nice idea, shame about the...]</ref></p>
}}

{{term|term= [[Restful Objects]] }}
{{defn|defn=
<p>A standard for creating a [[REST]]ful interface from a domain object model. Though the Restful Objects specification does not state that the interface must be generated reflective from the domain model, that possibility exists.</p>
}}

{{glossary end}}

==See also==

*[[Direct manipulation interface]]
*[[Object-action interface]]

==References==
{{reflist}}

{{Design Patterns patterns}}

[[Category:Software design patterns]]
[[Category:Software architecture]]