Doubts about Best Practices

[Ronan Lucio]

Hi,

I have two doubts hitting my mind:

1) What is the best way to populate foreign keys into a bean?

Supposing I have a class Product.
Each product has a Category.

What is the right way:

beanProduct = serviceProduct.getBean();
beanProduct.setName( "It's name" );
beanProduct.setCategory( 1 );

or

beanCategory = serviceCategory.getBean( 1 );

beanProduct = serviceProduct.getBean();
beanProduct.setName( "It's name" );
beanProduct.setCategory( beanCatebory );

or neither?

2) In CF community we use to talk about DAOs and Gateways but it doesn't
seem a widely used pattern.
What is the best usage? Have just one DAO as Row Data Gateway and
Table Data Gateway or use DAO as RDG and Gateways as TDG?

Thanks,
Ronan

[Greg Stevens]

Hey Ronan,

AI have some thoughts on #1. It is the OO way to create the
beanCategory and go beanProduct.setCategory(beanCategory), however
this doesn't translate well to the database. What I have been thinking
is that the product bean would have not just 1 attribute for Category,
but 2. One that represents the category's id and another that
represent's the category object.

Product
-------------------------------------------------
categoryId : int
category : Category
-------------------------------------------------
getCategoryId() : int
setCategoryId(int) : void
getCategory() : Category
setCategory(Category) : void
-------------------------------------------------

This is where I break some patterns out there, but I like to have a
slightly smart bean so I would end up having it so that when
Product.getCategory() is ran, it returns
CategoryDAO.findById(getCategoryId()). The only problem is this means
that the CategoryDAO would need to be injected into the Product. Would
it make any sense at all to just inject a ProductsDAO into the
product, inject the CategoryDAO into the ProductsDAO and then have
ProductsDAO.getCategory(productBean) return CategoryDAO.findById(...)?
Is this where the Gateway may be useful?

[Brian Kotek]

On Fri, Jun 20, 2008 at 2:49 PM, Ronan Lucio <lis...@tiper.com.br> wrote:

Hi,

I have two doubts hitting my mind:

1) What is the best way to populate foreign keys into a bean?

   Supposing I have a class Product.
   Each product has a Category.

   What is the right way:

   beanProduct = serviceProduct.getBean();
   beanProduct.setName( "It's name" );
   beanProduct.setCategory( 1 );

   or

   beanCategory = serviceCategory.getBean( 1 );

   beanProduct = serviceProduct.getBean();
   beanProduct.setName( "It's name" );
   beanProduct.setCategory( beanCatebory );

   or neither?

I would create a Factory that would create the product, populate it with any passed data, as well as creating and populating any composite objects. This way the logic for populating the object and resolving its dependencies is encapsulated within the factory.
 

2) In CF community we use to talk about DAOs and Gateways but it doesn't
seem a widely used pattern.
   What is the best usage? Have just one DAO as Row Data Gateway and
Table Data Gateway or use DAO as RDG and Gateways as TDG?

I'd actually say the opposite: not only is it widely used, it may arguably be over-used. It's become somewhat common to see every single table in a database have corresponding Gateway objects and DAO objects. I personally don't separate single-row persistence behavior in a DAO and aggregate behavior in a Gateway, I just have a Gateway and it does both. I also don't necessarily have separate Gateways for every single table, but rather group the behavior logically. So I may have forum, thread, and message tables in the database, but I may group the SQL for these together into a ForumGateway. In other words, just because the tables are there doesn't mean there must be separate DAO and Gateways for every one (nor Services for that matter).

Hope that helps?

regards,

Brian
 

Thanks,
Ronan

[Greg Stevens]

Sorry Ronan, I was treating category as a 1:1 relationship. Just
replace my getCategoryId() with getCategoryIds()...the rest should
still be applicable.

[Alan Livie]

I sort of agree with Brian but found I rarely touch DAO objects once they are in place but often have to add stuff to gateway objects (new report or new complicated SELECT query the dba wants for performance reasons).

So following the 'encapsulate what varies' idea I keep them separate.

