Неожиданный ответ на профессиональное интервью

Question

Это 100% -ный теоретический вопрос, и, возможно, мнение основано.

В профессиональном интервью я получил печатную страницу с большим количеством ужасно написанного и неправильно отформатированного кода двух class es, чтобы анализировать их по строкам в речи. Назовем эти структуры данных A и B. Не было никаких проблем или каких-либо сведений о ожидаемом поведении.

Однако один из их вопросов действительно разозлил меня.

После определения подозрительного поведения алгоритма и множества потенциальных и фактических ошибок они попросили меня идентифицировать еще одну ошибку. Я определил несколько других очевидных проблем, но я не понял, чего они хотят от меня. Ну, когда они сказали мне ответ, он взорвал мой разум. Упрощенная версия A и B является следующее (я оставил только те методы, которые являются частью их идеи):

template <typename T> 
class A 
{ 
public: 

    // elements are dynamically allocated on the heap 

    const T& getValue(unsigned i) const // I'm not even sure it was const 
    { 
     // return element at position 'i' 
    } 

    virtual void setValue(unsigned i, const T &value) 
    { 
     // sets the element at position 'i' 
    } 
}; 

template <typename T> 
class B: public A<T> 
{ 
public: 

    virtual void setValue(unsigned i, const T &value) 
    { 
     // set the element at position 'i' using A<T>::setValue() 
     // then sort all elements in descending order 
    } 
}; 

Ну, решение не компиляции, выполнения, или логическая ошибка. Даже потенциальный риск для них.Ошибка : с B::setValue сортирует данные после размещения элемента, вы не можете проверить, являются ли данные, которые вы получаете в данной позиции, то же, что вы сохранили в этой заданной позиции. Однако с A вы можете это сделать. Это непревзойденное поведение между A и B рассматривается как ошибка (и они добавили, что это не ошибка, но все же это ошибка).

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

Не могли бы вы назвать это ошибкой?

Answer 1

Мы могли бы решить, что она является частью интерфейса класса A и более конкретно пост состояние A::getValue, что A::getValue должны возвращать одинаковое значение, которое было (сразу), ранее назначенный A::setValue в тот же индекс.

Если такое условие сообщения указано, то производный класс, который нарушает условие сообщения, будет нарушать Liskov Substitution Principle. Это будет ошибка дизайна.

---

В упражнении не указано, существует ли такое условие сообщения или должно существовать. И без условия сообщения, нет ошибки проектирования (по крайней мере, не ошибка, которую я обсуждаю).

Должно ли существование (предположительно предполагаемое вашим интервьюером) существовать до конструктора иерархии. Который в вашем интервью был вами. Является ли условие post хорошим дизайном для иерархии, будет зависеть от того, что моделируют модели. Если A моделирует что-то вроде std::array - и это то, на что это похоже - тогда состояние сообщения, безусловно, является хорошим выбором дизайна, на мой взгляд.