>I really believe people do not organize things correctly. First, the exe at runtime executes most easily by just calling the specific function. The organization of things at design time is not relevant to the organization at runtime.
>
>Here's an example of runtime and designtime organization impact.
>
>I'm now working with someone's excel class. Excel itself is organized as Excel (Application), then WorkBooks, then Sheets. So why then does this class force me to call a function at the highest level to access a cell content of the sheet? Answer: it was not considered where the methods should be placed. I constantly have to pass the workbook and sheet numbers as parameters, instead of getting a reference to the sheet and calling the method from there. That incorrect organization at designtime is definitely impacting how I grok the tool as well as performance at runtime.

Having to use references with several dots repeatedly definitely is bad design, simply calls for some refactoring - locally at least. Specially with COM objects, where getting a reference to the next sublevel doesn't go so quickly as in Fox's own objects. Whenever I had to deal with Excel I kept one reference per level - oExcel, oWb, oWS and then ranges as needed, so then to incur the cost of getting a reference to the next member as few times as possible.

OTOH, speaking of god objects - why do you think everything in Office has a reference to .application? They may be crazy, greedy, dirty and whatnot at Redmond, but they aren't stupid.