Title: RE: [CFCDev] Newbie approach to Composite Entity pattern.

 

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Roland Collins
> Sent: Wednesday, 12 January 2005 9:30 AM
> To: [email protected]
> Subject: RE: [CFCDev] Newbie approach to Composite Entity pattern.
>
> At the end of the day, you can throw all of the OO concepts,
> patterns, and methodologies out the window if the code you
> write is too complex to follow or maintain.  Using patterns
> for the sake of using patterns is just about the worst thing
> you can do.  Knowing when to use a pattern and when to

I agree to a certain point. In that you could argue using a DAO/DG/BO solution in a basic "blog" for example seems a long winded process, in that why bother having three classes doing various task that are so simple you could almost roll them into one. Lots of reasons in the end, it won't scale as well if you were to throw in more advanced concepts and what not. I think patterns from my personal perspective help in regards to positioning logic more so then actually solving Realistic problems sometimes. What I mean by that is if you really wanted to, you could create a bunch of virtual problems, solve them and later find out that not one of those problems really existed it was just defensive programming. Is that pattern abuse?

I guess certain basic patterns like the DAO/DG work for me in regards to pigeonwholing certain information in specific areas. At first glance I can pickup that logic and run with it.

Another example is a abstractDLFactory.class (ie Abstract Factory Pattern), realistically the chances of me dropping one datalayer for another at runtime is very minimal. I could simply hard-code "USE SQL" inside my manager, removing the overall need for a switching mechanism and reducing your filebase down a bit - even cached object heirachy for that matter.

So what "problems" did this actually solve? Well I could give folk a hands-off approach to changing datalayers via config.xml vs having to dig into code on a few points to change it. Is this really a problem? Especially when a target audience is cfmx developers? Probably not. It could also be accomplished via a simple argument etc..

I guess in the end pattern abuse is very easy to accomplish (from my experience anyway) but in the end its abuse can be construde to have a purpose which really comes down to "eye of the beholder".


> violate it is one of the marks of a truly experienced
> programmer.  OO is tough stuff, and over time, you'll get it,
> but don't think that everything has to be fully OO in order
> to be a proper solution.

Either do I, sometimes the ye-ol procedure approach is just as effective as an OO one. I just prefer to think in an OO-Only approach for now, mainly to learn from, gain momentum in my code skills and find what actual lessons can be learned from OO and Patterns. At the moment I could easily knockup a blog in CF5.0 code (pre-CFC) and it would run probably run just as smooth.

I'm glad at the end of the day that we all talk / rant about patterns and cfmx and when to use them, while still proclaiming we are all newbies at it (well most have anyway) I think by proclaiming that it's a passive way of stating "heres what I personally think, I'm no expert so if you read this, don't follow my thoughts blindly - conjure your own opinion - but what do you think? Does it hold water and can I add 10 experience points against my coding level *think WorldOfWarcraft and your chosen profession is programming, the more you practice the more experience points you get and pretty soon you'll be a level60 coder with uber weaponary (languages) / spells (patterns)*.

Anyway, enough ranting back to codemonkeying...

Regards
Scott Barnes
http://www.mossyblog.com

Reply via email to