> My God object merely serves to hold the metadata pathing (like database > path, reports path, etc.) as well as some generic routines (like > FirstDayOfWeek, etc.). Things of a specific nature I do break up into > smaller objects and only instantiate as needed.
Now all your smaller objects assume that god object to exist and have FirstDayOfWeek, database path, etc. on it. Personally, my preferred method is to have a single global singleton 'factory' object with a simple defined 'create' or 'get' method that you pass in an object name. Then, anywhere in my code, I can request a 'settings' object, and if it doesn't exist it's created, and if it does exist, it's returned. This settings object holds my database path, etc. My actual code logic never assumes a global object beyond the goSCF(global singleton class factory). As for methods like FirstDayOfWeek, I think it's wasteful to put any function on an object when it's not operating in an OOP way. It is simply a function that goes in a function library. In other languages such as .NET, these are implemented as static methods, which makes sense as well for logical segregation. -- Derek _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