Alan
________________________________________
From: cfc...@googlegroups.com [cfc...@googlegroups.com] On Behalf Of Brian Kotek [bria...@gmail.com]
Sent: 20 June 2008 22:06
To: cfc...@googlegroups.com
Subject: [CFCDEV] Re: Doubts about Best Practices

[Brian Kotek]

Fair enough. Since I use Transfer I don't have to deal with "DAO" type CRUD stuff anyway, so my gateways tend to be for aggregate/reporting queries anyway. But in the cases where I'm not using Transfer I do just leave them in the Gateway as well.

[Adam Haskell]

At the end of the day we all need to stop talking about DOA and Gateways and all this Database crap as much as we do. Its old, trite, and quite honestly doesn't make a hill of beans difference most of the time. Honestly, ask yourself, "How many applications would I have been completely screwed if I chose to split my gateway and DAO up, or vice versa?" If you have a use case for that please by all means share it I'd love to hear it. If all we are concerned about is DAO or gateway then chances are something else, much more important, is being overlooked (not pointing fingers at anyone here :) ). If all you are doing is a large reporting app chances are you don't need to be doing complete OO anyway, yes I know sacrilege. Its true though ColdFusion is perfect for reporting without the heavy OO we try to apply to it in too many cases. Thinking back through some of the reporting apps I did and shoehorning them into an OO architecture I can confidently say I should have stuck with a light version of MVC and moved on.

Adam Haskell

[Dan Vega]

Adam,
I am sure you going to hear some slack for that but I am huge fan of what you just said. In Hal Helm's presentation he noted that we really need to quite being so data centric when thinking of OO development. MVC is a great start for people to solve a specific problem but everyone really needs to stop following everyone and thinking that 5 cfcs are OO development. I am doing a lot of research at the moment about OO in other languages and hope to share my findings soon.

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org

[Peter Bell]

Well, if you want to see OO in different languages, I'd look at:

Java - high ceremony, good for large apps

Ruby - low ceremony - very dynamic. Just remember not to blow your leg off

Smalltalk - The granddaddy of OO languages but still used in some domains. Check out seaside for a continuation based web server. Very interesting and I'm hearing it scales better than I'd have expected. I think it'd dabbleDB that was written in Seaside.

Best Wishes,

Peter 

[Dan Vega]

I have a good friend who is a Python developer as well so I hope to pick his brain. I am just saying that I think Adam has the right mind set, we really need to stop talking about DAO,Gateways & Service layers as the end all be all.

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org

[Brian Kotek]

This is caused in a large part by the code generators that introspect the database and generate CFCs. While those can be great time saving tools, the reality is that most people just take what gets generated and then run with it without thinking further about what they're doing.

This is why we get people with 5 CFCs for every single table in their database, and why people think that just because they're following these "patterns" (bean, DAO, etc.) that they are doing OOP. If everything is data-centric and there is no actual behavior in the objects, then all one really has is a totally procedural, data-centric application that has been shoved into CFCs. It really ends up being the worst of both worlds: all the complexity of OO with none of the benefits.

Hal is completely correct that we need to get away from the fixation on data or slavishly following patterns without really understanding the tradeoffs involved. Each pattern has consequences, and not all of them are good. The unfortunate reality is that truly groking OOP takes a long time and a major shift in mindset. There's no easy route to getting there, but one route that is probably among the most difficult is to blindly apply patterns or let code generators "do the work" without truly understanding what's going on or why these patterns exist.

[Peter Bell]

Hi Dan,

I don't think we ever did! It's a useful set of J2EE patterns. I personally use a service class and DAO per business object as it allows me to gen apps much faster than creating a custom set of mappings between service classes, business objects and DAOs. I like the service and DAO patterns as I find a good separation of concerns. I implement a custom data mapper in my base DAO and all works well for my use case. That said, look in Smalltalk/Ruby/Python and you'll see class methods used in place of Service singletons and you'll see some apps which abstract db access and some that don't. I think it is great to look at the various patterns. I personally think they're a little more evolved in Java than in C# and in Ruby than in Python (Python, like CF isn't *that* OO - 2.5 still has a couple of different ways of creating objects, a bunch of headless functions, primitives, etc), but you can learn something from every community. Looking forward to your postings!

Best Wishes,

Peter

[Dan Vega]

