CF.Objective

OOPs, part III: Gazintas and Coumzatas

I have a confession to make. I'm not doing anything new in this series of blog entries.

Yep, that's my confession. I'm not inventing, creating, designing. I'm simply reiterating things I'm picking up from all the sources I've been reading and rephrasing, or refactoring it, in my own special way. What I'm really trying to accomplish is to condense all of what I'm learning into something that can be used as a resource by others. It's a challenging process.

Personally, I think in metaphor, especially when trying to analyze something complicated. If I can analogize to several different contexts, I can condense the analogies into a fairly substantial understanding of the original concept. When I realized what was wrong with my understanding of OO, I realized it in terms of the alternator on a car.

"What's an alternator?"

That was the question that popped into my head after Sean's gentle rebuff.

What's an alternator?

It's the thing in your car that keeps the battery charged. Right?

And that's when the difference between OOP and PP really hit home. PP, for all of it's usefulness in very certain circumstances, is not very well suited to abstractions, and is mostly concerned with a direct interpretation of function to be inserted in a situation. PP makes custom-fit solutions that go exactly where they need to, and they fit wonderfully. PP says:

An alternator gets energy from the spinning engine via a belt-and-pulley, and makes this much electricity and puts it in the battery thru that red wire.

And that's an awesome way to describe the function of an alternator. We could even turn the process into subroutines, giving it more flexibility. But if we enact any substantial changes to the environment we're going to be in trouble. We weren't concerned with what an alternator IS, HOW it works, or WHERE it sits, we were just worried about providing the functions needed for what it DOES. And spatial relations are important, because if you need to alter your connections, you need to know where you can connect to what.

And that's the difference that I suddenly saw: OOP describes all the aspects of an alternator, at least all the ones that count. Which is not to say that OOP doesn't make mistakes or even that all relevant attributes get catalogued the first time around. But it DOES leave enough of a foundation that when something needs to change you know where the change needs to occur and exactly where that change will crop up in terms of other fixing that may need doing.

See, OOP isn't nearly as concerned with function, or with the procedures needed to connect an alternator to an engine and a battery. It's concerned with the processes, or forces, that act on a scenario, with condensing them into a cohesive set of units that can both describe and process the aspects of the system, and then using that combination of entities to accomplish the processing of work.

Like the alternator. We have several entites involved:

• belt
• pulley
• stator
• brushes
• wire

We have to assume that stator can't spin without pulley, pulley won't spin without belt, and belt is dependent on something else, external to the alternator. We can assume that stator spinning will induce electricity in the brushes which is fed to the wire, which is connected to some external entity.

So we have 2 interfaces: wire -> somewhere; and belt <- somewhere. Belt takes input, wire returns data. We have described the system, it's interfaces (in very simple terms, but still...) , it's components, and the process by which it's work will be accomplished. We now have a static view of the system, and how it's interconnections will produce electricity from torsional action on the pulley. If we find we need more electricity, we have options, we can increase the size of the windings on the stator, we can reduce the size of the pulley to spin the shaft at a faster rate... but we know where each piece is, what it does, and how it works.

In fact, since each piece only does it's job, depending on the level of your view, we're NOT making electricity, nor do we care about electricity. We care about breaking the system down into the most reasonable of the smallest pieces we can find, abstracting them to a degree that is again reasonable, and then interconnecting the elements until we've described each piece independently. We really don't care that we're translating rotation into electricity and heat, we care that we have a pulley, a wire, a stator, a bracket, etc., and we have the faith to assume that if we've described each one accurately, we will have a well-documented MODEL that will fit the needs of the larger system.

I suppose, for me, the transition is from worrying about "gazintas and coumzatas" (or, input and output) to a substantially different view: The well-done model will imply it's function. It's that simple. Don't worry about what it does, worry about what it IS and how it relates to it's neighbors... from there, it'll tell you what it does on it's own.

But, considering that it's -12F outside, I really must admit that I'm glad SOMEONE decided to turn electricity into heat. Cuz baby... it's cold outside!

Laterz!

posted by Jared @ 9:23 AM