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