Объектно-ориентированное программирование - путаница в дизайне классов

Question

Я пытаюсь обернуть голову вокруг объектно-ориентированного программирования.

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

Давайте возьмем иерархию классов:

class Fruit {
    void Eat() {

    }
}

class Apple extends Fruit {

}

Очевидно, что вы можете использовать Fruit полиморфно, если Eat() является виртуальным. Но имеет ли это смысл? Фрукты не могут есть сами!

Должен ли фруктовый объект передаваться человеческому объекту с функцией Eat()?

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

Answer 1

Большинство человеческих языков следуют структуре предложения (для простых утверждений), равной Объект субъектного глагола

В языках ООП, таких как c ++, не совсем иронично, объект является объектом, и он идет первым, поэтому нормальный порядок меняется на обратный:

Так что это «базовый» шаблон в c ++: -

object.verb( subject );

Это на самом деле мусор. Большинство классов разработано с интерфейсом subject.verb (object). Знание SVO, однако, позволяет проверить, был ли интерфейс класса спроектирован так, чтобы быть правильным (в данном случае это не так).

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

Answer 2

Вы правы, что, вероятно, eat () будет методом человека, млекопитающего или плода. У самого плода, вероятно, нет поведения, и, следовательно, нет методов.

Я не часто рассматриваю преимущества ОО в реальности для отображения реальных вещей в Объект. Это возможно потому, что мы имеем дело с менее осязаемыми понятиями, такими как «Счета-фактуры» и «Заказы».

Я вижу, что основной выигрыш от ОО заключается в структуре, которую он привносит в мой код. В реальном мире Счета-фактуры и Заказы на самом деле не делают ничего, но в моем коде они делают. Таким образом, программный заказ может быть гораздо ближе к комбинации данных, представляющих заказ, и некоторому человеческому бизнес-процессу, подходящему для заказа.

Answer 3

Если фруктовый объект лучше передать человеческому объекту, у которого есть Eat () функционировать?

Да.

Но программные объекты, как правило, более абстрактны, чем этот наивный пример. В реальном мире компьютерного программирования такие объекты, как фрукты и люди, обычно представляются в виде атрибутов в базе данных. Потребление и обработка таких данных будет осуществляться в объектах программирования.