3

Given a class like:

class State {
    bool IsLessThan(State);
    int data;
};

The State::IsLessThan(State) method can simply compare data in each class according to some logic. However let's say the data within State is expected to change throughout development and hold different predefined types of data groups which the client decides to add to the state. One way to implement this is:

class State {
    void Add(StateData);
    bool IsLessThan(State);
    Set<StateData> data;
};

Where any derived class of StateData can be thought of as a struct with some data. Assume that if a State does not contain a type of StateData, it has an instance created with default values. Every time a new type of StateData is added to the program, the logic and therefore code in State::IsLessThan(State) will need to be changed.

Assume that the main concern here is architecture extensibility. Can this be improved? Am I missing a better solution?

4
  • Google for "semaphore"
    – user188153
    Nov 19, 2016 at 23:47
  • 2
    That's not really relevant here as it's all on a single thread.
    – Ryan
    Nov 19, 2016 at 23:53
  • I'm seeing a lot of hints that this is in c++. Mind confirming that in the tags? Nov 20, 2016 at 1:51
  • It is C++, I probably should have mentioned that
    – Ryan
    Nov 20, 2016 at 1:53

3 Answers 3

4

To paraphrase your question, you have a class where instances must be able to compare themselves to other instances of the class, but where the contained data can vary and be extended in initially-unpredictable ways. You are concerned that the comparison requirement will be difficult to cleanly solve due to the data variation, and you hope to solve this by having the class contain an extensible StateData class.

Unfortunately, this is just moving the problem from one place to another. Sure, the StateData class can cleanly encapsulate the varying data, but then you have to figure out how to compare differing data structures, and you're once again staring at the original problem.

Unless you can create general rules for comparing the varying data you will be in a world of hurt once the data structures proliferate. To me, this is a strong indication that your design is flawed; either you should put clear constraints on the data to be contained, or the whole premise should be rethought and the data reorganized in some cleaner, more regular fashion.

1

Complex objects are usually compared by their members. Define a "less than" comparison for Set and StateData and compare containing objects delegating to their members. Do not try to implement comparison of objects with arbitrary structure, this usually causes associativity breakdown.

Comparisons of sets are usually poorly defined, you will want to be strict about it. For example, you could say that a Set is less than another Set if all of its members are less than any of members in another Set.

To generalize, if something does not have a well-defined structure, implement operation as part of its stable interface. Client code would not need to know it's structure at all.

0

How to compare objects with expanding amount of data?

Make sure there is a clearly defined order between the various types (and values) of data.

Assume that the main concern here is architecture extensibility.

To solve the problem of implementing bool IsLessThan(State);, you must solve these separate problems:

  • how can you tell if one instance of StateData is less than another instance of StateData, when the instances have different types

  • how can you tell if one instance of SetData is less than another when then have the same type

  • what does it mean for two State instances to compare less than one anohter, based on the contents of a set.

Neither of these has trivial answers, as the answer depends on the problem domain. It also seems (to me) like you are trying to solve the wrong (x-y) problem (which usually means you need more design / refactoring, or just to take a step back and reexamine what you are doing.

You are already talking about comparing objects of different types (specializations of StateData). Does that make semantical sense for all specializations of StateData? (that is, if one of your StateData has an image inside and the other a calendar date, can you really say that one is "bigger" than the other?

Can this be improved? Am I missing a better solution?

Are you sure you are solving the correct problem?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.