Great stuff Brian, I think you hit the nail on the head in that many people do something without really understanding why they are doing it.

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org

[Sean Corfield]

On Tue, Jun 24, 2008 at 10:49 AM, Brian Kotek <bria...@gmail.com> wrote:
> involved. Each pattern has consequences, and not all of them are good. The

This is the key issue I tried to raise in my design patterns talk at
MAX last year (there's a recording on UGTV of the preso I gave later
to IECFUG I think).

So much of the patterns talk shows pattern + code instead of pattern +
tradeoffs which is by far the more important aspect of patterns.

> unfortunate reality is that truly groking OOP takes a long time and a major
> shift in mindset. There's no easy route to getting there, but one route that

Agreed. But when I tell people that, sometimes they react badly
thinking I'm being elitist or implying they are "too stupid" to learn
OO. The reality is: it's hard. I started learning OO in '92 and my
first few years worth of code was embarrassing. Fast forward 16 years
and I'm still learning and shifting my focus on OO issues.

One of the key lines in Hal's preso was "forget the database" and if
you want to design a reasonable OO system, you really do have to try
to do that. Clearly, if you have a very data-centric app with almost
no "behavior" (i.e., it's almost pure data entry or pure reporting)
then OO might be a waste of time for you - or maybe only parts of the
app will benefit from OO, perhaps at a very high level in the service
layer.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Peter Bell]

Thats why I tend to prefer code gen/frameworks that start with a description of the model and then gen any persistence required if your use case (read no DBA and a green field app) allows it. 

Best Wishes,

Peter

[Sean Corfield]

On Tue, Jun 24, 2008 at 11:05 AM, Peter Bell <pb...@systemsforge.com> wrote:
> Thats why I tend to prefer code gen/frameworks that start with a description
> of the model and then gen any persistence required if your use case (read no
> DBA and a green field app) allows it.

Maybe it's time (finally) for OOBDMSs to come back into favor? :)

[Sean Corfield]

On Tue, Jun 24, 2008 at 11:06 AM, Sean Corfield <seanco...@gmail.com> wrote:
> Maybe it's time (finally) for OOBDMSs to come back into favor? :)

OODBMS. *ahem*

[Dan Vega]

I think Sean brings up a really great point here. In very data centric applications (bunch of forms and reports) a light mvc pattern to help seperate your model and view might be all you need. Maybe only certain features will follow a pattern. Its your job to learn the patterns and as Sean said always be mindful of them.

