Inheritance and Interfaces

  • Thread starter Thread starter shapper
  • Start date Start date
S

shapper

Hello,

I am having a few problems on inheritance and interfaces:

1. Is it possible, or correct, to inherit a class from 2 classes?

2. Can I have the following structure?
MyModel > Contains properties
IMyInterface > Contains methods
MyClass > Inherits MyModel to have its properties and IMyInterface
to implement its methods.

Thank You,
Miguel
 
shapper said:
I am having a few problems on inheritance and interfaces:

1. Is it possible, or correct, to inherit a class from 2 classes?
Click to expand...

In C# you can not inherit implementation directly from 2 classes.
2. Can I have the following structure?
MyModel > Contains properties
IMyInterface > Contains methods
MyClass > Inherits MyModel to have its properties and IMyInterface
to implement its methods.
Click to expand...

You can.

But I am extremely skeptical about an OO design with all
properties in a super class and all methods in a sub class.

Arne
 
Possible?  No.  Correct?  Depends on who you ask.  Multiple inheritance is  
allowed in some other languages (including C++), and some people swear by 
it.  But, it also introduces complexities that others feel outweigh any 
benefits that might be had.

In C#, the closest equivalent is to use interfaces to define whatever  
functionality you want to implement in the class, and then have the class 
implement those interfaces.  You can only inherit one class, but you can  
implement any number of interfaces.


That depends on what you mean by "structure".  The obvious interpretation  
is a "struct", and if so, the answer is "no".  A struct can't inherit  
another struct.

If you simply mean "a data structure", then as long as that data structure  
is a class the answer is "yes".  That said, note that an interface can  
have properties as well.  You should use inheritance when it makes sense;  
that is, your class really _is_ a more specific version of the class it's 
inheriting, and that class provides implementation you need.

If you're just trying to declare some set of class members, but there's  
not a genuine "is a" relationship between your class and the proposed base  
class, then just put everything in an interface and implement the  
interface.  If you need to use an existing implementation, use that  
implementation via composition rather than inheritance (i.e. put an  
instance of that implementation in your own instance, and delegate all the  
interface members to that instance by calling the composited  
implementation from your own implementation of the interface).

Pete
Click to expand...

I am implementing Data and Business Layers to use in my MVC projects.
So I have for example: PostModel, IPostRepository and PostRepository.
PostRepository implements IPostRepository to work with PostModel
(Create, Update, Delete, etc)

Now I am trying to create similar functionality to a custom ASP.NET
Profile provider.
This is a little bit more complex. The profile provider I am using can
be seeing here:
http://weblogs.asp.net/jgalloway/archive/2008/01/19/writing-a-custom-asp-net-profile-class.aspx

And I came up with the following:

MODEL:

public class Profile : ProfileBase {
public String Name {
get { return base["Name"] as String; }
set { base["Name"] = value; }
}
// Other properties
}

INTERFACE:

public interface IProfileProvider {
Profile GetProfile();
Profile GetProfile(String username);
}

PROVIDER:

public class ProfileProvider : Profile, IProfileProvider {
public Profile GetProfile() {
return Create(HttpContext.Current.Profile.UserName) as Profile;
} // GetProfile
public Profile GetProfile(String username) {
return Create(username) as Profile;
} // GetProfile
}

ProfileProvider, as the ULR I provided, it will have a reference in
the Web.Config.

What do you think?

Is this "ok"?

Thank You,
Miguel
 
[...]
  public class ProfileProvider : Profile, IProfileProvider  {
    public Profile GetProfile() {
      return Create(HttpContext.Current.Profile.UserName) as Profile;
    } // GetProfile
    public Profile GetProfile(String username) {
      return Create(username) as Profile;
    } // GetProfile
  }
Click to expand...
ProfileProvider, as the ULR I provided, it will have a reference in
the Web.Config.
Click to expand...
What do you think?
Click to expand...

Looks sort of weird to me.  Just looking at the class "Profile", is it  
your intent that the class be able to return (for example) the "name" via 
the property as well as via the class indexer?

If that's by design, then maybe that's okay.  But ProfileProvider looks 
especially odd.  If I've got a ProfileProvider, which inherits Profile, 
why wouldn't I just use the ProfileProvider when I want a Profile?  What  
is it about ProfileProvider that makes it a Profile, _and_ also something 
that returns Profile instances?

Note that this is not _necessarily_ a problem.  For example, in  
hierarchical data structures, you might see something like this.  Such as  
in the System.Xml.Linq namespace, where an XElement is an XNode, and can  
also return an XNode related to it (or many, for that matter).

But if there's a relationship like that in your data structure, it's not  
readily apparent from your description.  And if there's not a relationship  
like that in your data structure, then the data structure doesn't look  
quite right to me.

Pete
Click to expand...

I am not entirely sure I am doing this right but I am thinking as
follows:

I have the following projects on my solution:

1. MyProject.Core that includes:
- The models (Profile, Post, ...)
- The Profile interface and repositories interfaces

2. MyProject.SqlMembershipProvider (uses ASP.NET Membership)
- Includes the AccountRepository
The AccountRepository uses Account Model.
The account model has many properties, including Profile

2. MyProject.SqlDataProvider
- Includes all repositories that deal with SQL database

3. MyProject.Mvc
- The MVC application

I want to separate Profile Model from the Profile Provider because
later I might use another Membership provider.
For example, my own SQL tables including it in SQLDataProvider or a
XML Provider.
But the profile model and interfaces will be the same. Only the
Provider code will change.

Does this make any sense??

Now, about the Profile class I followed the link I mentioned but I
also found the following Link in MSDN:
http://msdn.microsoft.com/en-us/library/system.web.profile.profilebase.aspx

That contains the code, on the bottom, of a custom profile provider:
using System;
using System.Web.Profile;
namespace Samples.AspNet.Profile
{
public class EmployeeProfile : ProfileBase
{
[SettingsAllowAnonymous(false)]
[ProfileProvider("EmployeeInfoProvider")]
public string Department
{
get { return base["EmployeeDepartment"].ToString(); }
set { base["EmployeeDepartment"] = value; }
}

[SettingsAllowAnonymous(false)]
[ProfileProvider("EmployeeInfoProvider")]
public EmployeeInfo Details
{
get { return (EmployeeInfo)base["EmployeeInfo"]; }
set { base["EmployeeInfo"] = value; }
}

}
public class EmployeeInfo
{
public string Name;
public string Address;
public string Phone;
public string EmergencyContactName;
public string EmergencyContactAddress;
public string EmergencyContactPhone;
}
}

The only thing that is added to this code, as far as I can see, is the
two methods GetProfile to make it easier to get the current user
profile or a another user profile.

Anyway, what do you think?

I am not sure I am planning this right but as far as I understand I
can't find any problem.

Thank You,
Miguel
 
Back
Top