#technologia #programowanie #csharp #programista15k
Hej programiści, poradźcie coś.
Mam sobie klasę bazową i kilka klas potomnych. W każdej z nich chcę mieć funkcję zwracającą listę wybranych właściwości (List<PropertyInfo>). Normalnie można to zrobić nadpisując po prostu metodę, ale ponieważ będzie ona wywoływana wielokrotnie wymyśliłem, że może ją zrobić statyczną, tym bardziej że lista taka będzie identyczna dla wszystkich instancji danej klasy. Problem w tym, że metod statycznych nie można nadpisywać. Można je niby ukrywać przez new, ale może jest jakiś lepszy i bardziej elegancki sposób?
Hej programiści, poradźcie coś.
Mam sobie klasę bazową i kilka klas potomnych. W każdej z nich chcę mieć funkcję zwracającą listę wybranych właściwości (List<PropertyInfo>). Normalnie można to zrobić nadpisując po prostu metodę, ale ponieważ będzie ona wywoływana wielokrotnie wymyśliłem, że może ją zrobić statyczną, tym bardziej że lista taka będzie identyczna dla wszystkich instancji danej klasy. Problem w tym, że metod statycznych nie można nadpisywać. Można je niby ukrywać przez new, ale może jest jakiś lepszy i bardziej elegancki sposób?
- Najlepsze
- Wszystkie komentarze
Już na starcie wygląda to źle. Dlaczego nie niezależne klasy i wspólny
Więc albo przemyślenie i zaprojektowanie logiki od nowa i refaktoryzacja w kierunku kompozycji zamiast dziedziczenia (jeżeli masz taką możliwość, bo nie zawsze realia w projekcie na to pozwalają), albo zostawić tak jak jest.
Jeżeli cię to kopnie w dupę
- robisz statyczne pole trzymające tę listę propertiesów, inicjujesz ją w statycznym konstruktorze klasy
- robisz niestatyczną (czyli wirtualną) metodę zwracającą referencję do kolekcji z pola statycznego
Przy czym dobrze zadbać o to aby lista była niemutowalna i obiekty w tej liście również, aby uniknąć kuku jak ktoś ją
ale jak napisal kolega wyzej, to juz jest przekombinowanie i szkoda energii.
Wiem, że pola i metody nie mogą być statyczne dla zachowania polimorfizmu. Dlatego pytam, czy można to jakoś obejść. Chodzi mi właśnie o to, by dostać obiekt, który zależy w sumie od typu (klasy), a nie od instancji.
Kolekcję zrób statyczną, zadbaj żeby się nie inicjalizowała wiele razy jednocześnie z wielu wątków jeśli trzeba i tyle.
@MostlyRenegade: Jak chodzi tylko o typ, to może wystarczy stworzyć taką listę w konstruktorze w klasie bazowej, bo przez refleksje będziesz miał informacje o typie pochodnym, coś jak tu: https://dotnetfiddle.net/Voa78r
ja bym zrobił metode bazowa i nadpisywał w potomnych jesli chce coś dodac i dodawał na koniec
[ExportProperty(Order=100)]
i zrób metode które pobiera properyInfo tylko z tym atrybutem i sortuj po Order i juz
Jednocześnie wygląda na to, że trzeba będzie zupełnie ominąć zagadnienie stosując jakąś inną strukturę danych, ale to zostawię sobie na później. Najpierw funkcjonalność, potem refactoring.
@MostlyRenegade: tak się nie robi. W podejściu z interfejsami wsadasz ten kod do jednej klasy. Te metody, które są zmienne wpychasz do osobnego interfejsu a twój obiekt ze stałymi metodami trzyma obiekt implementujący interfejs jako pole.