jaredrobinson.com

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

Tags: mtnwestrubyconf, mwrc

This entry was posted on Saturday, March 14th, 2009 at 2:46 PM and is filed under Programming. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.