"if you have a very data-centric app with almost
no "behavior" (i.e., it's almost pure data entry or pure reporting)
then OO might be a waste of time for you - or maybe only parts of the
app will benefit from OO, perhaps at a very high level in the service
layer."

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org

[Peter Bell]

I find the OO still helps for data mapping even in fairly simple, data centtric apps. I love to be able to ask for User.FirstName, User.LastName, Boss.Title and Auctions.TotalSpent and get that without having to write the left outer joins and aggregates by hand. But maybe that's just beause I suck at SQL :-)

Its also nice to be able to Order.getAssociated("Items") or Author.getAssociated("Articles") - I find that stuff is just nice.

Best Wishes,

Peter

[Dan Vega]

At the same time you have something that just "works" for you Peter. I think what concerns me is on top of what Hal and even Adam said. People are doing things because that seems to be what everyone else is doing. If it works for you and you are productive and you don't find yourself questioning your methodology that is all that matters at the end of the day.

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org

[Matt Williams]

On Tue, Jun 24, 2008 at 1:08 PM, Dan Vega <dan...@gmail.com> wrote:
> I think Sean brings up a really great point here. In very data centric
> applications (bunch of forms and reports) a light mvc pattern to help
> seperate your model and view might be all you need. Maybe only certain
> features will follow a pattern. Its your job to learn the patterns and as
> Sean said always be mindful of them.

I may be somewhat naive in what type of apps people are building, but
I would guess that a good majority of apps can really be described as
data centric. Any e-commerce site is basically that. Any customer
management app is basically data centric. Calendars & events - data.

While I know blindly running with the 5-1 cfc is not a good way to
learn OO, I have found that the DAO / Gateway works and does make app
maintenance easier. Encapsulating the CRUD and other "aggregate"
selects makes the queries much easier to reuse. As does having a
service layer that provides an API to get to those queries.

Yes, we shouldn't argue about if the DAO & Gateway should be one CFC
or not; that is more of a personal preference. But I don't think we
should dismiss the usefulness of this for these "data centric" apps,
which seem to be quite common.

--
Matt Williams
"It's the question that drives us."

[Peter Bell]

Hi Dan,

Well, I have something that just works for me because I question my methodology all the time! I do agree though that in all communities (including Java, Python, PHP, etc) OO (and design patterns like MVC) can become "cargo cult programming". That was really what my RAD OO presentation was about - examples of where breaking the conventional wisdom was an appropriate choice given the design forces for a given use case. I still love that I'm breaking MVC in two different ways and it's working quite nicely for my use case.

Best Wishes,

Peter

[Brian Kotek]

Even more to the point, from what I can tell many (even most?) CF applications *are* data entry or reporting applications. This seems to be changing over time but is still the case for a lot of apps. While I would be the first to say that anyone who wants to continue to be a programmer beyond the next few years absolutely needs to learn OOP, that doesn't mean that every app needs to be full-on OOP. Learning it is critical: the market has spoken and OO has won. I don't just mean in CF but in application development in general. Sooner or later (and probably sooner), folks without an understanding of OO are going to be marginalized. It's happening more slowly in the CF world than with other languages, but it will happen. It's a big challenge to be sure (at least it was and still is for me) but the elephant in the room cannot be denied.

But it isn't all doom and gloom. The bottom line is that OOP actually *is* incredibly powerful and that the effort put into learning it *does* make one a better programmer as well as being more "marketable". It might not seem like it durning the most painful moments in the long learning curve, but there is actually light at the end of the tunnel! (I see it up ahead, it's dim, but I see it!) ;-)

[Dan Wilson]

This is an appropriate and timely thread for the community which, at large, needs a heavy dose of pragmatism on a regular basis.

In my refactoring session, I cover some stuff that isn't really considered patterns per se, but rather techniques for pulling out behaviour from procedural code. I tell the audience that Extract Method and Extract Object are probably the most useful and most used refactors they will use in their application refactoring, but they won't sell patterns books. We then step into some procedural code and pull out the behaviour.

These sorts of things aren't celebrated academically, nor do they sell books. Maybe lacking a nice name and a concrete description really prevents this from being talked about enough. I can say that both Extract Object and Extract Method  provide a mechanism to get more object orientation out of code.

DW

--
"Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew."

Guillaume Apollinaire quotes

[Dan Vega]

Peter,
Just like you I  am always questioning myself. I wish to be writing much cleaner more efficient & scalable applications so that is my real reason for posing these questions & sharing my beliefs. So far so good, this is some good stuff!

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org

[Brian Rinaldi]

Hal made some great points that philosophically I agree with but that I think you'd be hard pressed to find a company willing to implement it (mostly talking about larger companies with established IT depts). For instance, he said the model should drive the database and not the other way around. Great, I agree....but the reality is that most companies you are working with a database that pre-existed the web app or a database dictated by a DBA group that is not closely tied to the developers...etc. The point is, we can talk all these very high-minded ideals but they tend to run aground when put up against the entrenched system at a typical company (which is probably why OODBMS's never caught on in the first place). That separation of database expertise and programming expertise was probably created for a reason...though don't ask me to explain why (we programmers tend to think we should have domain over everything...and though I agree I am fairly certain I am wrong ;).

Anyway, it is, to me, a matter of understanding the difference between the "best solution" and the "best available solution". 9 time out of 10 (especially at big corps or govt) these two don't match. Depending on your organization the best available solution may be many degrees worse than the best solution but its generally better than the "current solution". Its a matter of understanding the limits of ideals.

This is the piece I told Hal at dinner I thought he missed. Code generators and ORMs are probably a philosophically poor solution to a problem since they do tend to create very data-centric models but they are a solution nonetheless. So, when you get all the Acme Corps on OODMS's, then I might reevaluate :)

