-----Original Message----- Nathan, This is exactly what I'm doing. I'm rebuilding the app that I use for my blog. It was running with one monolithic cfc (over a thousand lines of code), that contained public and administrative functionality.
My plan is twofold, separate the monolith into individual components based on functionality, and secondly secure the administrative functions by moving them into a password protected part of the site, so they're not accessible from the outside, and also, by making them private, ensuring that they'll only be accessible from inside the app. Thanks sas From: Nathan Strutz [mailto:[email protected]] Sent: Thursday, August 04, 2011 4:42 PM To: cf-talk Subject: Re: OO ColdFusion, somebody tell me if this is overkill Oh Dave, you're such a literalist and a pessimist. Since we're talking literals, having a component with nothing but private methods is usually wrong, they will likely change to package access. So there :p I disagree with what you said about reducing complexity. Reducing the number of methods in a component and reducing the number of lines in a file, does reduce the complexity of the file, which can be a serious problem in a lot of applications. If the file is getting unwieldy and excessively large, splitting out functionality (in a logical way) is always a good idea. However it does add another complexity of having more files. Realize that the reverse of this is a single-file-do-all-spaghetti-chaos application, but taken normalization to an extreme gives you hundreds of useless files. Your software will be always be complex. How you handle it always matters. Finally, "changing architecture" is exactly what Scott was asking about in the first place, even though he didn't say it directly. nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Thu, Aug 4, 2011 at 1:05 PM, Dave Watts <[email protected]> wrote: > > > Sounds like it's not a terrible idea. The pattern you're looking toward > > moving to is called the Service Pattern. It puts an interface into your > > Model. It's a good strategy if you are trying to reduce complexity (like > > number of functions in a component), split out concerns (like public > versus > > private), accommodate a changing architecture (like you're doing), and > > especially if you will expose any of your application through web > services > > later. > > I think you're assuming facts not in evidence here. The OP didn't > mention any potential reuse or services layer. And simply creating two > classes from one doesn't reduce complexity, it just moves it around. > Finally, it's extremely common for classes to contain both private and > public methods - objects are supposed to manage themselves without > exposing implementation details, and that's what private methods let > us do. Simply separating private and public methods into two objects > doesn't really solve any problem if you're simply going to extend the > class with the private methods in one new class. Finally, there's no > mention of "accommodating a changing architecture" in the OP's > question. > > I'm not trying to be unpleasant here, but I just don't see any of > those concerns in the original question. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > http://training.figleaf.com/ > > Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on > GSA Schedule, and provides the highest caliber vendor-authorized > instruction at our training centers, online, or onsite. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:346556 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
