Currently we have two classes:
- one that represents a ranking evaluation result (
RankResult)
- And another that represents a selection of best and worst (
KernelResult)
Both classes are in the same hierarchy and inherit from ResultABC.
This makes some common tools have to:
- Either be implemented twice
- or write the tools using LSP (that is, using exclusively the reference and common behavior of the superclass)
The first option adds a maintainability problem and unnecessary code growth. The second forces us into two scenarios that are not very desirable: one is to fill the tool with conditionals (or in other words, ruin polymorphism), and the other is to move all behavior to the superclass even though some may not make sense in the subclass.
Perhaps this last alternative leads us to another possible solution which is to entirely eliminate the class hierarchy and simply treat everything as a ranking and kernels as behavior of that ranking.
It's also important to mention that the concept of kernel, strictly speaking, is exclusive to ELECTRE methods. Therefore, it's also a strong criticism of why we should have that concept common to all aggregation functions.
Link to a prototype of a solution with only one class
Currently we have two classes:
RankResult)KernelResult)Both classes are in the same hierarchy and inherit from
ResultABC.This makes some common tools have to:
The first option adds a maintainability problem and unnecessary code growth. The second forces us into two scenarios that are not very desirable: one is to fill the tool with conditionals (or in other words, ruin polymorphism), and the other is to move all behavior to the superclass even though some may not make sense in the subclass.
Perhaps this last alternative leads us to another possible solution which is to entirely eliminate the class hierarchy and simply treat everything as a ranking and kernels as behavior of that ranking.
It's also important to mention that the concept of kernel, strictly speaking, is exclusive to ELECTRE methods. Therefore, it's also a strong criticism of why we should have that concept common to all aggregation functions.
Link to a prototype of a solution with only one class