Interfejsy a dziedziczenie jednobazowe

Witam

Moje pytanie odnosi się do interfejsów i dziedziczenia jednobazowego. Załóżmy, że mamy aplikację bazodanową, która operuje na kilku tabelach:

-Pracownicy
-Wypłaty
-Osiągnięcia
-Typ adresu zameldowania

W sumie do każdej tabeli możemy coś dodać, usunąć, zmodyfikować, wyszukiwać, wyświetlać - to są ich operacje wspólne, zatem można stworzyć klasę bazową z tymi metodami i polimorficznie wywoływać je w instacjach tej klasy np. w obiekcie Pracownicy. Tutaj nie widzę zastosowania interfejsów ( bynajmniej nie trzeba ).

Można by podejść do tego inaczej:

Stworzyć klasę TABELA, w której będą zawarte implementacje interfejsów class TABELA: IOperacjeTabele,

które rozwiązanie jest rozsądniejsze??? ( w drugim wariancie metoda Wyszukaj ) musiałaby być w interfejsie deklarowana kilka razy ( struktura zgodna z atrybutami tabeli ) . Więc to się trochę mija z celem

Liczę na wypowiedzi.

Pozdrawiam!

( bynajmniej nie trzeba ).
Nie „bynajmniej” tylko „przynajmniej”. To pierwsze słowo znaczy trochę co innego.

Stworzyć klasę TABELA, w której będą zawarte implementacje interfejsów class TABELA: IOperacjeTabele,
I dla każdej metody w klasie robić osobny interfejs? Trochę przesada.

Zawsze używaj interfejsów. W twoim przykładzie można by zrobić interfejs dla każdej tabeli. Dodatkowo staraj się nie obciążać obiektów zbyt wieloma zadaniami. Jeżeli twoje tabele mają za zadanie obsługiwać dostęp do danych, to nie pakuj tam jeszcze wyświetlania.

Mr Obvious napisał(a):

Zawsze używaj interfejsów. W twoim przykładzie można by zrobić interfejs dla każdej tabeli. Dodatkowo staraj się nie obciążać obiektów zbyt wieloma zadaniami. Jeżeli twoje tabele mają za zadanie obsługiwać dostęp do danych, to nie pakuj tam jeszcze wyświetlania.

Wtedy aby nie obciążać obiektów zadaniami jak z tego wybrnąć? Stworzyć dodatkowy obiekt? ( instancje klasy? )

Mr Obvious napisał(a):

Zawsze używaj interfejsów. W twoim przykładzie można by zrobić interfejs dla każdej tabeli.

I jaki z tego zysk?

Mnie się wydawało, że w pierwszym przypadku można było stworzyć klasę abstrakcyjną, zdefiniować w niej metody wirtualne, a potem stworzyć np. klasę pracownicy, która by dziedziczyła z klasy abstrakcyjnej ( tabela ) i tutaj przysłaniać i definiować metody zawarte w klasie abstrakcyjnej.

Z drugiej strony mogę napisać interfejs ( zdeklarować metody, funkcję ) i przy stworzeniu klasy Pracownicy podłączyć ten interfejs do niej.

Co lepsze?

Tak naprawdę spotkałeś się z problemem, z którym spotkali się np. twórcy popularnych ORM. Część z nich uznała, że encja, która musi dziedziczyć z jakiejś bazowej klasy frameworka do obsługi baz danych wygląda źle i lepiej będzie, gdy nie będzie sztywnego powiązania pomiędzy nimi, a konkretnym ORM. Plus jest niewątpliwie taki, że swój model nawet bez rekompilacji możesz wykorzystać w różnych sytuacjach, nie tylko w połączeniu z twoim oryginalnym kodem od baz danych. Takie podejście nawet doczekało się swojej nazwy: najpierw w Javie: POJO, a później w .NET: POCO (plain old java / clr object). Możesz znaleźć na ten temat więcej informacji wklepując właśnie ten akronim do wyszukiwarki.

somekind napisał(a):

Mr Obvious napisał(a):

Zawsze używaj interfejsów. W twoim przykładzie można by zrobić interfejs dla każdej tabeli.

I jaki z tego zysk?

