I've moved the Blog...
On the very off chance that someone bookmarked this blog, I've moved it to my home server pending a permanent location in conjunction with the company's website and on a server at a better host.
I'm moving off blogger because they're having performance issues, the comments often don't work, and I dislike not having direct control over important sites. Besides, Ray's blogger package is really cool.
I would have just put it at our regular URL, but I chose Ray Camden's blogging app and it uses absolute paths... which I can't do at this host. So I moved it to the server I CAN control, and I'll have to make do with a crappy URL for a while.
Anyway... if you have a bookmark, the site's been moved to here.
Laterz,
J
Mach-II Monday: Tears, and Sunshine
Well, I managed to pull it off... with a wee bit of help.
I have a working OO class for doing a2rss conversions (which isn't exactly right... it applies the supplied XSLT to the supplied XML doc and returns the resulting document) that I wrote last night. So since I have to start the handheld app for the client, I decided to run thru the Mach-II process using an HTML form to supply the URLs/paths.
First of all, setting up the app was a snap, thanks in large part to Trond's previously mentioned newbie doc and a few key points I'd missed in my reading. Setting up the first event, the form, and the view was easily done in Homesite+, and setting up the listener to connect with atomCFC's API was also very easy.
All-in-all, I found my first real venture into OO to be fantastically rewarding. Things went together better, stayed together better, and were more flexible than I've previously been able to accomplish. I think the assembly went faster and, frankly, now that I'm much more familiar with CFCs than I used to be, the whole process is pretty cool.
But, I found something about Mach-II that I really don't like. Anymore, it won't be an issue, but I think it's counter-intuitive, and since there's enough CFOO newbies, I'll mention it because I could NOT find the answer anywhere.
In the Mach-II.xml file is a common set of entries, and I emulated them to the letter:
< event="feedRSS" access="public">
< listener="feedListener" method="getRSS" resultkey="request.rssText">
< name="feed" contentkey="request.content">
That makes a great deal of sense to me, and fits with my overall impression of the framework. "Take resultKey from listener, supply it to request.content for transmission to the page. Great, a built-in transfer object... my presentation is automagenically abstracted from my logic. Hoorah!
Nope. Ain't so. And nobody, but nobody that I could find had explained where the resultKey went after it had been returned to the resultKey. I changed contentKey to the same as resultKey, and it quit erroring out, but I had absolutely no content.
Well, apparently, as Yoda explained it, the framework sets resultKey to the value returned by the listener. What contentKey actually does is aggregates content, for things like composite pages, so that you can compile several different contentKeys and output them in mainTemplate.cfm, for instance.
This, I think, makes no sense. I would prefer to see the view-page attribute named resultKey for aggregating results... and the contentKey attribute capable of retrieving a value from the event object. It's consistent, more aptly named, and separates view from logic to a greater degree.
That would give us something like this:
< event="feedRSS" access="public">
< listener="feedListener" method="getRSS" resultkey="rssText">
< name="feed" resultkey="content.part1" contentkey="rssText">
When it executes, the listener method returns the resuts of method, which gets inserted into event.{resultKey}. ViewHandler would then:
setContentKey("{contentKey}", event.getArg("{resultKey}"))
Once setContentKey executes, {contentKey} is available in the request scope, which acts as a conduit between the model and the interface. The specified view is implicitly either rendered to the screen or passed back to whichever module handles aggregating screens for podlike outputs based on the presence of a resultKey attribute in the view-page tag.
It just makes more sense to me, I guess...
But, it was explained to me that I could use the event-arg tag in the event-handler block to move the data from the resultKey into the event object:
< event="feedRSS" access="public">
< listener="feedListener" method="getRSS" resultkey="rssText">
< name="rssText" variable="request.rssText">
< name="feed">
Which, I assume, would mean either writing an event facade to give a view access to event data, or using event.getArg() calls to return data to the screen. I like my idea better, though.
I really DO like the idea of using the request scope as a conduit, and I really do like the Mach-II ideal for MVC and even-driven applications. The thing I don't like is the strange naming convention and lack of abstraction from listener response -> request scope -> view.
Anyway, I am now... (checking...) going on 7 hours late for my trip to the gymn, so I must leave. However, despite my travails, I DID get it to work (with a little help from my friends) and the end result can be viewed here. Let me know what you think!
Laterz,
J
atomCFC - Atom-to-RSS nears beta
First and foremost, big thanks go out to Sean once again, for his patient mentorship and sound advice. And now, on with the story...
So tonight I was asked about my proposed (but unmentioned here, unfortunately) atom-to-RSS feed. I decided I'd better get started on it right then and there, so I said "Yeah, it's almost done" and started writing it. Hey, it's short, so it really was almost done even before I got started.
The story behind it is this: On Tuesday last I began a frantic search for an atom converter to feed RSS aggregators 'cuz Sean told me he'd proferred my blog to fullasagoog.com (which totally rocks!) Unfortunately (or fortunately, depending on how you look at it) the only one I found was missing a namespace attribute in the Items section. The owner of that site was also offering the xsl sheet for download (here) so I grabbed a copy and rewrote enough of it to fix the issue and wrapped it in procedural CF as a fast fix and sent the new URL to the goog. And it worked great.
So, atomCFC is about 95% finished. I have it set up thusly:
Really, there's 2 main methods (5 public altogether):
init()
atomToRSS(atomURI string, xslPath string, xslURI bool = false)
atomToRSS is simply a wrapper for the next 3 methods, I added it because I was planning to use this as a webservice... but it didn't work like I expected so I need to learn more.
The other public methods are:
importAtom(atomURI string)
importXSL(xslPath string,xslURI bool = false)
createRSS()
For both atomToRSS() and importXSL() the xslURI boolean tells the method whether the value in xslPath is a URI (true) or an absolute file path (false), with the default being absolute file path. I've tested it with both local files and remote files, and it does work both ways, so I was pleased.
And finally, createRSS() takes no arguments. It verifies that importAtom and importXSL have executed and if so simply executes transform() against the two values and passes the resulting XML string thru the parsing engine to the setter for rssXML. At the moment, if either importAtom or importXSL (EQ "") it simply exits... I'd rather have it throw an error, but not tonight.
So once I had it working, I went back to the location that I was using to feed the goog and replaced the old procedural code I had running there with the CFC and an index.cfm... lo and behold, the goog didn't even notice. I'm pleased. Very pleased.
But for now, no more throwing errors till tomorrow when I've had a bit of sleep. If you want to see the CFCDoc page for atomCFC, feel free to hit this page for a look.
Cheers!
Mach-II beginning Monday
I've chosen my first production Mach-II app, and starting Monday I'll begin developing it and blogging my experiences as a total Mach-II newbie trying to put together my first real OO application. I'm looking forward to it.
The application will be an HTML interface scaled for portable devices (targeting IE on Windows CE and WebPro on the Palm) for the business agents at my current primary project. The current app is effectively a beta version, and it's done procedurally using CFCs, but I'm planning on reworking it into OO on top of the Mach-II framework. The handheld tools are due to be done now, and I decided that rather than do it in PP then redo the whole thing later, I'd just do the handheld piece OO and take that experience into redoing the larger application.
Sean Corfield blogged about Trond Ulseth's newbie experience with Mach-II and I'll be using his experiences as a guide in addition to having dug through the demo apps myself.
The Mach-II website says "Mach-II is a web-application framework focused on easing software development and maintenance." Hal Helms, Sean, and Ben Edwards are the project's primary contributors, and have done a lot of hard work.
I look forward to seeing it in action on my own projects.
What this is, what this isn't...
This blog is about my experiences learning CFOO "on the hoof," as Sean Corfield put it in his blog, about the transition from PP to OOP, and a collection of my thoughts and feelings as I assimilate all this new information. This is an OO blog, and it's about a transition from PP to OOP by an enthusiastic adopter of OO in CF.
It's about juxtaposing my previous experience against my new experiences, and about the difference it makes in my work and my life. I have been careful to speak my mind about OO and it's potential and yet not denigrate the work and experience of those who continue in the PP vein.
Overall, at least from my perspective, I've been saying "OO has the potential to be more sustainable in the enterprise, lends itself to standards compliance (OO standards until we've compiled CF standards) and to give CF a wider venue. I would prefer to inherit an OO app over a PP app. OO can give CF a deeper acceptance and penetration into markets that previously only accepted Java and .NET. There will always be a place for PP, even if it's supporting legacy apps, but OO is the key to opening more doors."
I was about to go into another rationalization... but those who agree already know why I think what I do, and those who disagree would probably not be swayed. It's all been said so many times it seems silly to say it again.
What I will say is this: there's a huge difference between a freelancer who can set his own guidelines, develop his own frameworks, and use the tools he creates for his own style; and the CTO who's thinking about developing a new online presence in an enterprise that has policies on development practices for its own protection. OO has already been established and gained acceptance in the Java market, .NET, C++, even VB; and OO is a mandate in many corporate venues. Adding OO and OO skills to the CF community is going to open the doors to those venues whereas before they simply could not by nature be open to us.
Maybe that's what I've been trying to say all along. PP's always going to be there, but I'm switching because I see the alternative as superior, and as opening previously closed doors. If you don't agree, that's fine. I disagree back... hehe.
I'd like to thank...
I've been meaning to take a little time and post some thank-yous to folks who've had an impact on my career over the years and recently. So, here goes...
Tim Goyer
Introduced me to CF in 1998.
Ben Forta
Wrote the CFWACK, without which (actually without 3 or 4 of which) I would never have gone anywhere. Ben's work has been critical to the growth of CF... while he ain't alone in his work, he's the earliest in my experience.
Dan Chick, Tom Lommel and Troy Pullis
3 Minneapolis CFUG managers over the last 5 years... the heroes of the CF community on a local level. Thanks guys!
Sean Corfield
Teacher, new friend, and the dude who opened my eyes to the essential nature of OO.
I'd been fighting with "what is OO" since I was... oh... 12? I was developing shareware in HyperCard, and someone told me "it was OO" but nobody could explain "OO" other than "it's objects." Consequently, like countless others, I developed a skewed sense of what object orientation means, until someone with enough patience finally said just the right 4 words.
Commenters in my blog
Every exchange between myself and those who leave comments in my blog gives me another set of insights into how I communicate, what others are thinking, and bits of information that I may have been missing in the past. I appreciate people taking the time to make an exchange of information. If we agree or disagree isn't really the point. What matters is that we've had the opportunity to enhance our understanding. Thank you.
I think it's one of the more powerful things about blogging, actually, that you get disagreement and even contention. There are those on the net who argue pointlessly, just for the sake of being argumentative, and who have nothing of value to add. There are those who seem that way at first but upon deeper examination really aren't, and whose comments give food for thought.
And, in closing...
I believe that texture is what makes things interesting... try climbing a mirror, then try climbing a cliff. Texture is what makes it possible. All these folks have added to the texture of my life in different ways. Some I've known for ages and some I've never directly communicated with at all. But they've kept me from being 2-dimensional, and for that I'm grateful.
Laterz!
cf.Objective - Minneapolis, 2006
I'm commited to generating (or trying to, anyway) interest in a second CF-centric national event in Minneapolis, hopefully in 2006. My dad asked me if it was going to be in the family room... heh, yeah, if it has to be. I really believe that the CF community would benefit from a second national conference... if for no other reason than flexibility and variety.
So if you feel inclined to comment, positive or negative, then please, by all means do. I'm mostly concerned with getting a feel for how many would be interested in attending and if anyone would be seriously interested in presenting.
I've got another blog entry on the subject here which says more about concept and why I don't think it could or would conflict with CFUnited. Be aware that this is in such a stage of newness that *nothing* is etched in stone, so anything regarding content is simply brainstorm.
Hammers vs. Foreheads: Pounding needs, driving questions...
I've heard lots of rationale against using OOP in CF applications, and I've even resisted it myself, perhaps because of peer pressure if for no other reason. I've heard it asserted that OOP "makes no sense" and that "simple questions are impossible to answer." But, if you understand it, if you reach out to grasp new concepts, you realize: OOP isn't about non-logic. OOP isn't about procedure. And purposed code isn't reusable.
We can debate this ad-nauseum, but I have learned enough to know that OOP is the future of CF unless want it to stay in the limited-run, limited-traffic site category. Having recently made the transition from PP to OOP, I can only say with conviction: It's a subtle, but essential shift that's the only vehicle to enterprise-class applications.
"Applications" being the key word. Understanding the transformation of CF from a tool to quickly create dynamic WEBSITES to a tool that can do that as well as create full-steam-ahead enterprise-class web APPLICATIONS is where we as a community go wrong. But a database-enabled website is not a web application, and if we're going to develop more and more applications we need to adopt standards and practices that have proved, repeatedly, to empower applications and the people that create them.
We can, and should, still use the old methods for situations where they're appropriate. Absolutely no argument there. For a simple, straightforward site that displays data on pseudo-static pages and with limited traffic I'm perfectly content to consider the old-school CF development style. However, after having seen commercial site after commercial site start in CF (probably because it was so strongly touted as a RAD tool, and comparitively inexpensive) and almost as quickly show up converted to ASP, Java, even Perl or PHP, I am tired of watching CF get a black eye every time I turn around.
It's design and architecture that cause these sites to fail, not the language, and yet CF is often blamed for these failures. And now that the underpinnings of everything we do are Java-based, and we can apply the full power of Java's core libraries to our development, if we simply implement the most powerful new tools at our disposal we can engage our profession in greater and greater projects.
I suppose what it boils down to is a shift away from something I read by Ben Forta. I can't recall the source, but Ben expressed the idea that CFers aren't programmers... they're developers. At the time, he was right. Now, it's much less true. But the beauty of CF is the fact that those who choose to can remain developers... and those who choose to evolve beyond that and begin to forge ahead in the "New Context" can do that too. We can now, with a fair degree of ease, become programmers.
I'm not going to, nor would I at any point in the foreseeable future, say that PP no longer has a place, nor that the only good site is one built on FuseBox or MachII or any other particular framework. But, to say that OO and CF should never be mixed, or to assert that we shouldn't apply the vast amount of information available from millions of man-hours of reasearch into enterprise software development is equally as short sighted.
So, while I absolutely respect the skills of those who are proficient in CF and the amount of knowledge and skill they have in applying CF to solutions, I utterly diagree with the idea that PP is better for CF, and would even go so far as to say I think it's a fairly irresponsible position. At the very least it's completely unfair and one-sided. Then again, we get to express the counterpoint and it gets us hits to our blogs. Perhaps it's a challenge, to me (as the new OOP evangelist in the Minneapolis CFUG), to prove the point, and make OO more logical and less confusing. I'll do my best, I promise.
Laterz!
I would proudly like to announce...
my goal, to see a national CF event hosted here in Minnesota in 2006. I would like to see "cf.Objective 2006" become a reality. I'm currently seeking input into the idea, trying to recruit sponsors and speakers, and attendees... actually the attendees are the important part. Have enough of those and speakers will just... show up. Right?
Ok, maybe not, but it still helps.
I realize that CFUnited is an important part of the year, and that them being smack-dab in the middle of summer makes picking a date a royal pain, and that these things are expensive to put on. So I see challenges and opportunities... what else is new?
What I don't see is cf.Objective and CFUnited as competing events. We all benefit from more choice, and each event is colored by it's attendees and presenters. And I'd like to bring CFers from all about the land to our lovely Tundra (hey, that -58F cold snap was 200 miles away. It's only been in the negative teens this week here... downright balmy!)
I'm also frustrated that event after event and tour after tour is hosted from Anaheim to... ummm... Yonkers? and nothing ever hitting one of the most beautiful areas in the Midwest. Aside from missing out on some beautiful territory, we Midwesterners must always travel to these things, and that in spite of the thriving Macromedia-centric community we have here.
Besides, in September it's usually very lovely weather, and once the leaves start to change it's one of the most amazingly beautiful places on Earth.
I would really like to see the event here in Minneapolis (or possibly Duluth) in 2006, and with the support of our local community, the CF community leadership, and generous corporate sponsorship from the show's benefactors, I think we can pull this off most happily. (Depending on how things work out, we may even see Flash UG folks, and Flash developers, since the boundaries of CF and Flash are shrinking faster than ever!)
Considering the recent changes in CF and Blackstone's upcoming debut, I'm hoping to see presentations on things like Running Multiple Instances on Apache, CF/Flash Remoting Best Practices, Street-level MachII, and OO for the Procedural Organism. Of course these are just imaginary titles, but they communicate some of the vision I have for this even.
Something else I'd like to see is more interactivity in the sessions, and I don't mean between presenters and the audience. I mean I'd like to see real training, hands-on "here's a machine for you to use and let's now go thru the steps to write an XSL transform from this to that" kind of training.
In light of all this, I have opened a new gmail account, so please email any ideas or comments to: cf.objective@gmail.com
Thank you,
Jared
Slow day
It was a slow day today, spending most of the afternoon at a doctor appointment. Don't worry, I'm fine... it was just a checkup.
As I contemplate my upcoming presentation to our Minneapolis area CFUG, I have two thoughts:
"You idiot, you've barely scratched the surface of OO and framework, and now you're planning to present on it? What's the matter with you?"
... and ...
"I really like the pizza they always have at the CFUG meetings."
Ok, there, I've admitted to it, I like cold pizza (can you tell I'm usually late for the meetings?)
But seriously, I've come to OO after programming as a hobbyist since I was nine years old, and after developing professionally for five or six years. I've tried to get my head around OO for ages, and it's finally happened. I understand the paradigms, and why I have come to believe it's a superior method for developing applications. THAT'S really what I'm planning on presenting about. My process, and what I've learned.
I want to present to the folks the fact that there's a difference between a webApplication and a webSite, and that when it comes to applications, I believe OO methodologies are superior, and I can explain why. It will be a hard sell, as it always is.
I've come to believe that if we don't pick up on things that our OO-based Java cousins have known for years, we're effectively doomed. I really think that as CF and Blackstone become more and more well known the developers who actually use legitimate Best Practices and good application design will continue to find work and those who don't will fade. Now that our platform of choice has been incorporated into the Java world anyway, we're going to at least have to learn how Java's Best practices affect us, and how to incorporate those techniques, among other things, into our tool boxes.
Don't worry... there'll always be a language or an environment for people who prefer procedural development. Even legacy COBOL applications need tweaking. And it's excellent that they're out there and that people will have work to do. Legacy CF apps will persist for a long time, and people who simply refuse to adopt OO will be available to assist with their maintenance and growth.
But if OO can be presented in a non-threatening way, and I can help one person understand not why procedural is bad but why OO is superior in many different context, then I'll be happy. If not... well, I always like a challenge, and both learning OO and making it's case for my colleagues are challenging!
Just some evening thoughts, as they spill off my fingers into blogland...
Laterz!
OOPs, part V: Suddenly not so classy
Well, this is interesting.
And frustrating.
Trying to figure out where to put what in a class diagram felt very natural, and things made sense. However, that which I expected to be easiest... my sequence diagram... is proving to be a great challenge. But, I think I'm getting it.
For some reason, this isn't feeling quite as intuitive, still not that bad, but it's taking some work to get things like who's doing the calling and who's doing the answering, the fact that set and get are reflexive terms, and how to use the interface for Together to model some of my init methods (they get too wide for the screen sometimes).
I think the hardest part of the process was figuring out where to start. UML2 allows an initial signal to be represented by a line coming in from the edge of the diagram, representing that which initiated the sequence... but Together doesn't really seem to like that idea much. Maybe I'm just doing something wrong. However, once I decided that I'd start the diagram from the perspective that the listener object was already instantiated and it's Configure method was called (basically, I'm imagining the kickoff signal is really there) I could at least get started.
Oh, I know why Together won't let me do an input signal on the chart... I'm using UML 1.4 rules to draw the chart. Duh... ok, so it's like 4AM and I'm beat. I was at friends house gaming all night last night (if you read my profile you'd know I like RPGs) and decided to check in with my model before going to sleep. I missed it... I'm having fun with this.
I think the thing that I like best about this whole process is that it makes you do what math teachers call "prove your answers" or "show your work." Use cases are like your scratch notes, from where you did math on paper instead of in your head. A Class Diagram is sort of like writing out a neat representation of the problem's components and the proposed answer, and a Sequence diagram is like the part of the answer where you show each operation as you, say, do an algebra problem, to prove why or how you ended up with the answer you gave.
The other thing that I like about this process is... well, there's 2 other things. Or two parts of the same other thing. Part the First is the fact that I am able to approach a problem and document my concept, so I really have the feeling of being in control and able to understand what I'm up against and my answer to it. Part the Second is that if I'm needing verification of my ideas, since I'm documenting them in UML it's very easy to send the diagrams to someone for verification. Since UML is fairly standard (each environment having a certain "dialect" I'd guess, but overall very similar) I can just show the diagram to someone and behold, they know instantly what I'm proposing. Gives one a deep feeling of security.
However, it's now only about 10 minutes shy of 5 AM, and I'm beat. I'm going to bed, and don't wake me up unless it's important. Thank you. *g*
Laterz!
OOPs, part IV: Salt and Peppa
Another metaphor occurred to me a few minutes ago...
Scenario:
I'm at the table eating bland food.
Procedural fix:
Susan, would you pass me the salt?
OO fix:
Use case:
Eater wants salt
Eater salts food
Eater requests salt from person closest to it
Person closest to salt gets salt
Person closest to salt hands it to Jared
Class diagram:
:eater
-------------------
- saltManager: saltManager
-------------------
- getSaltManager: saltManager
- setSaltManager: void
- saltFood: boolean
:saltManager
-------------------
- saltAdapter: saltAdapter
- saltLocation: String
-------------------
- getSaltAdapter: saltAdapter
- setSaltAdapter: void
- locateSalt: String
- dispenseSalt: void
- saltFood: boolean
:saltFactory
-------------------
-------------------
getSaltAdapter: saltAdapter
:saltLocator
-------------------
-------------------
- getSaltLocation: String
:saltAdapter
-------------------
-------------------
- getSalt: salt
- setSalt: void
And now you ask me WHY ON EARTH I went to that much trouble just to locate the salt...
Because, I answer, I now know exactly what I'm doing, I'm not dependent on Susan, and I don't really care where the salt is. I've covered the all the bases in my model of the salt transaction, AND I've abstracted the idea of getting the salt from Susan to a collection of modules.
Now, I can say this:
- set Jared = new eater()
- Jared.setSaltManager()
- Jared.getSaltManager().locateSalt()
- Jared.getSaltManager().getSaltAdapter(locateSalt())
- - saltManager executes locateSalt(), which transiently executes :saltLocator.getSaltLocation(), and has returned to it "Susan" for step 6:
- - saltManager calls saltFactory with the output of #5 as an argument
- Jared.getSaltManager().getSaltAdapter().getSalt()
- Jared.getSaltManager().saltFood()
And if I want to parameterize saltFood to get finer-grained control over how much salt I dispense, I can simply modify saltFood and the one place that it's called... from saltManager.
I can even... whoa... turn this into a Condiment API, and abstract even further by creating :condiment and setting ketchup, salt, pepper, and so on, into subclasses (inheritance applies because salt IS-A condiment, pepper IS-A condiment, and so on).
Now, if I haven't experienced a condiment before but it's added to my DiningRoom application, I can simply configure a new subclass... say tartarSauce... or I can take a different pattern and create :condiment as a superclass with 2 children named :sauce and :powder, and then make :salt, :pepper, and :pizzaCheese into subclasses of powder, and :ketchup, :mustard, and :tartarSauce into subclasses of :sauce.
It doesn't matter, because I've modeled the process of getting a condiment and applying it to my food. The function is implied in the classes and their properties/methods, and handlers have been created for the transactions that need to occur between the core classes.
Each class is cohesive (highly specialized)
Each class is loosely coupled (not directly dependent on anything else to do it's job)
My model is flexible, and I'm able to easily expand on it by simply repeating the same patterns for each further level of abstraction. AND, if I reach a point where the manager/factory/adapter idea is no longer efficient, I have an unlimited number of other patterns and frameworks from which to choose.
Now, where did Susan go? That girl is always running off... sheesh!
Laterz!
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!
