Request oops concept

Question

I have a question related to the concept of OOPS.

I have a base class

public class BaseClass { public int i = 10; public int x = 30; public string str = "Hello"; public virtual string Hello() { return "Hello of base class called"; } } 

I have a child class

 public class ChildClass : BaseClass { public int i = 20; public int z = 90; public override string Hello() { return "Hello of child class called"; } } 

Now I saw that the code below works fine

 BaseClass baseObject = new ChildClass(); 

and when I type baseObject. , then I see only members of BaseClass .

First question: can anyone advise me on a situation where a developer needs to do this BaseClass baseObject = new ChildClass(); ?

Second question: if my BaseClass object has a reference to my child class object, then why are my child member variables not accessible through this baseObject ?

Answer 1

To answer your first question.

Developers do this in order to provide an abstraction over what actual object they are accessing, which provides flexibility and “weakening of communication” over the code they use.

For example (a common scenario - which I use a lot), you can have 10 child classes that extend the base class. What if you want the method to return each type of child class? Well, without this type of declaration you will need 10 methods. But if you specified the return type "BaseClass", you can return all 10 types of child classes from one method. This method is closely related to user interfaces.

eg

 public BaseClass GetDynamicChildClass() { if (someCondition) return ChildClass(); else if (someOtherCondition) return SomeOtherChildClass(); } 

To answer the second question.

You cannot see child properties because you said that "baseObject" is of type "BaseClass" - the compiler has typed an object for this. To access the child properties, you need to specify it as a child type:

 BaseClass b = new ChildClass(); int x = bz; // error. int x = ((ChildClass)b).z; // works - this is a cast, throws exception in bad conversion ChildClass c = b as ChildClass; // also works, different type of cast, returns null in bad conversion int x2 = cz; 

This type of concept (polymorphism) is fundamental to object-oriented programming. Look at this great StackOverflow question: Try to describe polymorphism as easily as you can

He explains this in the simplest way, without tying it to any particular programming structure, which, in my opinion, is the best way to learn OO.

Hope this helps.

Answer 2

• If you want to have objects with individual behavior that have a set of common functions. For example, you want to put objects of different types into a list.

• The main type is ChildClass, but you are currently working on the BaseClass type. That is why you only see elements for BaseClass. However, it is still possible to convert an instance of BaseClass to an instance of ChildClass with a cast operation or the keyword "as".

Answer 3

When you do

 BaseClass baseObject= new ChildClass(); 

The static declared type of the object is " BaseClass ".

Therefore, you can only see objects of the "BaseClass" .

If you are sure that the object is of type ChildClass, you can give baseObject a method of "ChildClass" and then use the members of ChildClass

((ChildClass) baseObject). - Intellisense should help provide you with elements of a child class.

Using BaseClass baseObject= new ChildClass(); is the basis for RunTime Politicism . It is very often used if you need to call overridden child logic, but the interface corresponds to the base class

EDIT: An example script in which you used it. The User class got classes called Employee and 3rdPartyUser

The user of the class has a virtual method GetRoleInformation - which is used to obtain information about the role for the user from the Active Directory companies.

However, for a third-party user, since the information does not exist in AD, the logic for obtaining role information involves invoking a web service to retrieve data. In this case, GetRoleInformation is overridden in class 3PartyUser

Now, in the program, on the login page, after authentication, I return an Employee or 3rdPartyUser object. I pass this object to a method with the signature RoleCollection GetRole( User loggedInUser)

Inside this method, without determining the type of user, I simply call loggedInUser.GetRoleInformation and depending on whether it is Employee / 3rdPartyUser , the corresponding base / overridden method will be called and the role data will be obtained from the AD / web service.

In short:

Advantage

 BaseClass baseObject= new ChildClass(); 

ABOVE

 ChildClass baseObject= new ChildClass(); 

is in scripts when you are not sure about the exact type of the child object that will be assigned to the baseObject variable, for example: in this case Employee / 3rdPartyUser For example:

  BaseClass baseObject= GetLoggedInUser(); 

where the signature of this method is User GetLoggedInUser(string userid)

Otherwise, in an example like yours where the object is ALWAYS of type "ChildClass", I believe that there is no advantage to this.

Answer 4

Here is an example in which the only method we care about is in the base class. Using this type of abstraction, we can easily add more types of reports.

 public class Report { public virtual string ContentType { get { return "application/octet-stream"; } } public virtual byte[] Build() { return new byte[0]; } public static Report Create(ReportType type) { switch (type) { case ReportType.Pdf: return new PdfReport(); case ReportType.Html: return new HtmlReport(); case ReportType.Doc: return new DocReport(); case ReportType.Xls: return new XlsReport(); default: return new DefaultReport(); } } } 

Then, from the client side, we only need to do this:

 ReportType type = GetReportTypeFromFormPost(); Report report = Report.Create(type); // ... Response.Write(report.Build()); 

Answer 5

The answer to your first quest: this type of implementation is common when we use the abstract factory patten for i wll, which gives a simple example that creates the ford car family ..

 public class AbstractFactoryExample { public AbstractFactoryExample() { string type = ""; CarFactory facotry=null; if (type == "FORD") { facotry = new FordCarFactory(); } ICar MyFamilyCar = facotry.CreateFamilyCar(); ICar MyCityCar = facotry.CreateCityCar(); } } public interface ICar { } public abstract class CarFactory { public abstract ICar CreateFamilyCar(); public abstract ICar CreateCityCar(); } public class FordCarFactory : CarFactory { public override ICar CreateFamilyCar() { return new FordFamilyCar(); } public override ICar CreateCityCar() { return new FordCityCar(); } } public class FordFamilyCar : ICar { } public class FordCityCar : ICar { } 

to your second question:

you declare the object as a base class, so that it shows only the methods in it, and if you are sure that the generated instance is of the type of the child class

 ((ChildClass) baseObject) 

can solve the problem

please excuse me for my bad english

Answer 6

This actually makes sense to you when you use Factory Pattern ( http://gsraj.tripod.com/design/creational/factory/factory.html ) to create an object. This would abstract away the specific implementation details for different classes.