Promuję zasadę kodowania pod interfejs. Dzięki temu mamy większą elastyczność poprzez zmniejszenie powiązań z konkretną implementacją. Dobre narzędzie do zwiększania abstrakcji.

Ciekawski napisał(a):

Mnie się wydawało, że w pierwszym przypadku można było stworzyć klasę abstrakcyjną, zdefiniować w niej metody wirtualne, a potem stworzyć np. klasę pracownicy, która by dziedziczyła z klasy abstrakcyjnej ( tabela ) i tutaj przysłaniać i definiować metody zawarte w klasie abstrakcyjnej.

Z drugiej strony mogę napisać interfejs ( zdeklarować metody, funkcję ) i przy stworzeniu klasy Pracownicy podłączyć ten interfejs do niej.

Co lepsze?

To i to. Możesz mieć interfejs bazowy, jego implementację jako klasę bazową i klasa Pracownicy, może po nich dziedziczyć, jednocześnie implementując interface Pracownicy, który rozszerza interfejs bazowy. Jedno nie wyklucza drugiego.

@Rev
Ja to rozumiem tak, że on nie ma tutaj na razie żadnych encji, tylko wymyśla implementację wzorca DAO. O ile encja może być zwykłym starym obiektem, to już sam dostęp do źródła danych nie bardzo.

Na razie podsumuję i będę pytał dalej.

Wyjścia, które są dobre:

1. Pod każdą tabele ( klasę ) kodować dla niej osobny interfejs ( dla Pracownicy , IPracownicy itd... ),
2. Stworzyć klasę abstrakcyjną, w niej metody wirtualne i z niej dziedziczyć.
3. Stworzyć klasę, podłączyć do niej interfejs, który zawiera jakieś wspólne metody ( suma sumarum może to być klasa abstrakcyjna ) i jednocześnie dodatkowo podłączyć do niej interfejs, który tą klasę uzupełni.

Dobrze rozumuje?

Ciekawski napisał(a):

Wyjścia, które są dobre:

1. Pod każdą tabele ( klasę ) kodować dla niej osobny interfejs ( dla Pracownicy , IPracownicy itd... ),
2. Stworzyć klasę abstrakcyjną, w niej metody wirtualne i z niej dziedziczyć.
3. Stworzyć klasę, podłączyć do niej interfejs, który zawiera jakieś wspólne metody ( suma sumarum może to być klasa abstrakcyjna ) i jednocześnie dodatkowo podłączyć do niej interfejs, który tą klasę uzupełni.

1. Tworzenie zestawu prawie identycznych interfejsów, a z każdy z nich będzie implementowała tylko jedna klasa jest moim zdaniem bez sensu.
2. To brzmi znacznie lepiej, jeszcze niech ta klasa będzie generyczna, to w ogóle będzie wzorzec projektowy repozytorium.
3. Nie wiem o co chodzi, ale brzmi trochę jak Orbit Oriented Programming. ;)

"To brzmi znacznie lepiej, jeszcze niech ta klasa będzie generyczna, to w ogóle będzie wzorzec projektowy repozytorium."

Mam nadzieję, że to nie ironia :-)

Co do ostatniego to mniej więcej tak:

 PRACOWNICY:TABELA, IPracownicy

Myślę, że moża dziedziczyć z jednej klasy i przy okazji podłączyć interfejs.

Przeanalizuj sobie przykład
http://www.remondo.net/repository-pattern-example-csharp/

Tylko pamiętaj, że nie ma rzeczy idealnych, każde rozwiązanie ma swoje plusy i minusy. Musisz trochę kodu napisać, nawet "złego", żeby zobaczyć światełko w tunelu ;)

Generalnie chyba każdy uczący się powinien zaimplementować sobie różne wzorce "bazodanowe" - co najmniej: active record, DAO i repozytorium.

Witam

Otóż nurtuje mnie jeszcze jedna rzecz. Podtrzymanie połączenia bazodanowego w całym programie. Do tej pory polegało to na stworzeniu instancji klasy, która zawiera ów połączenie i wywołać metodę. Chodź lepiej na pewno stworzyć klasę Połączenie i w niej statyczną metodę, wtedy nie trzeba tworzyć instancji. Czytałem coś o wzorcu Singleton, który ów funkcje spełnia? Czy błądze? Pozdrawiam!