MC++ changing access in a derived class

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

Edward Diener

Since a C++ using declaration isn't allowed in MC++, is there a way to
specify that a property, method, event, or field's access can be changed in
a derived class, ie. is protected in one class and is made public in a
derived class ?
 
Daniel said:
I do not believe this feature is supported in .NET.
Click to expand...

I don't think so either.

A neat feature in C++ Builder was the ability to design a base class
component with full functionality, called something like
"CustomAComponentName", many of whose properties, methods, and events were
protected, and then each derived class with only refined functionality,
called something like "AComponentName", could decide which of these areas
could be made public ( or __published ) in the derived class. As it is now,
if a base class exposes a property, method, or event, there is no way to
eliminate that exposure in a derived class. Yet this last is often a valid
programming paradigm. My derived class is often a more particular version of
the base class which exposes a simpler interface. But in .NET the full base
class interface most always be exposed. That seems a deficiency of the
language design.
 
Edward Diener said:
I don't think so either.

A neat feature in C++ Builder was the ability to design a base class
component with full functionality, called something like
"CustomAComponentName", many of whose properties, methods, and events were
protected, and then each derived class with only refined functionality,
called something like "AComponentName", could decide which of these areas
could be made public ( or __published ) in the derived class. As it is now,
if a base class exposes a property, method, or event, there is no way to
eliminate that exposure in a derived class. Yet this last is often a valid
programming paradigm. My derived class is often a more particular version of
the base class which exposes a simpler interface. But in .NET the full base
class interface most always be exposed. That seems a deficiency of the
language design.
Click to expand...
The oft quoted Liskov substitution principle[1] probably fits here. In any
given case, a given class should be able to be used as its parent, meaning
that you shouldn't be able to reduce privledge to a given member, or should
only be able to do so in appearence(like explicit interface implementation
or VB's renamable interface methods(not sure of hte name for that)). I can
however see the purpose in allowing it to be expanded, if proper care is
taken. It is currently a CLR issue, however it is one that could atleast be
taken into consideration. If you wish to provide simplier interfaces, you
may want to consider an approach based on the concept of an interface
instead of modifying classes. Interfaces are bound to scale across other
languages better than modifying protections, and do end with a cleaner
system. There may be attributes that will allow you to hide members from the
intellisense list as well, but I don't know off hand.

1. http://en2.wikipedia.org/wiki/Liskov_substitution_principle
 
Daniel said:
Edward Diener said:
I don't think so either.

A neat feature in C++ Builder was the ability to design a base class
component with full functionality, called something like
"CustomAComponentName", many of whose properties, methods, and
events were protected, and then each derived class with only
refined functionality, called something like "AComponentName", could
decide which of these areas could be made public ( or __published )
in the derived class. As it is now, if a base class exposes a
property, method, or event, there is no way to eliminate that
exposure in a derived class. Yet this last is often a valid
programming paradigm. My derived class is often a more particular
version of the base class which exposes a simpler interface. But in
.NET the full base class interface most always be exposed. That
seems a deficiency of the language design.
Click to expand...
The oft quoted Liskov substitution principle[1] probably fits here.
In any given case, a given class should be able to be used as its
parent, meaning that you shouldn't be able to reduce privledge to a
given member, or should only be able to do so in appearence(like
explicit interface implementation or VB's renamable interface
methods(not sure of hte name for that)). I can however see the
purpose in allowing it to be expanded, if proper care is taken.
Click to expand...

Actually I think one should be able to reduce functionality in a derived
class in order to simplify a class's access. Certainly, of course, one
should be able to expand functionality, as this is the basic idea of OOP
programming.
It is
currently a CLR issue, however it is one that could atleast be taken
into consideration. If you wish to provide simplier interfaces, you
may want to consider an approach based on the concept of an interface
instead of modifying classes. Interfaces are bound to scale across
other languages better than modifying protections, and do end with a
cleaner system. There may be attributes that will allow you to hide
members from the intellisense list as well, but I don't know off
hand.
Click to expand...

I understand interfaces, the equivalent in C++ of abstract classes. I will
consider them more in my own design.
 
Edward Diener said:
Daniel said:
Edward Diener said:
Daniel O'Connell wrote:
I do not believe this feature is supported in .NET.

I don't think so either.

A neat feature in C++ Builder was the ability to design a base class
component with full functionality, called something like
"CustomAComponentName", many of whose properties, methods, and
events were protected, and then each derived class with only
refined functionality, called something like "AComponentName", could
decide which of these areas could be made public ( or __published )
in the derived class. As it is now, if a base class exposes a
property, method, or event, there is no way to eliminate that
exposure in a derived class. Yet this last is often a valid
programming paradigm. My derived class is often a more particular
version of the base class which exposes a simpler interface. But in
.NET the full base class interface most always be exposed. That
seems a deficiency of the language design.
Click to expand...
The oft quoted Liskov substitution principle[1] probably fits here.
In any given case, a given class should be able to be used as its
parent, meaning that you shouldn't be able to reduce privledge to a
given member, or should only be able to do so in appearence(like
explicit interface implementation or VB's renamable interface
methods(not sure of hte name for that)). I can however see the
purpose in allowing it to be expanded, if proper care is taken.
Click to expand...

Actually I think one should be able to reduce functionality in a derived
class in order to simplify a class's access. Certainly, of course, one
should be able to expand functionality, as this is the basic idea of OOP
programming.
Click to expand...
It leaves a balacne, if you reduce functionality, you loose the OOP concept
of being able to use a derived class as a base. In nearly all cases, I would
consider loosing that to be breaking OOP. If you want to produce a new
interface, I say create a new class and call into the class you wish to base
off of.
 
Daniel said:
Edward Diener said:
Daniel said:
Daniel O'Connell wrote:
I do not believe this feature is supported in .NET.

I don't think so either.

A neat feature in C++ Builder was the ability to design a base
class component with full functionality, called something like
"CustomAComponentName", many of whose properties, methods, and
events were protected, and then each derived class with only
refined functionality, called something like "AComponentName",
could decide which of these areas could be made public ( or
__published ) in the derived class. As it is now, if a base class
exposes a property, method, or event, there is no way to eliminate
that exposure in a derived class. Yet this last is often a valid
programming paradigm. My derived class is often a more particular
version of the base class which exposes a simpler interface. But in
.NET the full base class interface most always be exposed. That
seems a deficiency of the language design.

The oft quoted Liskov substitution principle[1] probably fits here.
In any given case, a given class should be able to be used as its
parent, meaning that you shouldn't be able to reduce privledge to a
given member, or should only be able to do so in appearence(like
explicit interface implementation or VB's renamable interface
methods(not sure of hte name for that)). I can however see the
purpose in allowing it to be expanded, if proper care is taken.
Click to expand...

Actually I think one should be able to reduce functionality in a
derived class in order to simplify a class's access. Certainly, of
course, one should be able to expand functionality, as this is the
basic idea of OOP programming.
Click to expand...
It leaves a balacne, if you reduce functionality, you loose the OOP
concept of being able to use a derived class as a base. In nearly all
cases, I would consider loosing that to be breaking OOP. If you want
to produce a new interface, I say create a new class and call into
the class you wish to base off of.
Click to expand...

I agree with you. One shouldn't reduce functionality but one can simplify
what is already there by adding a simpler set of functionality for a derived
class. You have made the correct point that removing functionality destroys
polymorphic access through a base class pointer ( or reference ). Definitely
my error in not considering that.
 
Back
Top