@Henry, I would say avoid getting too involved with UML class diagrams before coding. I agree with "Uncle" Bob Martin when he says UML is something that is best when drawn on a whiteboard to quickly show others in the team your ideas - then rubbed out afterwards.
Trying to create your domain model in a UML class diagram before coding IMHO is REALLY DIFFICULT. It's also argued that class diagrams alone will probably lead to a BAD DESIGN unless you are also creating sequence diagrams at the same time. As Nando said the key is behaviour and it's hard to model behaviour well in class diagrams. I would echo Marc and say write some tests and there's a better chance you'll put your working code in the correct place, have a cleaner API and conform to the key principles. Also, when using TDD you are initially thinking about 'how I would like to interface with this object' and 'what name will I give this method'. As a result you are focusing on your API or interface first and worrying about implementation second. So rather than pondering 'should a site have a reference to page?' just start building the core functionality of a site (or page) and you'll soon discover your dependencies. Pick a use case, scribble down the tests you think you need, pick a test and start coding I prefer the 'small steps' way of coding to the 'big picture up front'. If you're learning OO like me the big picture up front can be daunting! And as far as mistakes go, I make them every day. I finished a project yesterday and can already see some flaws in my design. Refactoring ticket in Jira (no time for a refactor now) and I move on to the next project, confident I wont make the same mistake twice ... 'fool me once shame on you' etc! Alan ________________________________ From: Henry Ho <[email protected]> To: [email protected] Sent: Saturday, February 21, 2009 12:21:58 AM Subject: [CFCDEV] Re: To Reference or not to reference... that is my question LOL.... don't make me laugh so loud at the office! Thank you very much guys. Much appreciated. I'm actually spending time now drawing UML class diagram... moving things around, before I start coding. Nice tips! And yes, I'm using cfspec. :) Regards, Henry Ho On Fri, Feb 20, 2009 at 4:16 PM, Marc Esher <[email protected]> wrote: 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 -~----------~----~----~----~------~----~------~--~---
