Override property
shapper
I have a class A with the property Title:
public class A {
public String Title { get; set; }
}
And a class B then inherits A and has the following properties:
public class B {
public String Name { get; set; }
public String TitleSeparator { get; set; }
public override String Title { get { return String.Concat(title,
TitleSeparator, Name); } set { title = value; } }
private String title;
}
I need to override Title property in A so it gets the value Title +
TitleSeparator + Name.
I am getting an error:
B.Title.get': cannot override inherited member 'A.Title.get' because
it is not marked virtual, abstract, or override
I am marking it as override. You can see on my code.
What am I missing?
Thanks,
Miguel
Peter Duniho
> Hello,
>
> I have a class A with the property Title:
>
> public class A {
> public String Title { get; set; }
> }
>
> And a class B then inherits A and has the following properties:
>
> public class B {
> public String Name { get; set; }
> public String TitleSeparator { get; set; }
>
> public override String Title { get { return String.Concat(title,
> TitleSeparator, Name); } set { title = value; } }
> private String title;
> }
>
> I need to override Title property in A so it gets the value Title +
> TitleSeparator + Name.
You can't do that. Even if you could, it's very bad practice to have a
setter take as input something different than what you'd get as output
from the getter.
> I am getting an error:
> B.Title.get': cannot override inherited member 'A.Title.get' because
> it is not marked virtual, abstract, or override
>
> I am marking it as override. You can see on my code.
>
> What am I missing?
Read the error message again. I cannot think of a clearer way to explain
the problem than what the compiler is already telling you. Note that "it"
refers to the "inherited member 'A.Title.get'", not the member you're
adding to 'B.Title.get'.
Pete
shapper
wrote:
> You can't do that. Even if you could, it's very bad practice to have a
> setter take as input something different than what you'd get as output
> from the getter.
Now I am confused.
Basically what I am trying to do is something as follows:
When I define the Title property,
B myB = new B();
B.Title = "My Title";
I would like B.Title value to become B.Title + B.TitleSeparator +
B.Name
Is this not possible or the way I am doing is wrong?
I am doing this because my B class is something as follows:
public class B : A {
public String Name { get; set; }
public String TitleSeparator { get; set; }
public String Title { get; set; }
public B() {
Name = "Sample Name";
TitleSeparator = "-";
Title = String.Empty;
}
}
So I set default values for the first two properties.
Later in my code I do something like:
ContainerClass = new ContainerClass {
B = new B { Title = "This Page Title" }
}
And I would like Title to become Title + TitleSeparator + Name with no
more need of code;
Well this is how I am thinking ... probably wrong.
(Note: my B class is public class B : A { ... I forgot the ":A" part
on my previous post)
Thanks,
Miguel
Jesse Houwing
I think the best way to approach this is to override ToString and let that
create the title for you.
To do it the way you're doing it, you'll have to make the Title property
in type A virtual, so that you can override it in type B like so:
class A{
public virtual string Title
{
get;
set;
}
}
class B{
public override string Title
{
get
{
return base.Title + TitleSeparator + Name
}
set;
}
A better way would be to look at the name and try and find a better solution.
As Title in itself seems to be a little more than just a string... It could
be multiple strings, depending on where in the hyrarchy you are...
To me the original Title would be more like MainTitle, while the second (in
type B) would be a SubTitle...
Then you could have a Title Property (get only) which returns the right title
in every type:
class A
{
public virtual string Title
{
get { return MainTitle; }
}
public string MainTitle {get; set;}
public override string ToString()
{
return Title;
}
}
class B
{
public override string Title
{
get { return base.MainTitle + TitleSeparator + SubTitle; }
}
public string SubTitle {get; set;}
}
--
Jesse Houwing
jesse.houwing at sogeti.nl
Peter Duniho
> [...]
> When I define the Title property,
>
> B myB = new B();
> B.Title = "My Title";
>
> I would like B.Title value to become B.Title + B.TitleSeparator +
> B.Name
>
> Is this not possible or the way I am doing is wrong? [...]
It does seem to me your basic approach is just wrong.
You have a property, Title. You are trying to make that property do two
completely different things. As a setter, it defines some string _other
than the title_ (!). As a getter, it defines a string representing the
title.
The getter seems fine to me. But the setter is messed up.
What you really have are four pieces of information:
-- "Name"
-- "Separator"
-- "Title"
-- "The Thing That Follows The Name and Separator in the Title"
Now, you haven't given enough information to know what that last thing is
called. Maybe it's a "Document Name" or perhaps it's a "File Name" or
maybe it's a "Remote Host Name". Let's just call it "OtherName" for now.
Then, your base class already has a "Title" property. So you need _three_
new properties, not two new ones and an override. Call those properties
"Name", "Separator", and "OtherName".
Then, when _any_ of those properties changes, you assign a new string to
the "Title" property, a string that is the concatenation of those three
new properties.
That approach would properly respect what the "Title" really is, and would
provide symmetric behavior for all of the properties with respect to their
getters and setters.
If that doesn't seem like an appropriate solution, you're going to have to
be more specific about what your classes are, and especially about why the
above doesn't work for you.
Pete
shapper
wrote:
> I think the best way to approach this is to override ToString and let that
> create the title for you.
What do you mean? Creating a custom type converter?
> To do it the way you're doing it, you'll have to make the Title property
> in type A virtual, so that you can override it in type B like so:
>
> class A{
>
> public virtual string Title
> {
> get;
> set;
>
> }
> }
>
> class B{
>
> public override string Title
> {
> get
> {
> return base.Title + TitleSeparator + Name
>
> }
> set;
> }
I did but I get the following error on set:
'Title.set' must declare a body because it is not marked abstract,
extern, or partial
I am not sure but since the get is not on the short form I need change
the set to:
public override string Title { get { return String.Concat
(base.Title, " - ", Name); } set { title = value; } }
private String title;
> A better way would be to look at the name and try and find a better solution.
> As Title in itself seems to be a little more than just a string... It could
> be multiple strings, depending on where in the hyrarchy you are...
Basically Title is the page title.
On each ASP.NET MVC Controller Action (Renders a page) I define the
title.
But then on B class I want to add " - Site Name" to the title.
I placed "-" in TitleSeparator property and "Site Name" in Name
property.
This way for a particular page, if I need to change it I can.
The reason why this is getting complex is that A is a class inside a
library that I use in all sites and it contains properties like Title,
Keywords, Scripts, etc ...
TitleSeparator and Name is specific to each project implementation so
it is in class B that inherits class A to bring all those common
properties.
shapper
wrote:
> Now, you haven't given enough information to know what that last thing is
> called. Maybe it's a "Document Name" or perhaps it's a "File Name" or
> maybe it's a "Remote Host Name". Let's just call it "OtherName" for now.
I just wrote a better explanation.
My classes are just like that.
They have a few more properties and nothing else.
I just named them A and B because I didn't copied the code.
But A is PageHead and B is PageEngine.
PageHead (A) > Contains properties like Title, Keywords, Scripts and
Styles and I use it in all my projects.
PageEngine (B)> Specific to this project where I need to add the title
separator and site name " - Site Name"
I don't want to mess a lot in class A only to satisfy the needs of a
specific project.
Peter Duniho
> On May 9, 10:34 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
> wrote:
>
>> Now, you haven't given enough information to know what that last thing
>> is
>> called. Maybe it's a "Document Name" or perhaps it's a "File Name" or
>> maybe it's a "Remote Host Name". Let's just call it "OtherName" for
>> now.
>
> I just wrote a better explanation.
Where?
> My classes are just like that.
Just like what?
> They have a few more properties and nothing else.
>
> I just named them A and B because I didn't copied the code.
>
> But A is PageHead and B is PageEngine.
Maybe this is a "lost in translation" thing, but I don't understand why an
"engine" inherits a "head". It seems to me that the only thing that would
inherit a "head" class would be other classes that are more specialized
types of "head".
So, right there it seems like you be may be abusing your object
hierarchy. Hard to say without knowing more, but it doesn't sound right
just based on the names.
> PageHead (A) > Contains properties like Title, Keywords, Scripts and
> Styles and I use it in all my projects.
>
> PageEngine (B)> Specific to this project where I need to add the title
> separator and site name " - Site Name"
>
> I don't want to mess a lot in class A only to satisfy the needs of a
> specific project.
Nothing in my suggestion would require you to make any changes to your
base class at all.
Pete
shapper
wrote:
> Maybe this is a "lost in translation" thing, but I don't understand why an
> "engine" inherits a "head". It seems to me that the only thing that would
> inherit a "head" class would be other classes that are more specialized
> types of "head".
You are right. In fact both classes are at same level.
Let's call both classes Page.
So Page in my common library contains properties that I use in all my
projects.
The other inside my project extends the original one by adding a few
more properties specific to the project.
Then I pass this class in my ViewModel so the View (Html) can use all
properties where necessary.
So I took another approach: partial classes. So on my Common library I
have:
namespace Common {
public partial class Page {
public String Keywords { get; set; }
public String Description { get; set; }
public String Title { get; set; }
}
}
And on my project I have:
namespace MvcProject {
public partial class Page {
public String TitleSeparator { get; set; }
public String Name { get; set; }
public String Language { get; set; }
}
}
Now on my ViewModel I would need to define a property of type Page to
pass to the view:
public class ViewModel {
public Page Page { get; set; }
public ViewModel() {
Page = new Page {
Description = "This web site",
Keywords = "First,Second,Third",
Title = "Web Page Title",
TitleSeparator = " - ",
Name = " My MVC Web Site"
};
} // ViewModel
This does now work because I get the error:
'MvcProject.Page' does not contain a definition for 'Title'
This is because the ViewModel interprets the Page class as one or the
other.
So I got stuck again ... :-)
Was this such a bad idea?
I am just trying to make this right because I will use it in all my
projects.
Thanks,
Miguel
Peter Duniho
> [...]
> TitleSeparator and Name is specific to each project implementation so
> it is in class B that inherits class A to bring all those common
> properties.
I meant to mention this in my other reply, but by the time I returned to
it and posted it, I'd forgotten. Anyway...
It's not completely clear, but assuming by "is specific to each project
implementation", you mean that each implementation will have a different
separator and name, then putting those properties into each implementation
doesn't seem appropriate. Instead, the base class ought to have those
properties, with each project implementation providing their own values
for the properties.
Pete
Peter Duniho
> [...]
> This does now work because I get the error:
> 'MvcProject.Page' does not contain a definition for 'Title'
>
> This is because the ViewModel interprets the Page class as one or the
> other.
> So I got stuck again ... :-)
Right. You've declared each "partial class Page" in its own namespace, so
they are in fact two completely different classes.
I'm still not really clear on the relationship between the classes. Your
_description_ of them suggests that inheritance might be a fine approach.
It's just that the names you originally provided for them were not names
that would normally show up in an inheritance relationship.
So far, we've received at least two potentially conflicting descriptions
of what's going on. In particular, it's not really clear what the
multiple subclasses look like.
Your most recent reply strongly suggests that there _is_ in fact a common
base class, called a "PageBase" (I know that's not what you called it, but
humor me). Then there are multiple subclasses. We might call those
"PageKindA", "PageKindB", "PageKindC", etc..
Now, one very important question IMHO is what each of those subclasses
look like. For sure, it seems to me that you need the "Title" property
(to provide the actual title), and then three more properties ("Name",
"TitleSeparator", and "OtherName") to specify what actually forms the
"Title" property. But where each of these go depends on how the classes
are defined.
Based on what you've written so far, I'd implement this all in one of two
different ways:
-- Put all four properties into the base class. The "Title" property
is read-only, the value created automatically from the other three
properties, and the other three properties are set by the sub-classes as
appropriate to their needs.
-- Put the "Title" property into the base class, and the other three
into a sub-class that needs them. The sub-class would set the "Title"
property any time its own three properties changed...again, based on the
values of those three properties.
The deciding factor is the answer to that "important question" I
mentioned. Specifically, do _all_ of the sub-classes have these three
different properties, used to form the "Title" property? If so, then
you've got a feature common to all the sub-classes, and so can implement
that feature in the base class and would choose the first solution above.
The sub-classes would simply set the three component properties as
necessary.
On the other hand, if some sub-classes only ever use the "Title" property,
while others have this "three-into-one" characteristic, you need to
support both with the sub-class. In that case, you can either still use
the first solution, and simply have those sub-classes ignore all but the
"Name" property (they could default to "null", and the "Title" property
would treat that as an empty string). Or you can implement only the
"Title" property in the base class, and have each sub-class that wants a
more complex title be required to implement their own extra properties for
that purpose.
In the latter approach for the second solution, you might make the "Title"
property virtual; that way the sub-classes can override the setter and/or
getter to support their own behavior (e.g. the getter would concatenate
the other three properties, while the setter could either try to parse the
input string into three different property values, or simply throw an
exception).
These approaches might look like any of the following examples:
namespace AllInBase
{
class PageBase
{
public string Name { get; set; }
public string TitleSeparator { get; set; }
public string OtherName { get; set; }
public string Title
{
get { return Name + TitleSeparator + OtherName; }
}
}
class PageKindA
{
public PageKindA()
{
Name = "Page";
TitleSeparator = " - ";
OtherName = "A";
}
}
}
namespace TitleInBase
{
class PageBase
{
public string Title { get; set; }
}
class PageKindA
{
private string _name;
private string _sep;
private string _other;
public string Name
{
get { return _name; }
set
{
_name = value;
_SetTitle();
}
}
public string TitleSeparator
{
get { return _sep; }
set
{
_sep = value;
_SetTitle();
}
}
public string OtherName
{
get { return _other; }
set
{
_other = value;
_SetTitle();
}
}
private void _SetTitle()
{
Title = Name + TitleSeparator + OtherName;
}
}
}
namespace VirtualTitleInBaseWithParse
{
class PageBase
{
public virtual string Title { get; set; }
}
class PageKindA
{
public string Name { get; set; }
public string TitleSeparator { get; set; }
public string OtherName { get; set; }
public override string Title
{
get { return Name + TitleSeparator + OtherName; }
set
{
string[] rgstr = value.Split(
new string[] { TitleSeparator },
StringSplitOptions.None);
if (rgstr.Length != 2)
{
throw new FormatException("value must include the
TitleSeparator");
}
Name = rgstr[0];
OtherName = rgstr[1];
}
}
}
}
Surely somewhere in the above there's something you might find useful.
And if not, unless you can concisely and clearly state exactly why the
above won't work, I don't think there's much else I could comment on.
Pete
Alexander Mueller
You need to add 'virtual' or 'abstract', but not 'override'
to the Title-property of your base-class 'A'.
abstract fits best, since yor A-class has no implementation for Title;
abstract means incomplete or no implementation, it's up to the dervied
class to fully implemented the base class signatures.
Note that also the class itself must be marked abstract if it contains a
abstract member;
abstract classes can't be created themselfes, only derived classes that
implement all abstract members can be created.
virtual what be your favorite choice if you'd had implementaion for
Title in A, which you want to override or extend in B.
classes with virtual members can be created themselves.
MfG,
Alex
class Program
{
static void Main(string[] args)
{
var b = new B { Title = "B-virtual" };
var bb = new BB { Title = "BB-abstract" };
Console.WriteLine("{0} {1}", b.Title, bb.Title);
Console.ReadLine();
}
}
//virtual solution
public class A
{
protected string _title = null;
public virtual string Title
{
get{return _title;}
set{_title = value ;}
}
}
public class B : A
{
private const string TitleSeparator = "-";
private const string Name = "Name";
public override string Title
{
get { return string.Concat(base.Title,
TitleSeparator, Name); }
set { base.Title = value; }
}
}
//abstract solution
public abstract class AA
{
public abstract string Title { get; set; }
}
public class BB : AA
{
private string _title = null;
private const string TitleSeparator = "-";
private const string Name = "Name";
public override string Title
{
get { return string.Concat(_title,
TitleSeparator, Name); }
set { _title = value; }
}
}
Peter Duniho
<mill...@hotmail.com> wrote:
> [...]
> abstract fits best, since yor A-class has no implementation for Title;
"abstract" might be appropriate, but it's not true that class "A" has no
implementation for Title. It does, and Miguel may actually prefer to
preserve that implementation so that sub-classes don't need to provide it
if they don't want to override the property.
> [...]
> virtual what be your favorite choice if you'd had implementaion for
> Title in A,
Just to reiterate: he does have an implementation for the "Title" property
in "A".
Alexander Mueller
> On Sat, 09 May 2009 21:09:26 -0700, Alexander Mueller
> <mill...@hotmail.com> wrote:
>
>> [...]
>> abstract fits best, since yor A-class has no implementation for Title;
>
> "abstract" might be appropriate, but it's not true that class "A" has no
> implementation for Title.
Sorry i wasn't familiar with that
public String Title { get; set; }
-Thing. I thought it'd do the same thing as in an interface, i.e.
declare but not implement the property, i was missing the assignment in
the setter and the return in the getter.
Now I realize that it also creates a hidden data member for us behind
the scenes. Very nice.
> It does, and Miguel may actually prefer to preserve that implementation so that sub-classes don't need to provide
> it if they don't want to override the property.
Yes the getter in the derived class B is kind of odd.
An extra Readonly prop would be the cleaner way at first glance.
But on the other hand there is no need for not having any
special code in a prop, if you only want to assign and return a
value a field is all you need.
Also if the classes serves as data-source and the B-items shall
return more extended info in the Title-column as the the A-items do,
then this is solution where you don't have to change anything in the
data binding and the code that set the binding doesn't have to
distinguish between derived and basic types.
So at least it works without excessivly changing the OO-model.
MfG,
Alex
shapper
I am testing all solutions to check which one better fits my MVC
project ...
Jeff Johnson
news:ebca38e9-727e-4b29...@z7g2000vbh.googlegroups.com...
> I am getting an error:
> B.Title.get': cannot override inherited member 'A.Title.get' because
> it is not marked virtual, abstract, or override
>
> I am marking it as override. You can see on my code.
Overriding is a two-way street. Not only do you have to specify that you're
overriding it in the derived class, but you have to specify that it CAN be
overridden in the BASE class. So in the base you have to use the "virtual"
keyword and in the derived you have to use "override." This is one of those
cases where I like VB's implementation better. Its keyword for the base
class is "Overridable," which is far more clear than C#'s use of the legacy
C++ "virtual" keyword.