No, you wouldn't be able to do it. Since the variable "theperson" is
compiled as a Person, you can only use the members defined in the
Person class.
The object itself is still a Fireman, so you can cast it to Fireman,
then call Injured:
if (theperson is Fireman) { // good idea to check before casting
Fireman fireman = (Fireman)theperson;
bool b = fireman.Injured();
}
But in most cases, if you need the variable to be a Fireman, then you
wouldn't have declared it as a Person. As someone stated previously
in the thread, you want the most abstract view that your scenario
allows - in this case, if you need your person to be a Fireman, then
your scenario's most abstract view is Fireman, not Person. (or maybe
IInjurable if you only care about whether or not the object can be
injured)
Of course, there are always exceptions. For example, suppose you have
a method that works for all types of Person objects, but does
additional stuff for a Fireman - you could do something like this:
void DoSomething(Person p) {
Console.WriteLine(p.Occupation());
if (p is Fireman) {
if (((Fireman)p).Injured()) {
Console.WriteLine("p is a Fireman and is injured");
}
}
}
On May 7, 8:31 am, Learner <[email protected]> wrote:
> Thanks so much for putting your ideas in a more understandable way. I
> have another question... see the belwo example say we have a person
> class as below
>
> public class Person
>
> {
>
> public virtual string Occupation()
> {
>
> return "No Occupation";
>
> }
> }
>
> public class Fireman : Person
>
> {
>
> public override string Occupation()
> {
>
> return "Fireman";
>
> }
> }
>
> public class Policeman : Person
>
> {
>
> public override string Occupation()
> {
>
> return "Policeman";
>
> }
> }
>
> then we can then do the following when using the classes.
>
> Person theperson;
>
> theperson = new Fireman();
> Response.Write(theperson.Occupation());
>
> theperson = new Policeman();
> Response.Write(theperson.Occupation());
>
> This will write "FiremanPoliceman"
>
> by instantiating an instance of the derived classes Fireman or
> Policeman into it we can get the different implementations of the
> Occupation method.
>
> I guess I am clear with why we need to assign the policeMan/firMan
> into person class. But what if there is another method that has been
> defined in only fireMan that is not in the person class per say
>
> public class Fireman : Person
>
> {
>
> public override string Occupation()
> {
>
> return "Fireman";}
>
> private bool _injured;
> public bool Injured()
> {
> return _injured
> }
>
> }
>
> then can we still instatntiate as below and be able to call 'Ijured'
> function?
>
> Person theperson;
>
> theperson = new Fireman();
> Response.Write(theperson.Occupation());
>
> and do Response.Write(theperson.Injured()); ?
>
> Hope I am asking my doubts in a right way.
>
> Thanks,
>
> -L
>
> On May 7, 8:20 am, rbdavidson <[email protected]> wrote:
>
> > In the specific case you site, I would have written "Dim myBook As
> > Book = New Book". Acutally I would have written, "Dim myBook As New
> > Book", but you get the point. The reason I would have done so is
> > because the variable is declared locally and there is no need or
> > benefit for restricting to the parent object. In my opinion, at this
> > level it is a question of primarily of programer style.
>
> > What the article is doing is following a general principle. I.e. You
> > get higher reuse and greater stability if you restrict your methods to
> > relying on the most abstract view of an object. Since no property or
> > method specific to Book is required by this method, it casts the new
> > Book object as its parent LibraryAsset and uses just the properties
> > and methods exposed by that parent. If Book overrides any
> > LibraryAsset routines the Book version of the routine will be called
> > instead of the Library Asset version.
>
> > This general principle is very useful with method parameters or when
> > dealing with non-private properties. For example, why restrict an
> > paramter to being a partciular class when all you realy care about is
> > that it implements a particular interface. For objects that are
> > declared and used locally this prinicple is not as useful, but there's
> > nothing wrong with following it even then.
>
> > -- R.B. Davidson
>
> > On May 6, 9:00 pm, Learner <[email protected]> wrote:
>
> > > Hi,
>
> > > I am reading an article online and I have come across the below code
> > > snippet.
>
> > > Public Sub ReturnBook(ByVal dueDate As DateTime)
>
> > > Dim myBook As LibraryAsset = New Book
>
> > > myBook.DueDate = dueDate
>
> > > Dim amountDue As Double = myBook.CalculateFineTotal()
>
> > > Console.WriteLine("Book: {0}", amountDue.ToString())
>
> > > End Sub
>
> > > I am kind of not sure if I understand the line of code Dim myBook As
> > > LibraryAsset = New Book right. In which LibraryAsset is the base class
> > > and Book is the derived class. LibraryAsset class is a MustInherit
> > > class with a overridable function in it.
>
> > > Instead of the line Dim myBook As LibraryAsset = New Book can't we
> > > code like
>
> > > Dim myBook As Book = New Book ? Why do we have to assign a New Book
> > > instance to LibraryAsset?
>
> > > In other words if I have a base class X and a derived class Y inorder
> > > for me to instantiate Y in another class do I have to use
>
> > > Dim y1 as X = New Y but not Dim y1 as Y = New Y?
>
> > > Please explain this. I am bit new to OOP techniques.
>
> > > Thanks,
>
> > > -L- Hide quoted text -
>
> > - Show quoted text -
