Architektura i dziedziczenie pomiędzy klasami

0

Cześć!

Od razu załączam poglądowy rysunek:
io_diagram.jpg

Powyżej stan obecny i pożądany. Myślę, że stan obecny jest łatwy w zrozumieniu.
Co jest najważniejsze z tego stanu?

  • To, że klasa zawierająca (Manager) i zawierana (SpecificObjectIf) dziedziczą z tego samego interfejsu, co oznacza, że funkcja, której używają obie klasy ma tę samą sygnaturę.

Okey. Co chcemy zmienić? Co chcemy osiągnąć?
W skrócie: chcemy, żeby klasa Manager miała metodę getParam, która będzie przyjmowała parametr int.

Niby proste, ale nie do końca:

  1. jak dodamy taką metodę w interfejsie ConfigIf, to klasa dziedzicząca po SpecificObjectIf będzie musiała ją sobie zaimplementować, co jest tej klasie zupełnie niepotrzebne
  2. jak byśmy dodali tę metodę tylko do interfejsu ManagerIf, to clang zacznie nam mówić: hidden overloaded virtual function ... declared here: different number of parameters

Wyłączenie tego błędu clanga nie wchodzi w grę.

W związku z powyższym chciałem zapytać Was o zdanie: jakie najbardziej optymalne rozwiązanie tu widzicie?
Jednym z takowych może być rozdzielenie tego interfejsu ConfigIf, ale chciałem poznać jeszcze inny punkt widzenia.

Dzięki z góry!

0

A co Cię blokuję przed dodaniem tej metody jako nie wirtualnej bezpośrednio do Manager?

6

Zawsze jak widzę diamond inheritance to jestem przekonany, że ktoś gdzieś podczas designu popełnił błąd. Może to ładnie wygląda w UML-u, ale jest szalenie niepraktyczne.
Niemniej jednak:

#include "all.hpp"

struct ConfigIf
{
    int getParam() { return 42; }
};

struct ObjectIf : virtual ConfigIf
{
};

struct SpecificObjectIf : ObjectIf
{
};

struct ManagerIf : virtual ConfigIf, SpecificObjectIf
{
    using ConfigIf::getParam;
    int getParam(int x) { return x; }
};

int main()
{
    ManagerIf m;
    DBG(m.getParam());
    DBG(m.getParam(0));
}

https://wandbox.org/permlink/tVRIksoucXT968oQ

3

Offtopic: A mnie zastanawia ten suffix: If.

W każdym razie, nadużywanie dziedziczenia jest plagą, która psuje OOP. To zawieranie abstrakcji (a nie dziedziczenie) jest główna siłą OOP.

2

Czemu nie załatwić to prymitywnie prosto:

  • int ConfigIf::getParam(int index=-1);
  • int ManagerIf::getParam(int index=-1) { return index<0?ConfigIf::getparam():mObjects[index].getParam(); }

Wiem że każdy lubi się bujać, ale żeby aż tak .... :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1