Что такое хороший пример для наследования классов? [закрытый]

Лучший, который я всегда использовал, был Формами.

Вы можете затем иметь

Shape --> Quadrilateral
Quadrilateral --> Rectangle
Quadrilateral --> Trapezoid
Rectangle --> Square
Shape --> Triangle

и т.д.

, Методы затем также легко предположить.

Shape::Area
Shape::Draw
Shape::Intersect (x,y)

Пример:

"Все происходит из Объектного" подхода.

Собака-> Животное-> Живое существо-> Объект

Собака А является Животным, которое является Живым существом, которое в свою очередь является Объектом.

Лучший пример, который я имею, столкнулся (и читайте во многих книгах), тот, который использует Форму.

лучшая вещь об этом состоит в том, что можно очень легко объяснить все понятия (включая жесткие) связанный с ООП как Класс, Объект, Наследование, Абстракция, Инкапсуляция, Полиморфизм, и т.д. любому программисту, не важному из его опыта.

Наследование может быть сложным. Давайте запустимся с самого простого из них всех - наследование поведения. Вот, пожалуйста наследовав поведение только и никакое состояние. Например: И Человеком и Животным являются Одушевленные объекты, которые показывают поведение IsAlive. Использовать Ваш пример:

class LivingThing {
   /* We propose a new type */
  public:
    virtual bool IsAlive() = 0;
    virtual void Birth() = 0;
    virtual void Death() = 0;
};

class Person : public  LivingThing {
    /* A real living thing */
  public:
    virtual bool IsAlive() { return true; }
    virtual void Birth() {}
    virtual void Death() {}
    /* .. and has some special behavior */
    void Marry();
    void Divorce();
};

class Animal: public  LivingThing {
    /* A real living thing */
  public:
    virtual bool IsAlive() { return true; }
    virtual void Birth() {}
    virtual void Death() {}
    /* .. and has some special behavior */
    void Bite();
    void Bark();
};

я записал этому использованию синтаксис C++, если Вы имеете проблемы при понимании какого-либо из него, просто говорите так!

Что относительно

class Weapon 
{
}

class Gun : extends Weapon
{
}

class Knife : extends Weapon
{
}

и.

Мне нравится пример механизмов, поскольку он позволяет, чтобы относительно чистое расширение включало интерфейсы в обсуждение (IAutomaticGearbox, кто-либо?)

Я всегда любил:

class Shape {
}
class Square extends Shape {
}

, Но любой из лучших трех Вы заключаете в кавычки, был бы прекрасен. MountainBike звучит как самое захватывающее. Можно сделать подобные вещи с автомобилями, конечно.

Я предлагаю 'устройства'. Никто действительно не моделирует программное обеспечение использования животных, но они делают устройства модели.

class Device
{
  void start();
  void stop();
  DeviceStatus status { get; }
}

class VideoDevice : Device
{
  ... methods for any/all video devices ...
}

class DiskDevice : Device
{
  ... methods for any/all disk devices ...
}

Я думаю, что Форма является хорошим абстрактным классом. Существуют и 2D и 3D формы. 2D формы обычно имеют область, в то время как 3D формы имеют объем. Оба могут иметь "расположение" или "массовый центр".

Некоторые предложения:

class Shape {..}

class Shape2D extends Shape {...}

class Circle extends Shape2D {...}

class Rectangle extends Shape2D {...}

class Polygon extends Shape2D {...}

class Shape3D extends Shape {...}

class Sphere extends Shape3D {...}

Многие люди используют пример Форм, но это - на самом деле опасное. Проблема возникает, когда Вы интуитивно решаете, что квадрат является подклассом прямоугольника.

Когда дело доходит до поведения, квадрат более ограничен, чем прямоугольник, повреждая замещаемость. Например, мы могли спросить прямоугольный объект изменить его высоту. Если квадрат является подклассом прямоугольника, который означает, что мы должны смочь спросить тот же квадрат. Однако изменение высоты квадрата означало бы не квадрат больше! Конечно, мы могли увеличить ширину соответственно, но это не то, что мы ожидали бы, когда мы должны были спросить объект заявленного прямоугольника типа, который является на самом деле квадратом внизу, для изменения его высоты.

Это звонило принцип замены Лисков , и необходимо знать о нем при выполнении любой серьезной разработки OO.

Квадраты, конечно, sub установил из прямоугольников вместо класса sub . Вот в чем разница между ориентированными на данные и ориентированными на поведение подходами.

Как Jon, я предпочитаю Потоки как пример. Не трудно объяснить, даже непрограммистам и его ориентированному на поведение cleary, избегая counter-intuitivity примера форм.

Автозапчасти могут быть интересными, например, Вы могли бы иметь

class part
{
    OEM
    Manufacturer
    Number
    Description
}

class Tire extends Part
{
   Speed
   Rating

}

Мне нравится Stream иерархия. Идея состоит в том, что что-либо может использовать поток, обычно не заботясь, какой поток это, и отдельные подклассы обрабатывают устройство хранения данных по-другому (например, NetworkStream, MemoryStream и FileStream в.NET).

, Если Вы интересуетесь интерфейсами, затем IEnumerable<T> в.NET, большой - можно выполнить итерации по любому набору, не заботясь, какова базовая структура данных.

Я соглашаюсь с Jon Skeet на его потоковом примере. Возможно, это не прекрасно, но это имеет преимущество перед большей частью примеров здесь:

Это реалистично

, Велосипеды, люди или животные, формы или оружие просто не были бы смоделированы наследованием в реальных проектах. (формы, в частности, совершенно опасны, потому что это не работает .)

Это - мой главный объект неприязни с наследованием. Это слишком часто преподается как что-то, что должно использоваться для выражения каждый иерархия, которую можно найти. Сотрудник является человеком, правильно? Таким образом, класс Сотрудника должен наследоваться классу Человека. Но человеком является также LivingCreature, таким образом, у нас должен быть один из тех классов также. И LivingCreature является также Организм, таким образом, там у нас есть другой класс. И Организм.... не стесняются продолжаться.

я думаю, что было бы хорошо, если бы кто-то, где-нибудь, на самом деле преподавал наследование путем объяснения, когда это должно использоваться, и не, как можно захлопнуть его по любой иерархии, выгодно ли это или нет.

Потоки (или устройства как в примере ChrisW) имеют преимущество, которое они делают смысл . Вы хотите смочь рассматривать все потоки то же, подключены ли они к буферу памяти, файлу или сетевому сокету. И все устройства действительно имеют большое поведение вместе, которое могло правдоподобно быть факторизовано в базовый класс Устройства.