1. Chapter 5: Bend or Break

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

3.  “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());

4.  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.

5.  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();) ‏

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

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

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

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

10.  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

11. This isTemporalCoupling Decouple temporally by allowing for concurrency Standard CouplingContent

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

13.  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

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

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

16.  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.

17.  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.

18.  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

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