[Parseval]

Siema,

Mam klasę X, w zakresie której tworzony jest obiekt klasy Y. Ze względu na unit testy, które będą puszczane na maszynie o innej architekturze potrzebuję podmienić implementację klasy Y tworząc jakiegoś stuba. Jedyną rzeczą jaką chciałbym zmienić w kodzie, to stworzenie interfejsu dla klasy Y, a na etapie kompilacji pod unit testy podmieniać tylko plik źródłowy. Żeby to wszystko ogarnąć, trzeba stworzyć 3 headery (InterfaceY.hpp, Y.hpp i YStub.hpp) i dwa pliki ze źródłami (Y.cpp, YStub.cpp). Kłopot polega na tym: w jaki sposób mogę pod interfejs Y w klasie X przekazywać (przez kompilację) odpowiednią implementację?

#programowanie #programista15k #cpp #cmake #kompilacja #embedded #linux

[Passer93]

https://en.cppreference.com/w/cpp/language/pimpl

EDIT: @Parseval: Ogólnie to nie potrzebujesz tylu plików nagłówkowych. wystarczy jeden interfejs a to implementacje będą się różniły i wybierasz na etapie linkowania jedną z nich.
Jeśli implementacje różnią się data memberami to możesz użyć pimpla.

[Saly]

Mam klasę X, w zakresie której tworzony jest obiekt klasy Y

@Parseval: to klasyczny przykład użycia https://en.wikipedia.org/wiki/Dependency_injection : w skrócie zamiast tworzyć obiekt klasy Y w środku X po prostu dostarczasz go z zewnątrz, najlepiej przez konstruktor.

[Parseval]

@Passer93: Spróbuję zrobić to w ten sposób :)
@Saly: Tego próbowałem uniknąć, żeby nie dokładać do konstruktora implementacji narzędzia (obiekt Y), które jest zależne od architektury.

[Saly]

@Parseval: ale miejsce wyboru implementacji jest tam, gdzie jest wołany kontruktor. Klasa X wie tylko, że będzie używała InterfaceY.

[Passer93]

@Saly: Miejsce wyboru implementacji możę być w CMake'u.

Powiesz że to antypattern.

[Saly]

@Passer93: wolę widzieć po samym kodzie co może wpływać na to, że klasa zmienia swoje zachowanie. Poleganie na systemie budowania (czy linkowaniu) to straszny syf, bo cały ekosystem tworzenia kodu w C++ już jest dostatecznie skomplikowany, żeby dokładać takie coś. Plus niektóre systemy budowania (np. Bazel) nie pozwalają na takie haksy

[SpinOff]

@Parseval: Też bym się skłaniał ku dependency injection. Jeśli nie chcesz tworzyć obiektu Y poza klasą X, to zawsze możesz przekazać klasie X fabrykę obiektów Y.

[Passer93]

@Saly: Rozumiem twój punkt widzenia, ale pliki CMake'a to dla mnie też część "kodu" i łączenie różnych targetów z różnych plików obiektowych to normalna praktyka.

Z CMake'iem jest jak z dżinem, tyle lat go człowiek próbuje okiełznać i nagiąć do swojej woli że jak już się uda to będzie go wykorzystywał do wszystkiego z zemsty xD