Jacob Fugal wrote:

>On 1/9/06, Lyndon Samson <lyndon.samson / gmail.com> wrote:
>  
>
>>On 1/10/06, David Vallner <david / vallner.net> wrote:
>>    
>>
>>>The main advantage of instance variables to global variables is that
>>>they allow you to scope the variables down to -very- narrow contexts of
>>>validity, and they can be hidden outside said scope. If that's what you
>>>mean by "more restrictive variation", then scoping is the restriction
>>>that matters. And giving context to relate global variables via naming
>>>conventions sounds pretty painful.
>>>      
>>>
>>I guess what I was thinking was, conceivably you could have a class with
>>say 100s of methods, all with full access to any
>>(private/protected/public) instance variables. How is that different to
>>100s of functions accessing global variables?
>>    
>>
>
>It's not. Both are bad design. However, in the case of the class +
>instance variables, the problem is that you shouldn't have hundreds of
>(significant[1]) methods in one class, that's a major code stink --
>smell isn't a strong enough word.
>
>Jacob Fugal
>  
>
I'm with Jacob on that one, if you abuse OO, (or rather fail to make 
proper use of it), you can very well end up with code as evil as script 
kiddy PHP hacks. Bad code is bad code is bad code, and no language or 
paradigm will ever prevent people from being horribly bad at it. And 
vice versa, you can make surprisingly clean procedural code if you 
enforce granularity and don't rely on global state - GLib comes to mind.

>[1] At peril of reopening the "Array has too many methods" can of
>worms; yes, I do like convenience methods; no, I don't think Array has
>too many methods, although there are a *few* questionable methods in
>Array; yada, yada, yada. The important thing is that convenience
>methods *should* be built upon the other methods of the class, and
>thus not access the instance variables. They are only there, as the
>name implies, for convenience.
>  
>
And at peril of joining sides in a holy war I'm not yet well aware of, 
I'm taking the stance that people need to distinguish between designing 
application (internal) code, and designing library (exported) code. The 
former I prefer maintainable and consistent, the outer, which other 
people are most likely to make use of, I prefer usable, well supplied 
with friendly interfaces that provide Sensible Defaults instead of 
having users of my library understand my Great Plan (tm) - which is 
something only people that modify a library should care about. The one 
argument that speaks against many methods in a class is reduced 
maintainability, but I'll buy that one if I see Array getting 
convenience methods that aren't implementable with a one-liner.

David Vallner
.NET bashing for fun and profit. (Because SortedLists are IDictionaries now)