Abstract Properties

  • Thread starter Thread starter SpookyET
  • Start date Start date
S

SpookyET

Why does abstract properties force you to use get; or a set; in them? I
want neither.
class abstract Foobar; class FoobarReader : Foobar with only gets; class
FoobarWriter : Foobar with only sets;
Why can't you declare it as protected abstract MyType MyProperty; For
interfaces it makes sense to force a get or a set on you, but for
abstracts?
 
It is stupid to have to do something like this;

public abstract class MetaDataFile
{
protected abstract string Path
{
get; set;
}
}

public class MetaDataFileReader : MetaDataFile
{
protected string Path
{
get { return path; }
set { throw new System.Exception("Property or indexer cannot be assigned
to -- it is read only");}
}
}

public class MetaDataFile : MetaDataFile
{
protected string Path
{
get { throw new System.Exception("Property or indexer cannot be read --
it is write only");}
set { path = value; }
}
}
 
SpookyET
It is stupid to have to do something like this;
Click to expand...
Agreed!

First you should not throw a System.Exception directly, you should derive
your exceptions from System.ApplicationException or throw existing
exceptions.
set { throw new System.Exception("Property or indexer cannot be assigned
to -- it is read only");}
Click to expand...
I would suggest throwing a System.NotSupportedException.
get { throw new System.Exception("Property or indexer cannot be read --
it is write only");}
Click to expand...
Again I would suggest throwing a System.NotSupportedException.


Should MetaDataFileReader & MetaDataFileWriter inherit from MetaDataFile?

I would expect reader & writer to accept a MetaDataFile as a parameter,
similar to how StreamReader & StreamWriter accept a Stream as a parameter,
not inherit from MetaDataFile!


As to your original question, polymorphism just doesn't work that way.
Remember that when you define a base class you are saying that all classes
derived from this base class support these features. Which allows you to
define variables of the base class, while working with objects of the
derived class. If the base class does not "support" either getting or
setting the property, then it sounds like the property does not belong in
the base class, it sounds like it belongs in each derived class, as either
get or set.

Such as:

MetaDataFile file = New MetaDataFileReader();

Because MetaDataFile defines Path, you can use file.Path above. Because you
only have a MetaDataFile variable the compiler does not know & you should
not care that you actually have a MetaDataFileReader, MetaDataFileWriter, or
SomeOtherGreatAndWonderMetaDataFile object. As long as they inherit from
MetaDataFile polymorphism says things will work consistently. Which is where
I may throw a NotSupportedException when a derived class does not (can not)
fully support the base "contract".

Hope this helps
Jay
 
It is stupid to have to do something like this;
public abstract class MetaDataFile
{
protected abstract string Path
{
get; set;
}
}
Click to expand...

Actually, it does make sense, though it's a bit of a pain.

A property can have a get or a set or both. For an abstract class or
interface, the signature (get, set, or get & set) must match in a derived
class. In other words, if in the abstract class or interface, you define a
property with only get, nowhere in the derived classes may you implement a
set.

I'm not sure what the underlying reason is for this, but I'm pretty sure it
has to do with how the virtual method tables are handled by the CLI. So it's
not necessarily something they said, "we should do it this way in C#." It's
more along the lines of C# does it because the CLI does it.

Pete
 
Back
Top