--
Brian Rinaldi
blog - http://www.remotesynthesis.com/blog
ColdFusion Open Source List- http://www.remotesynthesis.com/cfopensourcelist
Boston CFUG - http://www.bostoncfug.org
Adobe Community Expert - http://www.adobe.com/communities/experts/members/brian_rinaldi.html

[Dan Vega]

Well I think that most of us are glad to know that this very issue is not one that just the CF community faces.

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org

[Brian Kotek]

On Tue, Jun 24, 2008 at 2:26 PM, Matt Williams <mgw...@gmail.com> wrote:

I may be somewhat naive in what type of apps people are building, but
I would guess that a good majority of apps can really be described as
data centric. Any e-commerce site is basically that. Any customer
management app is basically data centric. Calendars & events - data.

This is true, of course. Every application has to use or manipulate some form of data. But I think the idea (at least on my side) is that when I say a "data-centric application" I mean literally that. Apps with virtually no actual behavior. A contact management app with a master-detail view and a data entry form. A reporting tool that queries a database and dumps out tables or graphs. These kinds of thing are extremely common, and are essentially nothing but a direct pipeline between the browser and the database: form > query > html table.

Now an e-commerce site, on the other hand, I would say is probably going to be much more complex. We're getting into business rules (What's on sale? What discount tiers do I give to various customers? How do I calculate shipping and tax rates? What algorithms determine what featured items are on the home page?) Depending on how robust and feature-rich the application is, these can all get very involved and complex. And the business rules will probably change constantly. So this is where an OO approach would probably provide much more benefit. I suppose I'd say that the more rules there are and the more parts of the application are subject to change or variation, the more sense OO makes.

[Dan Vega]

What if we were to start a problem/solution type of either collection / wiki / google doc for now that does just this.Brian had some great points that there are so many pieces to a an ecommerce application. When you break the application down there are so many places where thinking in an OO approach would really benefit our application. I think the more "situations" we as developers see and program ourselves to think that way the more it would become second nature.

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org

[Adam Haskell]

Ronan and others, I didn't mean to scare anyone away (not that I was accused of this, yet) by my comments. The above thread and the following discussion may not get you any closer to understanding a DAO or a service layer, or entirely answer the posted question. It probably will not get you any closer to understanding how to architect a shopping cart either but what it will do is get your mind working. Far too many times it is too complicated or time consuming to really get into the nitty gritty of a system on a board.Instead what you have before you in this thread is a breadth of knowledge and opinions from various people in the CFML community all colliding into one spectacular brain dump. These are the types of discussions I think we need more of I'm just disappointed it happens only around conferences :(  I think we as a CFML community are still going through our elastic reaction to the introduction of OO into our language. The recoil is beginning to happen and we need to be mindful to find the proper balance of OO, where/how it fits and where it does not. Don't be afraid to disagree with me or anyone else. Do not blindly follow; try and disagree, challenge the norm. I very much disagree with Peter sometimes but I'll damned if i don't have respect for him putting himself out there and trying.

Adam Haskell

On Fri, Jun 20, 2008 at 2:49 PM, Ronan Lucio <lis...@tiper.com.br> wrote:

Hi,

I have two doubts hitting my mind:

1) What is the best way to populate foreign keys into a bean?

   Supposing I have a class Product.
   Each product has a Category.

   What is the right way:

   beanProduct = serviceProduct.getBean();
   beanProduct.setName( "It's name" );
   beanProduct.setCategory( 1 );

   or

   beanCategory = serviceCategory.getBean( 1 );

   beanProduct = serviceProduct.getBean();
   beanProduct.setName( "It's name" );
   beanProduct.setCategory( beanCatebory );

   or neither?

2) In CF community we use to talk about DAOs and Gateways but it doesn't
seem a widely used pattern.
   What is the best usage? Have just one DAO as Row Data Gateway and
Table Data Gateway or use DAO as RDG and Gateways as TDG?

Thanks,
Ronan

[Mark Mandel]

Good conversation, and definitely a direction I find my coding practices going in these days - more pragamtism.

This is the piece I told Hal at dinner I thought he missed. Code generators and ORMs are probably a philosophically poor solution to a problem since they do tend to create very data-centric models but they are a solution nonetheless. So, when you get all the Acme Corps on OODMS's, then I might reevaluate :)

