> 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:346539 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
