Re: Language improvement: Add scope to class member fields
- From: WXS <WXS@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 26 May 2006 08:28:02 -0700
(Sorry if this is a dupe it timed out when sending it the first time and it
doesn't seem to be showing up yet)
The normal scenario is 90% of coding is done this way and does not break
every small subset of functionality into seperate classes. Should it? I'd
say depends on the usage. Sometimes having lots of other small
objects/classes being allocated can put a heavy burden on the GC, so is not
desireable. Sometimes wrapping and having every variable needed for those
methods is making it too isolated and requiring convoluted accessors to get
at the information/variables in a logical way.
This mechanism just adds an extra level of granularity. An example of this
general philosophy is MS for example adding anonymous delegates. The regular
delegates were perfectly fine right... better abstracted? But the reality is
the usage patterns called for it and for the majority of development work it
made it easier to work with and manage/understand the code.
Should the class be the end all boundary for scoping? Of course not, thats
why classes have methods that scope locals, methods that are public, private,
protected, protected internal, etc. Scoping helps clarify the meaning and
usage of things. The problem is there is little scoping for class fields and
methods in the same class. This party-on everything in your own class
approach rarely survives well in real world software cycle where tens of
developers are continually adding functionality with little if any time left
for refactoring and the testing that would be needed to do that.
In the ideal world everyone would buckle their seatbelt too... but real
world dilemas, schedules and timeframes unfortunately are a bit messy.
Having an extra mechnism that is easy in place for developers to isolate code
even within the same class could prove extremely useful.
..NET's single inheritance doesn't help the situation here, as it may have
made sense to abstract another class to derive from but that is not possible
in .NET would need to use proxies...etc.
A recent example I hit along these lines, was a multithreading timer
scenario where one function could potentially be called multiple times. So I
created a class member field like bool inMyMethod=false; This needed to be
protected by a lock as well.
MyMethod() would check this flag first within a lock and only run the method
if it was the first time through.
A second method called something like ResetFlagForMyMethod() can be called
within the class for other events and inside it just did lock(lockObject_) {
inMyMethod=false; }
I don't want any other methods using either the lock object I am using there
or the inMyMethod flag. This is so trivial it would make almost zero sense
to make a seperate class out of it, and because MyMethod requires some access
to other member variables in the current class would be problematic and too
coupled/confusing.
Within this class there are probably several little helpers with similar
types of variable usages, if I could scope those variables I could ensure no
one would use them inappropriately outside the intended methods. As it
currently stands there is no protection.
Very few, if any of the developers I know would abstract such small subset
of functionality for organizational purposes. Would you?
I agree with the general principle of class seperation but I think these
micro classes would just be too much for developers to deal with, and given
the code I have seen over the years I know that not doing that is the norm.
Don't get me wrong in the right cases I'm all for abstraction into other
classes, I just think there are these subsets of functionality even with
classes that I have seen consistently in real world code that cause problems
and confusion.
"Barry Kelly" wrote:
WXS <WXS@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
So for example if you had a complex class that internally maintained an
array for its own private use, and you added methods Add, Remove and Get and
wanted to make sure those were the only methods that had access to that
variable because it needed to be locked for multithreading purposes,
This is where I part company with your approach. If the class is getting
complex, and it requires a set of methods to work on a subset of data,
then I think those methods and data should be refactored into another
class - a private inner class if necessary.
So not sure how viable this is but something
to think about if there is some way to improve... ideas?
Allowing classes to become more complex is not a terrific design goal,
IMHO. The two biggest problems in existing class library design I see on
a day to day basis are:
1) Classes that do too much. (User interfaces are a major culprit here,
especially ones designed with the IDE control surface designer.)
2) Classes, inheritance, interfaces, polymorphism etc. introduced for
"flexibility" or "extensibility" before it's a proven requirement.
Too few classes is often a symptom of the first, too many a symptom of
the second.
One could try to argue to break out subsets into other
classes. But many times the set of functionality is so limited, it would be
like a micro class...
I don't see the trade-off here. Either the functionality is trivial so
that scoping is overkill, or it is complex enough to put in a separate
class.
And with
several of those subsets it is not only hard to discern what variables work
with which methods
If you have several confusing sub-sets of state inside your class that
make implementing the class more difficult, all the more reason to
factor them into another class! In fact, I would consider this pain
point to be the motivating factor in creating the new class -
recognizing that a lump of behaviour and state needs to be encapsulated.
That's what classes are for.
but can be functionally disasterous if a variable that is
supposed to be protected by locking before accessing is used directly in
another method.
And a reference to an inner class gives you a handy thing to lock
against :)
-- Barry
--
http://barrkel.blogspot.com/
"Barry Kelly" wrote:
WXS <WXS@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:.
So for example if you had a complex class that internally maintained an
array for its own private use, and you added methods Add, Remove and Get and
wanted to make sure those were the only methods that had access to that
variable because it needed to be locked for multithreading purposes,
This is where I part company with your approach. If the class is getting
complex, and it requires a set of methods to work on a subset of data,
then I think those methods and data should be refactored into another
class - a private inner class if necessary.
So not sure how viable this is but something
to think about if there is some way to improve... ideas?
Allowing classes to become more complex is not a terrific design goal,
IMHO. The two biggest problems in existing class library design I see on
a day to day basis are:
1) Classes that do too much. (User interfaces are a major culprit here,
especially ones designed with the IDE control surface designer.)
2) Classes, inheritance, interfaces, polymorphism etc. introduced for
"flexibility" or "extensibility" before it's a proven requirement.
Too few classes is often a symptom of the first, too many a symptom of
the second.
One could try to argue to break out subsets into other
classes. But many times the set of functionality is so limited, it would be
like a micro class...
I don't see the trade-off here. Either the functionality is trivial so
that scoping is overkill, or it is complex enough to put in a separate
class.
And with
several of those subsets it is not only hard to discern what variables work
with which methods
If you have several confusing sub-sets of state inside your class that
make implementing the class more difficult, all the more reason to
factor them into another class! In fact, I would consider this pain
point to be the motivating factor in creating the new class -
recognizing that a lump of behaviour and state needs to be encapsulated.
That's what classes are for.
but can be functionally disasterous if a variable that is
supposed to be protected by locking before accessing is used directly in
another method.
And a reference to an inner class gives you a handy thing to lock
against :)
-- Barry
--
http://barrkel.blogspot.com/
- References:
- Language improvement: Add scope to class member fields
- From: WXS
- Re: Language improvement: Add scope to class member fields
- From: Barry Kelly
- Language improvement: Add scope to class member fields
- Prev by Date: Re: Is it possible to make empty datagridview rows visible?
- Next by Date: ndoc and/or HTML help link to other chm
- Previous by thread: Re: Language improvement: Add scope to class member fields
- Next by thread: Re: Language improvement: Add scope to class member fields
- Index(es):
Relevant Pages
|
