Understanding Inheritance

[akiaz]

Hey everybody...I'm having a problem understanding inheritance. Here is a simple (maybe?) description: I have a project in a solution that contains a class (of course). In the same solution, I have created another class that inherits from the first and there is a reference to that project as well.

 

Ok, now I have added a third project to the solution and there is a reference to the project that contains the derived class. Then I instantiate an object from the derived class. No problem.

 

But when I try to access a property (UserID) of the object that is defined in the original base class I get the error:

 

'Public Overridable Overloads Property UserID() As Integer' is declared in project 'FirstProject.dll', which is not referenced by project 'ThirdProject.exe'.

 

Ok fine, but why do I have to reference the first project in the third project? I thought that my derived class should encapsulate ALL functionality of the base class. Is there something simple I'm not getting?

 

TIA

[akiaz]

The plot thickens...I have discovered something, but the problem remains.

 

In the base class (which is in c#) i have this:

 

public virtual int UserID
{
 get
 {
   return this._intUserID;
 }
 set
 {
   this._intUserID = value;
 }
}

 

but now I have added this to the derived class (in vb.net):

 

       public overrides property UserID As Int32
           Get
               return mybase.UserID
           End Get
           Set
               mybase.UserID = value
           End Set
       End Property

 

and then I no longer have to reference the base class in the third project. But dosen't this seem to contradict OO design? I shouldn't have to override properties in a derived class should I? Is there a keyword I'm missing that makes this all work properly?

 

Please excuse my ignorance of .NET object oriented design as this is new to me.

[Arch4ngel]

I know there's masking of variable, function and others...

 

When the IDE look for your data... it look to the more local.

Be sure not to have 2 class named exactly the same. As one would mask the other.

 

Was it your question or did I pass beside at 100 miles per hours ?

[akiaz]

The classes are named differently and are in similar but different namespaces but the reference takes care of that, along with Imports statement.

 

Originally, I did not declare the property using the virtual modifier. This should have exposed this property as available in the most derived class.

[akiaz]

I know there's masking of variable' date=' function and others...[/quote']

 

Ok, I see what you mean now, but the intellisense picks up the property name without having the reference to the base class project. I would think that if the VS editor can "see" the property, then I would not need a reference to the base class.

 

Seems strange that I can see the property when coding but not be able to use it.

[Nerseus]

As the compiler states, you need a reference to the first project in your third project. While project2 encapsulates some logic from project1, you still need the reference (the DLL) so that when code from project1 is run it knows where to get it.

 

When you compiled project2, it did NOT copy all of project 1's code into project 2's DLL. It relies on project 1's DLL to contain all that code and functionality.

 

I'm actually surprised that the code from your second post would compile. I wouldn't think it mattered what if you overrode all properties from the base class or not - you would still need the reference to that DLL.

 

In answer to *that* question, yes - overriding a base class's property to do the exact same thing is a bit overkill just to prevent you from having the extra reference.

 

-Nerseus

[akiaz]

I'm not expecting it to copy project 1's code into project 2, I expect inheritance to provide the mechanism so that when accessing a type method in project 2, it knows to look in the base class if it is not overridden. I completely understand that project 2 relies on project 1's DLL to contain the code, but project 3 should rely on project 2 and not project 1. What if later I want to replace the DLL file from the first project? Do I have to recompile the entire solution? The DLL in project 3 should not have to be. That would be a major flaw in .NET if that were the case wouldn't it?

[Nerseus]

I'm not sure I understand the dilemma - Project 3 only requires a reference to Project 1. As you stated, changing the implementation of Project 1 (and hence generating a new DLL) would not require a recompile of Project 2 or Project 3 for those two projects to take advantage of the "fix" to Project 1.

 

You should not have to re-implement any properties in Project 2 or Project 3 if they do what you expect in Project 1. I thought you only re-implemented the UserID property in Project 2 (or was it Project 3) to try and get around having to reference Project 1 from Project 3? If you take that re-implementation out and have Project 3 reference Project 1, you should be fine.

 

-Nerseus

[akiaz]

I think I understand much better now. I was under the (incorrect) assumption that because project 2 referenced project 1, that it should not be necessary to reference project 1 from project 3. But the reference is there so that project 3 can "find" the code to run in project 1 when necessary, if the property is not overridden in project 2.

 

The whole reason why I asked this in the first place was that in order to support multiple developers on a large scale project, I didn't want to have to require the guy working on project 3 to have to have an up to date DLL from project 1 in order to compile his DLL.

 

You have made this clear for me, thank you very much.

[Nerseus]

No problem.

As for team development, you can have the project 1 DLL available on a network if it's not very volatile (changing interfaces every day or so). It would help if the version number of that DLL NOT change for awhile otherwise it won't work - you'll have to recompile Project 3 if Project 1's version changes.

 

You could also make it a requirement that whenever you work on Project 3 you must have Project 1 in the same solution. This works better while Project 1 is undergoing a lot of changes. Once it gets more "stable", it's usually better to put it up on the network just to limit the size of your solutions (if it becomes an issue).

 

-nerseus