Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The problem with the idea that all your objects know how to display themselves is that each object can only be displayed in one way. What happens if you want to provide a detail view of a user, and a summary view. What happens if you want to display a view that merges a number of objects (users and their associated addresses for example). If you seperate your business objects (users) from the things that know how to display them then you have no more code to write, you just seperate it into different places.</p> <p>This makes software more maintainable because if a user object is behaving incorrectly, you know it is the user, if it is not displaying properly, you know it is the view. In the situation where you need to provide a new interface to your application (say you decide to provide a new look and feel for mobile browsers), then you dont need to change your user object at all, you add a new object that knows how to render the user object for a mobile browser.</p> <p>SOLID principles provide some good reasoning for this, <a href="http://mmiika.wordpress.com/oo-design-principles/" rel="nofollow noreferrer">here</a> is a relatively concise look at these. I am afraid that I dont have a book to hand that sums it up well, but experience has taught me that it is easier to write new code than it is to update old code, and so designs that favour small modular classes that plug together to achieve what is needed, while harder to design up front, are far easier to maintain in the long run. It is great to be able to write a new renderer for a user object, without ever having to delve into the internals of that object.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload