Questions while designing OOP hierarchy

When creating inheritance hierarchy, I get confused. Abstract base class should contain only commonly used stuff for inherited classes. But knowing which is commonly used methods, fields and properties is not possible while designing. So I feel free myself 开发者_Go百科to grouping them with abstract classes which inherits hierarchically. This is what I am doing without care about which my real classes where will be in hierarchy because I will find easily a place in comprehensive hierarchy. And also it is highly possible to find some unnecessary abstract classes in middle of hierarchy.

But I don't know is this right way of designing? And which disadvantages can occur in none-perfect abstract hierarchy. I have to give clear example for it. Think chess and pieces. If I have to define pieces like pawn, queen, king etc. Look at below UML diagram.

I divided hierarcy to 2 slided and none-slided pieces after Piece abstract class because I believe that sliding and none-sliding will require different commonly used members.

But I can also divide them directionally because some pieces can go 8 directions, some can 4 directions and some can go to 2 or 3 directions. Grouping them directionally cause some new questions. Where they will be in hierarchy? they will come after sliding classes? If so possible to find four directional grouping under sliding and none-sliding groups and we know that it is not possible to inherited by 2 classes. So for such situations I have to choose interfaces? if directions will never be under both so it is possible to use abstract classes. That's ok then if I found again new common grouping which will not require inherited by 2 classes so I can define it under directions.

In the end of design, all of my pieces can find perfect leaf nodes in hierarchy and this will be really good for future to have enough comprehensive building which I will not need change something in hierarchy.

But what can be disadvantage to creating too large comprehensive hierarchy?

Can be that in auto-complete of IDE can show many unnecessary and strange named abstract base classes which confuse others? what can be other disadvantages?

Way, way too complicated for the task. You're overdoing the OO. This means you will have to fill 20-odd classes with code. You should really simplify this.

Consider thinking about it in terms of attributes (color, isUnderAttack) and behavior (moving). In this case, you only need one class class ChessPiece, which has properties for color and isUnderAttack. You can then use some form of dependency injection. Consider how this code would look:

public class ChessPiece
{
    public enum ChessPieceColor{White, Black}
    private IChessMove behavior;
    public ChessPiece(IChessMove behavior, ChessPieceColor color)
    {
        this.behavior = behavior;
    }
    public void Move()
    {
        behavior.Move();
    }
}

public interface IChessMove
{
    void Move();
}

public class KnightMove : IChessMove
{
    public void Move()
    {
        // code to perform the moving.
    }
}

public class Program
{
    static void Main()
    {
        ChessPiece knight = new ChessPiece(new KnightMove(), ChessPiece.ChessPieceColor.White);
    }
}

Then you would simply code a different IChessMove for each type of piece. Obviously you would need to add more information to the methods here to make it actually work, but it should show you the pattern you should be using here. A class for every possible piece is going way too far, when many have common behaviors.

Ok... The problem is, that inheritacne hierarchies are fragile - they can be easily useless, for example in cases you describe as your concerns. You can design the hierarchy in many ways, as you suggest, but keep in mind the Liskov Substitution Principle and most importantly, that you should not overuse inheritance. Use it only if necessary. You should not use abstract class and inheritance just because you can. I am not good at chess, but do pieces of different colors have different behaviours? There is a famous example of problem with abstraction when creating the inheritance hierarchy. Take a circle and ellipse, which is more abstract? When you try to make any of them superclass of the other, you will end up with inflexible design. Try to understand more about object oriented programming and try to inherit only when no other choice is better.

But what can be disadvantage to creating too large comprehensive hieararchy ?

The disadvantage of having an overly complex model is that it makes the code harder to write, read, and maintain.

It happens though. Its very hard to design thing right on the first shot. Its better not to try.

This is what test driven development is for. Rather then hypothesize on what you need, you use tests to flesh out your requirements which in turns flesh out an implementation. TDD ftw.