Интервью объектно-ориентированного проектирования [закрывается]

Есть замечательный плакат для Принципа замены Лискова , который гласит: «Если он выглядит как утка, крякает как утка, но нужны батарейки, у вас наверняка есть неправильная абстракция ". И это быстрый ответ - некоторые из объектов могут быть как животными, так и пищей, поэтому, если вы не хотите идти по пути множественного наследования, тогда схема классификации неверна.

Как только вы преодолели это препятствие, остальное не ограничено, и вы можете ввести другие принципы дизайна. Например, вы можете добавить интерфейс IEdible, который позволяет использовать объекты. Вы можете использовать аспектно-ориентированный подход и добавить декораторы для плотоядных и травоядных, и это позволит потреблять объекты только правильного класса.

Дело в том, чтобы уметь думать на ногах, видеть и объяснять различные аспекты проблемы и хорошо общаться. И, возможно, не , чтобы застрять на ограничении «один правильный ответ».

Я бы посоветовал ему это поцарапать. Ужасная абстракция. Не говоря уже о том, что нам не дается никакого контекста. Абстракции не возникают из воздуха или из «идеи» о том, что «правильно». Покажите мне, какую проблему вы пытаетесь решить в первую очередь, чтобы мы могли оценить эту абстракцию.

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

Создайте интерфейс Eatable (или вы можете называть его Food , если хотите), и поскольку у нас нет контекста, то я ' Предположим, это программа для игрушечной консоли, которая просто печатает:

<X> ate <Y>

, поэтому все, что нам нужно для этого интерфейса, - это метод getFoodName () .

Для проверки ошибок вы можете создать набор методов isXFoodType , например, ] isGrassFoodType () , isMeatFoodType () и т. д. Реализация Cow Eat (Eatable e) будет проверять isGrassFoodType () , а в случае сбоя выводит:

"Cow can't eat " + e.getFoodName()

Алан Кей, придумавший термин «объектно-ориентированное программирование», сказал: «ООП для меня означает только обмен сообщениями, локальное сохранение и защиту, а также скрытие процесса состояния и крайнее позднее связывание. из всех вещей ».

Попытка решить эту« проблему »в модели данных звучит для меня как противоположность позднему связыванию: зачем вам компилятор, чтобы обеспечить это? Я бы вообще не стал беспокоиться о смене модели. Если вы пропустили что-то, что вы не можете есть, вы выдаете исключение - как и в реальной жизни, почти всегда!

Вот некоторые мысли по поводу этого вопроса интервью:

Я согласен с Сайлонским Котом: такая абстракция не работает без множественного наследования (даже если это Java-подобные интерфейсы.)

Я бы создал две формы наследования:

Животное:

• Плотоядное животное
• Травоядное животное

Пища:

• Мясо
• Овощное

Метод «съесть» двух видов животных (Я игнорирую всеядных, насекомоядных и многие другие виды) будет специализироваться на различных видах пищи. Если мы используем такой язык, как Java, то Food будет интерфейсом.

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

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

Все, что есть, есть Вещи, которые могут иметь атрибут Имя. Но все там на каком-то уровне - Еда; если он может что-то съесть, то и что-то может это съесть. Я мог бы сделать Food родительским классом, и дать ему метод, который возвращает логическое значение, чтобы проверить, может ли объект параметра съесть текущий объект.

Итак,

class Food {
    boolean canBeEatenBy(Food hungryObject)
    String name
}

Кажется, это простейшая иерархия классов, которая подходит для всего, что мне может понадобиться на первом проходе?

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

Двойная отправка , возможно?

Any animal is food, any vegetable is food. And in fact a tiger can be eaten by a cow. (The prion disease scrapie is spread by feeding infected sheep neural tissue to uninfected sheep.)

You could have a hierarchy of species, ala Linnaeus, both animal and vegetable. Each species is a Singleton, and it has a List that records its typical diet. Ditch the Food hierarchy entirely, it only confuses things.

And, if your only problem is recording diet for each species, then the multiple Species classes are unnecessary. Just have a single Species class with the species name as one instance variable and the List as another.

Если вы ожидаете, что система станет очень большой, я бы предложил разделить на подклассы растение / мясо и травоядное / плотоядное / всеядное.

Убедитесь, что система имеет стандартный интерфейс для всех растений / животных под названием getFoodName () и getFoodType (), вы можете добиться этого, создав родительский класс для растений / животных, называемых видами.

Проблема, которую я мог бы увидеть с подклассом растений / мяса и плотоядных / травоядных, заключается в том, что сурикат является плотоядным животным, но, вероятно не может есть носорога (может быть лучший пример), поэтому необходимы некоторые ограничения, помимо «Я ем мясо, вы едите растения».

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

Еда должна быть интерфейсом, поэтому растение и животное тоже могут быть едой.

abstract Класс Animal должен иметь метод eat, принимающий в качестве параметра Food.

подклассы Animal: Carnivore, Herbivore и Omnivore должны иметь свою собственную версию еды.

Например, для Carnivore:

 private void eat(Food food)
 {
      if(food instanceof Animal)
      {
           happilyEat();
      }
      else
      {
           sniff&TurnAway();
      }
 }

Проблемы решены.

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