The Pragmatic Programmer

1. Chapter 5: Bend or Break The Pragmatic Programmer

2. Decoupling and the Law of Demeter • Write “shy” code. • Limits Visibility • Organize code into modules • Eliminates Unnecessary Interactions • Limit the number of calls to other modules

3. Minimize Coupling • “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. Coupling Problems • 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. Law of Demeter • 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! Metaprogramming

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

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

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

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 Bend or Break

11. Temporal Coupling • Decouple temporally by allowing for concurrency

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

13. Architecture • 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. Cleaner Interfaces • Always design for Concurrency • Considering time ordered can lead to cleaner and more maintainable interfaces. • Promotes interfaces without bugs and surprises.

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

16. Publish/Subscribe • 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. Model View Controller • 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. Coupling • 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