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 On Jun 25, 2008, at 1:55 PM, Ronan Lucio wrote: > 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: >> >> 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 <[EMAIL PROTECTED]> >> 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 >> >> >> >> >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
