1. Maths / group theory PhD
2. Encryption – mortgage transfers and Unix
3. Software house
4. Agile / XP
5. Coaching / training in s/w craftsmanship
1. There's a problem in s/w development
2. We'll look at failed solutions
3. Introduce the concept of coupling
4. Look at the properties of coupling
5. Do some calculus
6. Reconsider the problem
First, the Problem...
The TDD cycle
Red
Green
Then what?
Refactoring is hard
No-one does it
No-one knows what to do:
How much?
What to pick?
When to stop?
Now on to the failed solutions
(This section may be a bit of a rant :-)
People don't always know what “duplication” here means
Not all duplicated text is “duplication”
And duplication between Bounded Contexts is often / usually preferable to “fixing” it
eg. build problems from shared library
Plus, not all “duplication” is bad
Ambiguous
Overlapping
People remember their names, but not what they mean
Not clear what to DO
eg. Feature Envy isn't always a problem (eg between bounded contexts)
S, O describe end results – but people think they are things to DO
L can be tested for, but no-one does
I, D are design rules, but no-one understands what they really mean
People don't know about these
(People don't think about packages / namespaces / aggregates as a design tool)
CCP == SRP
SDP == SAP == DIP
And not all dependency is bad
Connascence was introduced and first examined by Meilir Page-Jones
(who has the coolest moustache in CS)
Connascence first appeared in this paper
(Although Yourdon and Constantine kinda mention it in Structured Design in 1979)
You can see in this video still that Jim is talking about connascence
...which is a CONNECTION between different software elements
Connascence has a number of attributes or properties.
These are my names for them, you may see others elsewhere.
Let's first talk about the TYPE of the connascence
Imagine we implement an object that contains a data structure based on a hash table (and for some reason we decide not to use a standard library)
The get() and put() functions must agree on the hashing algorithm to be used
Even if we extract the hashing algorithm to a function...
… both get() and put() still need to call it, and are therefore still coupled by CoA
Now, working with the person next to you, think of other examples of CoA?
Consider this old-fashioned printf call in C...
… there is CoP between the format string and the arguments to the call
With the person next to you, think of other examples of CoP?
Consider a system in which monetary amounts are represented as numbers of pence
There is CoC between everything that has to calculate with those values
… and also among the types of the variables and return types of the functions
Now, in pairs come up with more examples of CoC
NO AUDIENCE WORK HERE
NO AUDIENCE WORK HERE
NO AUDIENCE WORK HERE
Now have the audience suggest examples
Now have the audience come up with examples
Now we'll cover the DEGREE of the coupling
Now we'll cover the REACH of the coupling
Page-Jones defines only 3 encapsulation levels
But in modern programming there are more
Connascence is worsened by crossing the boundary between two encapsulation units
Maybe each of these is a “scope”?
Maybe therefore “block” has been missed by P-J?
Those are the main properties of connascence.
We could also consider whether the connascence is EXPLICIT (obvious) or IMPLICIT, but Page-Jones is quite wishy-washy about this...
Page-Jones gives these as guidelines for maintainability
Can we turn them into an “algorithm” for refactoring?
Everything depends on what we mean by these words
(...and on our “definitions” of the various kinds of connascence :)
We have numbers for level and degree, so let's see if we can rank the types
<group exercise>
Now let's list some properties of this function
<call out and flipchart>