The Ticket object then does what it needs to do to determine the result to return; the calling object does not need to be troubled with the plumbing details.
In addition to eliminating coupling between these objects, it also prevents a potential maintenance nightmare. Let’s say I needed this description String in 150 places throughout my application. Things are fine until one day it becomes evident that the statusDescr property needs to be broken out into numerous different elements. This calls for a new class: TicketDeleteStatusDescription with properties: statusDescr (as is currently used), statusLongDescr, statusDropDownListDisplayText, and statusDefaultText. TicketDeleteStatusDescription becomes an aggregate of TicketDeleteStatus so that our new aggregation relationship becomes:
By encapsulating all of this within Ticket, however, I only need to make one change in the Ticket class. The Ticket class’s getStatusDescr() method – which previously just accessed its deleteStatusDescr property – now needs to be changed to call the TicketDeleteStatusDescription class’s getStatusDescr() method. Thus, the call Ticket.getStatusDescr() used in 150 places can remain as is.
Keep Things S-I-M-P-L-E!
From Rusty Herald's Cafe au Lait Java Quote of the day - exactly what we need to keep in mind in our own efforts! http://www.ibiblio.org/javafaq/
Quote of the Day
...complexity leads to disaster. Your application should be built around simple constructs and understandable layers, which combine to perform complex tasks. The code itself, however, should avoid complexity at every stage. This is much easier to say than to do, though, since many programmers are afraid of missing important pieces, or of oversimplifying.
You don't need to be afraid of doing something too simply if you embrace change in your application. The ability to fearlessly embrace change is based on good testing practices. If your code has thorough, automated, repeatable tests, then making changes to the code loses much of its anxiety. As changes are introduced, the tests will tell you whether or not you are breaking something important. Automated testing gives you a safety net, allowing you to examine simple solutions first, and to change them over time without fear.
--Justin Gehtland Read the rest in ONJava.com: Better, Faster, Lighter Programming in .NET and Java http://www.onjava.com/pub/a/onjava/2004/07/14/BFLJava.html
Back to Thoughts On Technology Page | Back to Peter's Home Page | Back to Family Home Page