I don't know if I entirely agree with this, in that if you start modelling first, and then build a DB that will support that model, and ORM / code generator will give you the OO model you want. That being said, if you have a legacy DB, or you start developing DB first, then, yup, you will have to jump through some hoops to get to where you want to go OO wise - or you may not get there at all.

Mark


--
E: mark....@gmail.com
W: www.compoundtheory.com

[Sean Corfield]

On Tue, Jun 24, 2008 at 3:32 PM, Mark Mandel <mark....@gmail.com> wrote:
> I don't know if I entirely agree with this, in that if you start modelling
> first, and then build a DB that will support that model, and ORM / code
> generator will give you the OO model you want.

Agreed. I'm in an environment where I can still design and build a
decent OO model but have a seasoned DBA construct the schema and then
I can map between the two - the whole point of ORM really.

> That being said, if you have
> a legacy DB, or you start developing DB first, then, yup, you will have to
> jump through some hoops to get to where you want to go OO wise - or you may
> not get there at all.

And what a lot of people seem to forget (or not want to deal with) is
that you can always write adapter objects to enable your nice, clean,
well-designed business object model to map onto a (completely
different) nice, clean, well-designed relational data model.

[Peter Bell]

Code gens and ORMs are NOT bad solutions per se. They are only bad when they are db centric. The whole point of an ORM is to handle object:relational impedance mismatch so it actually facilitates the easy persistence of rich object models. To say code generators are db centric is like saying programmers are db centric. They are as db centric as the templates and the metadata they use. Those that start with the db model to gen the object code ARE db centric and usually not all that useful which is why I always recommend starting with rich metadata describing a real object model and annotating that with persistence metadata to allow for the object model and persistence to be fairly decoupled.

Best Wishes,

Peter

[Tom Chiverton]

On Tuesday 24 Jun 2008, Dan Vega wrote:
> really need to stop talking about DAO,Gateways & Service layers as the end
> all be all.

I (used to) do that because (I used to) spend a lot of time doing them.
Now, with AOP, Reactor etc I don't have to pay much attention at all :-)

*However* we do still need to keep talking about OO, because there are a vast
number of CF developers out there (well, at Scotch anyway !) that are not
using OO at all - and building some fairly large apps.
Maye their code is very good, but I bet taking an OO approach (yes, maybe
using a Pattern or two) would make it better.

--
Tom Chiverton

****************************************************

This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500.

For more information about Halliwells LLP visit www.halliwells.com.

[Tom Chiverton]

On Tuesday 24 Jun 2008, Dan Vega wrote:

> doing things because that seems to be what everyone else is doing. If it
> works for you and you are productive and you don't find yourself
> questioning your methodology that is all that matters at the end of the
> day.

Something that came out of the 'requirements and estimating' talk Peter did at
Scotch was 'what if you could be *more productive*'.

[Ronan Lucio]

Hi Adam,

At first I'd like to thank you to share your thoughts in the thread. Thats good.
I'm really happy with comments and the evolutions of the thread.

Not trying to change the thread's focus, but I will add a comment:

from Brian:

"Hal is completely correct that we need to get away from the fixation on data or slavishly following patterns without really understanding the tradeoffs involved. Each pattern has consequences, and not all of them are good. The unfortunate reality is that truly groking OOP takes a long time and a major shift in mindset. There's no easy route to getting there"

from Sean:
"Agreed. But when I tell people that, sometimes they react badly thinking I'm being elitist or implying they are "too stupid" to learnOO. The reality is: it's hard"

Agreed. It's true.
But... people should have a start point to learn OO.
And... the main one is the practice (and books, simultaneously).

When people goes to the practice they tend to follow the models used by the big architects. That's good.
I don't thing it is "to blindly apply patterns". Because it's just a start point, the initial architecture.
As way as the project grows the programmers will see why some patterns apply and others not.
I think this is a (my) way to learn.

In most of case it's not good to disagree with some patterns because we still don't feel ourselves in the same level of experience in OOP than all of you.
Thats why we prefer to ask instead of argument.

It's just my thoughts.

