Re: Language improvement: Add scope to class member fields
- From: WXS <WXS@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 26 May 2006 08:55:02 -0700
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.
The functionality for the small subset of functionality is trivial but if
you have several of these small subsets of functionality within the class,
and allowing other methods to have access to variables that don't need is
sloppy and inappropriate but too trivial to warrant a class abstraction.
Also the code other than a naming convention or comments has no way to show
the "intention" of those variables as they are only intended for a specific
method/uses. And naming and commenting are not enforcing which could be
dangerous when you really needed a lock to use a specific variable or some
methods have side effects relative to member fields thus access to the fields
should be isolated from allowing other methods to use them inappropriately.
A language should have a way to express intention, just like in SQL you can
express constraints for fields. You should be able to express constraints for
access to fields (granted a different sort of constraint but hopefully you
see the general idea).
"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/
- Follow-Ups:
- Re: Language improvement: Add scope to class member fields
- From: Paul E Collins
- Re: Language improvement: Add scope to class member fields
- 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: Insert an Image to a dataGridView column
- Next by Date: Re: shouldn't if (this!=null) generate a warning?
- 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
|
