Unexpected answer on a professional interview [closed]

Question

This is a 100% theoretical question, and maybe opinion based.

In a professional interview I got a printed page with a lot of awfully written and improperly formatted code of two classes to analyze them line by line in speech. Let's call these data structures A and B. There was no problem statement or any info about the expected behavior.

However one of their questions really pissed me off.

After identifying the suspected behavior of the algorithm and many potential and actual errors, they asked me to identify one more error. I identified several other obvious problems, but I didn't figure out what they want from me. Well, when they told me the answer it blew my mind. The simplified version of A and B is the following (I left only the methods which are part of their idea):

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
    }
};

Well, the solution is not a compilation, runtime, or logical error. Not even the potential risk of these. The error is the following: since B::setValue sorts the data after you place an element, you cannot test whether the data you access at a given position is the same what you stored at that given position. However with A you can do this. This unmatched behavior between A and B is considered as an error (and they added that it is not an error, but yet it is an error).

I think it's fully a design choice (since the whole point of B is to maintain sorted data) and I wouldn't say this is an error, especially without a problem statement or any information on the expected behavior. It doesn't even violate the idea or concept of polymorphism.

Would you identify it as an error?

Answer 1

We could decide that it is part of the interface of the class A and more specifically a post condition of A::getValue, that A::getValue must return the same value that was (immediately) previously assigned by A::setValue into the same index.

If such post condition is specified, then a derived class that violates the post condition would violate the Liskov Substitution Principle. It would be a design error.

---

It was not specified in the exercise whether such post condition exists, or should exist though. And without the post condition, there is no design error (at least not the error that I'm discussing).

Whether the (presumably assumed by your interviewers) post condition should exist is up to the designer of the hierarchy. Which in your interview was you. Whether the post condition is good design for the hierarchy would depend on what the classes are modeling. If A models something like std::array - and that is what it resembles - then the post condition is definitely a good design choice in my opinion.