Chapter 5: Bend or Break

 Write “shy” code.  Limits Visibility  Organize code into modules  Eliminates Unnecessary Interactions  Limit the number of calls to other modules

 “We do not want the object to give us a third-party object that we have to deal with to get the required service”  When we need a service it should be preformed on our behalf.  Bad: public void plotDate(Date aDate, Selection aSelection) { TimeZone tz = aSelection.getRecorder().getLocation().getTimeZone();... }  Good: public void plotDate(Date aDate, TimeZone aTz) {... } plotDate(someDate, someSelection.getTimeZone());

 In large projects, the command linking a unit test is longer than the unit test.  “Simple” Changes to one module propagate through unrelated modules.  The developers are afraid to change code because they aren't sure what will be affected.

 Any method of an object should only call methods belonging to:  Itself  Parameters passed to it  Object it created  Directly held component objects (c.print();) ‏

 Changes to details cause problems  So: Get the details out of the code!

 Tip: Configure, don’t integrate.  Use metadata to get configuration data OUT of the code body.

 “Data about data”  Any data that describes the application  Generally, used at runtime  Examples  Windows.ini files  X11

 Program for the general case  Keep specifics outside the main code base  Many benefits*  Leave the details out, so easier to change

 Application:  Find what changes most, and attempt to code your program in such a way that you can change the metadata to adapt.  Don’t write dodo code

This isTemporalCoupling Decouple temporally by allowing for concurrency Standard CouplingContent

 Analyze workflow for concurrency  You already do it normally  Design using services  Independent  Concurrent  Consistent interfaces

 Taking advantage of temporal decoupling makes programs easier to write.  Use queues to decouple tasks.  Multiple threads can feed off the queues.  The hungry consumer model replaces the central scheduler with multiple independent consumer tasks

 Always design for Concurrency  Considering time ordered can lead to cleaner and more maintainable interfaces.  Promotes interfaces without bugs and surprises.

 Modules accomplish well-defined responsibilities  Once those are created, how will they communicate?  Events signal other modules that “something interesting happens.”

 Objects should only receive events they need  There should only be one publisher to send events.  Subscribers need only to register with the publisher to receive event notifications.

 Separate views from models.  Provides flexibility  Allows from non traditional multiple controllers.  Model. Abstract data model representing the target object.  View. It Subscribes to changes in the model and logical events from the controller.  Controller. A way to control the view and provide the model with new data. It publishes events to the model and view.

 Listeners and event generators still have some knowledge of each other: They must agree on common interface definitions.  There even more are ways of reducing coupling.  Web applications

 Shared memory space  Originally intended for AI systems  Allows for a totally decoupled system  Content coupling  Temporal coupling  Single, consistent interface