Henry, permit me to add to the list of "Things Henry Ought To Do To Learn Himself Some OO".
1) go download cfunit, mxunit, cfspec, or cfcunit. whatever 2) get quickly acquainted with how to write a test 3) try to write some tests for the code you're trying to build *before you even design it*. (yes, i'm talking about test-driven development. shhhh. don't tell anyone). Try to get a feel for how you'd like to *work with your code* before its written. Basically, tests are supposed to say "here's how I know my code works". So you're forced to ask the question, "how do I know my code works?" this method of thinking about your code is one of several "How do I know if my code is bad OO?" detectors. Not so long ago, I wrote this one app. I didn't use TDD, though I wrote tests kind of after the fact. To test it, I had crap like this: <cfset result = object.doSomething()> assertEquals(someExpectation,result.getSomeObject().getSomeInternalDealio()[1]["SomeStructKey"])> total pain in the ass. I had a design problem, but I didn't know it for sure until after I tried to test it. This is just another way of seconding what Dan said: write code man. write tons of it. if TDD helps you get there, then that's great. Above all, stop your fretting! You are going to make a million design mistakes. Know this: Brian Kotek and Sean Corfield aren't working in your office. They're not signing your paycheck. They're not sitting on your shoulder waiting for you to f**k up and say "Ah, Henry, you're violating SRP! You suck! Your window shouldn't know s**t about your room you moron!". It's OK if you don't get it right the first time. or the 2nd. or the 20th. If Henry's gonna learn to Rock, Henry's gonna have to learn to suck, too. That's why God made the words "Version 2". Because "Version 1" almost always sucks. I think it's awesome you're asking so many questions and really digging in. I hope you're putting as much effort into cranking out code as you are into thinking about the code you're trying to write. marc On Fri, Feb 20, 2009 at 5:59 PM, Nando <[email protected]> wrote: > Henry, > > I'd focus on behavior to help you answer questions like these. Abstract > relationships are there, but the essential is relationships formed around > getting things done - behavior. > > Does Site need to operate on an array of Page objects to do it's job? If > not, then you don't need a reference to all Page objects in Site. Simple. If > it needs to operate on a single page object, one at a time, perhaps you can > store an array (or a query) of Page Id's so you can easily create the object > when needed. > > Does Page sometimes need Site to do it's job. If so, pass a reference to > Site into Page. > > You'll get it wrong, in sense that down the line, you'll realize a better > approach in developing operative relationships between objects. You can't > get around making lots of "mistakes" in OO. It's not like learning syntax, > where you can ask a question or study up a bit and start getting it right > from the beginning. > > Focus on behavior ... make your mistakes. The faster you make them, the > faster you'll learn. > > > On Fri, Feb 20, 2009 at 9:38 PM, Henry <[email protected]> wrote: >> >> Dear all, >> >> Q: Can an object (objectA) has a reference to other object (objectB) >> just for the sake of representing the relationship while none of the >> behaviour of objectA requires objectB? >> >> e.g. In a CMS system that manages many sites: a Site has many Page. >> Page has a reference to the Site to specify which site it belongs to. >> However, none of the behaviour/methods of Page requires Site. >> >> Is representing the many-to-one relationship (many Page has one Site) >> a valid enough reason to have Page carry a reference to the Site >> object? Or having this reference to Site is actually unnecessary? If >> so, how else to specify that relationship? >> >> >> Here's what I think... agree or disagree? >> >> a.) Setting just the ID can represent the relationship without >> reference. But in pure OO fashion, storing siteID in Page seems >> weird, afterall siteID is a PK of the Site table. >> >> b.) If the only reason to eliminate the reference to Site is the >> overhead of creating the Site object, then a SiteProxy object sounds >> like a good fit. So, just store a reference to SiteProxy in Page to >> represent the relationship. >> >> >> Thank you all! >> >> Henry Ho >> > > > > -- > > Nando M. Breiter > The CarbonZero Project > CP 234 > 6934 Bioggio > Switzerland > +41 76 303 4477 > [email protected] > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
