Technology

I found some notes I took in 2004 at a lecture I attended on coupling. It may have been a lecture Dave Thomas gave at CJUG.

Decoupling your code:
coupling: you can change something, and something else changes too
Methods calling methods: hard to understand, hard to maintain, hard to re-use.

Symptoms: Minor change recompiles the whole system. Unit tests require every jar on the box. Things stop working when you change their context. Hard to partition project between subteams.

Treat code like spy cells: limit interactions, if one is broken all others are safe, enforced structure.

Some coupling is good. Some code must call other code. Make it deliberate.

Types of coupling: Static, dynamic, domain, temporal.

Static coupling:
Classes are staticly coupled if one needs another to compile.
Java has interfaces. Good to couple to something more abstract. Gang of Four says to program to interfaces.
Interfaces reduce coupling. Split intent from implementation, single point of abstraction. Interfaces != list of class’s methods.
Inheritance is also static coupling. What if parent class changes?
Different rules for inheritance. Java: easy to inherit, hard to delegate. Inheritance is okay for “is-a”, bad for “has-a” or “uses-a”. Business world – not many uses for “is-a”, more “has-a” and “uses-a”
How to delegate?

Dynamic coupling:
happens at run-time. method chaining: order.getCustomer().getAddress().getState()
coupling question: what can change? What can break? Those methods can change.
Start by asking what caller is doing. Express intent at point of call.
Large-scale coupling: Compiling is transitive: a -> b, b -> c, then a -> c
can be circular.
use observer pattern: can break circular chains. Linear chain: add a layer. Mediator class. Is that a GoF pattern?
Mediator: construction manager. You deal with manager, manager deals with subcontractors. manager negotiates between subcontractors.

Subsystems: Things that need to be coupled tend to cluster. make each a subsystem. Ex: java package. Put a facade on a package. Security: read facade, read-write facade, returned via factories.

Domain coupling:
Business rules in code. When rules change, code must change. Value can be parameterized. Behavior can be too. Use interpreter. Interpreter pattern. Define action codes (pick out verbs)
Activate: A
Upgrade: U
Ship: S
Referral: R

Add strings of action codes to database.
Action code: idea from cobol. Do a search. Book idea: Cobol Principles for Java
not GoF intprepter pattern. Give users a screen to link product and actions.

Temporal coupling:
Coupling in time: dependence on sequence of events. imposing a sequence where none is needed.
Recommended: first edition of Bertrand Nayer’s book
Invariant: something that must be true. Invariant must be true at all times.
Design for concurrency. Do stuff in parallel. use a state machine. Can use mediator pattern. Threads: hard, okay with hash maps. Processed-based: RMI, SOAP. Message-based: JMS

Static coupling: reduce with interfaces, facade, delegation
Dynamic coupling: reduce with mediator, command pattern, express intent at point of call
Domain coupling: reduce with metadata, interpreter
Temporal coupling: reduce with monitor and maintain class invariants, synchronize correct places, parallelism

Image from Wikimedia, assumed allowed under Fair Use. Image from the Vatican Virgil, a 5th century manuscript of poems by Virgil.

On 2004-06-24, Alan Shalloway of Net Objectives gave a talk on design patterns at my then-employer. Here are my notes.

2004-06-24 – Patterns
Net Objectives -> Alan Shalloway, author of “Design Patterns Explained”
Boeing: Great internal education
Gang Of Four: Difficult book to understand
GOF: Using terms differently
AS: Looking at patterns differently, will also look at analysis
Adding functionality:
Where is the problem? Writing new code, integrating it into the system
Integrating is more difficult
Must accomodate change (not predict change):
identify special cases, abstract out commonalities, containing no more than one variation per class
Design from context: big picture to small, not small to big

Patterns can be architectural, design, idiomatic (language-specific)
Patterns describe relationships between entities (objects) in your problem domain,
handling variation and new ways of using inheritance come from inheritance

Patterns work on many levels: analysis/motivation, design, implementation
Think of them as “software patterns” – gives some “why” as well as “what”

use pre-existing solutions
some patterns deal with modifiability
design is not synthesis, but differentiation

3 perspctives:
– conceptual: what you want, requirements
– specification: interfaces of classes, how objects “talk” to each other
– implementation: code itself

Mop, broom and sponge: same and different
as specific object: different
as concept: all cleaning objects

abstract classes: concepts, never instantiated, define interfaces

person -> clean -> utensil interface (mop, broom, sponge)

encapsulation: ususally thought of as data hiding
can think of it as hiding classes -> derived classes
implementation hiding, type hiding, data hiding

Objects at different levels:
implementation: data with methods
specification: objects are contracts they implement
conceptual: entities with responsibilities

do not use inheritance badly
lots of switches (coupled) or inheritance
switches are coupled: if you must change one you have to change them all
sales tax: different class for each country

guidelines:
design to interfaces (interfaces in general sense)
favor object aggregation over class inheritance

consider what varies in design, encapsultate the concept that varies
– find what varies and encapsulate it in a class of its own
– contain this class in another class

use cases: “writing effective use cases”

cohesion: focusing on one thing
coupling: dependence of different actions

Commonality/variability analysis
From Jim Coplien – Multi-Paradigm Programming for C++
Thesis online
abstract: emphasize what is common, or ignore what is different
find commonalities relevant to problem domain

challenges in finging commonalities: we are data-centric,
objects usually thought of as “intelligent data”, instead of as behaviors
variability: makes sense only in a given commonality
frame of reference
it is a variation of commonality

commonality: gives architecture longevity
variability: makes it fit for use

commonality -> perspective (conceptual), specification -> abstract class, interfaces
variability -> implementation, specification -> concrete classes

patterns are about relationships

Matrix for CVA

case 1 case 2 case 3
behavior 1   implementations for behavior 1
behavior 2   implementations for behavior 2

Look at patterns in terms of their motivations, not just what they do
switches are okay if they are in one place
can use abstract factory to instantiate the implementations – separates construction from use
Joshua Bloch: Effective Java

www.netobjectives.com/dpe2nd – go to seminars too
Timeless Way of Being: Alexander
ezine: info @ netobjectives.com – subscribe

Image from Wikimedia, assumed allowed under Fair Use. Image from the Vatican Virgil, a 5th century manuscript of poems by Virgil.

I read an article from a few months back in Business Week about cloud computing. There was a chart about the size of data.

• A binary digit is a bit
• 8 bits is a byte
• 1,000 bytes is a kilobyte (10 to the 3rd power)
  
• 1,000 kilobytes is a megabyte (10 to the 6th power)
  
• 1,000 megabytes is a gigabyte (10 to the 9th power)
  
• 1,000 gigabytes is a terabyte (You can start using the monster truck “SUNDAY!! SUNDAY!! SUNDAY!!” voice here) (10 to the 12th power, aka trillions)
• 1,000 terabytes is a petabyte (10 to the 15th power, aka quadrillion)
  
• 1,000 petabytes is an exabyte (10 to the 18th power, aka quintillion)
  

With regards to terminology, this was as far as I went.

• 1,000 exabytes is a zettabyte (10 to the 21st power, aka sextillion)
  
• 1,000 zettabytes is a yottabyte (10 to the 24th power, aka septillion)
  

 

Image from Wikimedia, assumed allowed under Fair Use. Image from the Vatican Virgil, a 5th century manuscript of poems by Virgil.