So, why the same question (DAO x Gateway) hits the same mailling list often?
Because it was never answered in a common. (well, perhaps it don't has - so the doubt remains).

I don't know until where it's good or not.
In one hand everyone have to have yours thoughts and feelings about OOP for the patterns continues to evolve.
In the other hands the CF community doesn't have a set of Best Practices for OOP.

Should it do? I don't know - just a doubt that hits my mind.
Everything has pros and cons.

Although having a set of patterns can lead programmers to blind his/her OO skills or break some evolution, it would bring more programmer to the group of the betters - those who worry to do a good job.

Although NOT having a set of patterns can force programmers to think and better understand OO patterns, it could break a migration from spaghetti code programmers to OO patterns.

A good example of how good is to have pattern to guide are the books Martin Fowler's books that always are a good reference for every good programmer.

Just to think about, once some personalities in this list are the references in the CF community all over the world.
What a responsibility, no?

Thanks,
Ronan

Adam Haskell escreveu:

[Peter Bell]

Just one general comment. Check out the Dreyfus model of skills acquisition. When people start learning, they need recipes to follow. Then over time they need to try stuff and make mistakes. Finally they internalize the rules and can come up with "appropriate design decisions". It's actually perfectly OK to start off with recipes. To try to do anything else is to misunderstand the learnign process.

Best Wishes,

Peter

[Brian Kotek]

On Wed, Jun 25, 2008 at 1:55 PM, Ronan Lucio <lis...@tiper.com.br> wrote:

Agreed. It's true.
But... people should have a start point to learn OO.
And... the main one is the practice (and books, simultaneously).

Very true, which is the point I was trying to get across. The only way to really internalize the thought process behind OO is to read (a LOT) and experiment. What works and doesn't works in various situations will begin to become apparent.
 

When people goes to the practice they tend to follow the models used by the big architects. That's good.
I don't thing it is "to blindly apply patterns". Because it's just a start point, the initial architecture.
As way as the project grows the programmers will see why some patterns apply and others not.
I think this is a (my) way to learn.

This I'm a bit less sure of. The danger in following the models used by "the big architects" is that they do what they do based on a relatively complete understanding of the tradeoffs involved. When a newcomer looks at that, they may (and often do, it seems) assume that the decision for that particular context applies to all similar contexts. This is where the problems can occur, because it is very possible that the approach being studied may not be suited to the problems that the newcomer is dealing with. In that case, this will have the opposite effect: building and maintaining the application that they are working on will actually become much more difficult or complex than it may need to be.

Part of the difficulty in understanding patterns, at least for me, is that one generally should not look at a pattern and then try to find a place to use it. Rather, one should wait for a problem to arise and then look to patterns for a possible solution.
 

In most of case it's not good to disagree with some patterns because we still don't feel ourselves in the same level of experience in OOP than all of you.
Thats why we prefer to ask instead of argument.

Asking is always fine; that's what this list (and others) are for, after all. I think the general idea is that people should try to be pragmatic about OO and try their best to build up an understanding of it. There is really no easy shortcut, but reading books and answering questions can help during the journey. I still read an embarassing number of books, blogs, etc. on the subject since, as with many things, the learning process is truly an ongoing thing.
 

So, why the same question (DAO x Gateway) hits the same mailling list often?
Because it was never answered in a common. (well, perhaps it don't has - so the doubt remains).

If you mean the general idea behind using a DAO or Gateway to encapsulate interaction with an external resource, I don't think there is a great deal of disagreement on the subject. And if you mean specifically which one is best (or to use both), that actually seems more of a matter of personal preference than anything. As long as one is getting the benefit of using them, the specific details of where you put what is rather unimportant.
 

I don't know until where it's good or not.
In one hand everyone have to have yours thoughts and feelings about OOP for the patterns continues to evolve.
In the other hands the CF community doesn't have a set of Best Practices for OOP.

I would say the "best practices" for CF OOP are very similar to the best practices for OOP in any other language. So the basic underlying principles that drive the whole thing (favor composition, design to interfaces, encapsulate what varies, tell don't ask, etc.) apply to us just as much as they do in other languages.
 

[Ronan Lucio]

Hi All,

I'd just like to thank you all for the replies with your valuable opinions.
I agree with most of said in the thread and it helped me to clarify some
things in my mind.

Thanks in advance,
Ronan