Avoiding Inheriting All Things from Base Class

I was thinking a scenario like that :

class Utopia => A Base Class which pass it's fields and methods to derived classes.

class Watashi => A derived class, derived from Utopia and inherits everything

class Baka => A derived Class, Inherits some fields from Utopia

There are some types above and Type Baka should inherit some specific fields and methods but how ? How can I specify fields and methods that only Baka will inherits whereas Watashi inherits everything from Utopia.

Sample Code :

class Utopia {
   public string Moshi;

   [Exclude(ClassName("Baka"))]
   public string HaveIt;
}

class Baka : Utopia 
{
 // only开发者_运维知识库 Moshi appears here
 base.[Moshi]
}

class Watashi : Utopia 
{
  base.[Moshi][HaveIt];
}

If I want to use Polymorphism :

   Utopia _utopiaBaka = new Baka();
   _utop.[Moshi];

   Utopia _utopiaWatashi = new Watashi();
   _utopiaWatashi.[Moshi][HaveIt];

And of course Framework also checks the derived class whether they are base classes for other types.

Split Utopia into more than one class. Have one class that any class can inherit from, so Baka would inherit from that.

Then, extend this PartialUtopia class, add the rest of the methods and have Watashi inherit from that.

This way you can have a way to have classes pick which methods they need by which base class they extend.

Thats not how inheritance works in OOP. Baka inherits everything from Utopia just like Watashi.

This is not how inheritance works, you would have to split up your classes. If you and your girlfriend get a child, you can't chose that it only inherits genes for blue eyes and a musculus body :)

I would suggest researching the differences between public, private, and protected. It sounds like that whats your looking for.

http://msdn.microsoft.com/en-us/library/ms173149.aspx

What you want to do is completely incompatible with the concept of inheritance in Object Oriented programming. It is like asking "Why is blue blue?" if blue was not blue it would not be blue.

When one class (Baka) inherits from another (Utopia) this means (in OOP) that Baka can do everything that Utopia can - OOP languages offer features that rely upon this and if you were able to override you would cause horrible exceptions.

For example, if I have a method that takes a class of type Utopia as a paramter as below:

public void TakesUtopia(Utopia utopia)
{
    utopia.BePerfect();
}

We can also pass in classes of type Watashi and type Baka because they both inherit from Utopia. Baka, by inheriting from Utopia is guaranteed to have an implementation of the method BePerfect()

If somehow an instance of Baka did not have an implementation something horrible would happen.

To further this - consider what happens when TakesUtopia relies upon the behaviour of Utopia. Say for example utopia exposes a PriceOfHappiness property.

public string TakesUtopia(Utopia utopia)
{
     if (utopia.PriceOfHappiness() > 100)
     {
          return "Can't buy happiness';
     }
}

When writing my TakesUtopia method, should I be expected to write code to deal with the possiblity that any method within utopia is not implemented? What would such methods do when they are called?

What are you trying to do specifically? If you are concerned about a subclass overriding a given method implementation, you can always declare a method sealed:

class FooBase
{
    sealed void Bar()
    {
        //base implementation
    }
}

class FooDerived
{
    void Bar()  //poof! compilation error
    {
        //never reached
    }
}

Alternatively, you can have your inheriting subclass inside the assembly and the non-inherting outside. Just use protected internal.

There's two different concepts: interfaces and inheritance. Basically they're two different questions. One is "How do I want to interact with this object?" (interface). The second is "How does this object work internally?" (inheritance).

In classic OOP examples, consider a base class:

class Shape {
    virtual void draw();
    virtual int size();
}

This is an interface, it defines how you work with different shapes. Now consider these:

class Square : Shape {
    ...
}

class Circle : Shape {
    ...
}

While the interfaces to these two classes would be the same (draw() and size()), the implementations would not share anything in common. Is the drawing code for a circle really relevant at all to the drawing code for a Square? No, they just share the same name & desired result.

The reason I bring this up is because if you want some classes to inherit some members of other classes, then you may have the problem that you're confusing inheritance with interfaces. AFAIK, C++ doesn't support interfaces (I'm probably wrong about this). But you could fake this with 'pure virtual' classes (like the Shape above).

class Shape {
    virtual void draw();
}

class EdgyShape : Shape {
    virtual int width();
    virtual int height();
}

class RoundyShape : Shape {
    virtual int radius();
}

Now you have interfaces with a heirarchy, but no implementation at all.

class Circle : RoundyShape {
    ...
}

class Rectangle : EdgyShape {
    ...
}

class Square : Rectangle {
    ...
}

So Circle and Rectangle share no code with each other, while Rectangle and Square do. And all 3 share the same basic Shape interface, with some additions depending on the type.

Maybe this sheds light on how to refactor your class heirarchy so you can split them up better?