Jim Weirich: The Building Blocks of Modularity
Interview questions:
– What tech books have you read lately? To guage their interest in continued
learning.
– How do you recognize a good design?
Someone said they’d come and listen to him talk about oatmeal. So guess what?
He’s going to talk about oatmeal.
At one time, the thought was that matter was like a bowl of oatmeal, that it
was fairly consistent all the way through with maybe a few lumps. Someone shot
a particle emitter at a thin strip of gold, and found out that that wasn’t
true. Matter is like a bowl of oatmeal with rasins and apples in it. That’s
when scientists started developing their atomic theory. Several forces in the
universe: Gravity, Electromagnetism, Strong Nuclear, Weak Nuclear. Why should
there be so many different forces? They tried to come up with Grand Unified
Field Theory, and they’re still working on it.
In computers, we have some principles we use to write software:
– SOLID
– Law of Demeter
– DRY
– Small Methods
– Design by Contract
– etc.
Is there a grand unified theory of software development? That’s what he wants
to think about and discuss today.
Everyone should have a mentor when they get started in their careers. He did.
Coupling & Cohesion. The connection between modules, and how well a module
itself fits together. Less coupling is good. Too much coupling is bad. Seven
different types of coupling, according to Meyers:
– None
– Data
– Stamp
– Control – when you have do describe the func with the word “or” or “otherwise”
– External
– Common
– Content
Which boil down to local data and global data, and whether it’s simple or
structured data.
A simpler way to thing about coupling: Connascence – things that are born together and change together. If two pieces of software are tied together so that changing one requires changing the other. Rule: As the distance between software increases, the conanascence between the two should be weaker.
Connascence of Position (with parameters to methods) versus Connascence of Name
(using a hash to pass parameters). The latter is better when there’s a large
number of parameters.
Connascence of meaning. I.E. Don’t use magic numbers in your code.
Contra-nascence – when it doesn’t matter what magic number you assign to two
different constants, as long as they aren’t the same.
Connascence of Algorithm. If you change a checksum checking func, and you have
to also change the corresponding function that generates the checksum.
Connascence of timing, of value, etc. This entire talk is on github: git://github.com/jimweirich/presentation_connascence.git