Refactoring To Reuse #2

#2 Separate Presentation From Domain Entity

Many projects that you undertake might have a presentation component to it – it could be a browser based app, thick client on a desktop, or even a kiosk-type interface. Regardless of specific the presentation technology, you have to ensure that your domain or business logic is effectively decoupled from the user interface code. This is in fact the foundation of the Model View Controller design pattern. You can move business logic in the model layer, presentation logic in the view layer, and the glue code that orchestrates across user actions and domain entities into the controller layer. Often times this separation might not reveal itself in a clean way. In those cases it is important to refactor the code appropriately.

Here is an example – say you have a class named Organization which holds a collection of Units and a collection of Employees. For the sake of integration ease, the Organization class contains a toString() method that generates HTML markup code that formats an Organization object into a neat nested table structure. If you change the way the markup is generated or change rendering output format from HTML to PDF you will end up touching the Organization class. Not a good idea from a reuse standpoint. You want Organization to be about the business entity and nothing else. The fact that it was generated for a web application should be decoupled from the core domain object. You can refactor this class in a number of ways. One way to refactor would be to remove HTML code from the object’s toString() method and move it to a OrganizationFormatter class. This new class could be in a new package structure that is specific to a presentation. If you envision need to support multiple formats you can make OrganizationFormatter an interface and have multiple implementations – a HTMLFormatter, a PDFFormatter, and so on. Based on need a SimpleFactory can be used to return the appropriate formatter at runtime to generate the output. Regardless of the format, you can reuse the Organization class as-is.

Another case where this is needed is when your domain entities make assumptions about the user interface layer. This would require refactoring for enabling reuse as well – will elaborate on this in a future post.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Advertisements

One Response to Refactoring To Reuse #2

  1. […] connectivity earlier so in this post I will expand on formatting logic and is a continuation of the earlier post on formatting. Just like any other aspect of your design you can make formatting as complex as you need. The key […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: