Czy istnieje wzorzec projektowy do zarządzania głębokimi relacjami wiele do wielu?

Mam problem ze zdefiniowaniem tego wzorca danych, na który natrafiłem podczas pracy nad kilkoma aplikacjami.

Składa się ona z:

1. Typ obiektu, który składa się z wielu samych obiektów
2. Drugi typ obiektu, w którym każda instancja „ma wiele” pierwszego obiektu
3. I każdy z podobiektów pierwszego obiektu można modyfikować według każdego powiązania z drugim typem obiektu.

Prostym przykładem może być:

1. Kurs programowania składający się z zestawu lekcji
2. Lekcje składają się z zestawu zadań.
3. Kurs może być przypisany do ucznia.
4. Jednak po przypisaniu kursu do ucznia każdą lekcję i / lub zadanie można dostosować do tego ucznia, z usunięciem i uzupełnieniem, do momentu, w którym oryginalny kurs może nie zostać rozpoznany.

W moich rozwiązaniach skutkuje to:

Po przypisaniu kursu do studenta kurs jest ładowany do pamięci. Następnie dla każdego pod-obiektu generowany jest obiekt relacji uczeń / pod-obiekt z odpowiednimi metadanymi. Zasadniczo używam oryginalnego obiektu jako szablonu do generowania wymaganych obiektów, które można dostosowywać.

Powoduje to powstanie ogromnej ilości danych, ponieważ podobiekty stają się bardziej złożone i numerowane. Zastanawiam się, czy istnieje jakaś optymalizacja lub wzorzec, aby zmniejszyć ilość logiki / złożoności wymaganej do manipulowania tym wzorcem danych.

Widzę kilka opcji w zależności od tego, czego potrzebujesz: (1) jeśli istnieje wiele unikalnych instancji zgodnych ze wspólnym algorytmem, (2) jeśli istnieje wiele podobnych obiektów lub wygenerujesz obiekty w czasie wykonywania, oraz (3) jeśli chcesz dynamicznie modyfikować zachowanie obiektu podczas działania. Uwaga: w razie potrzeby możesz połączyć wszystkie wzory, o których tu wspominam.

1. Jeśli każdy „drugi typ obiektu” jest unikalny, ale zachowuje się podobnie, można użyć Wzorca szablonów . Wygląda na to, że to robisz. Ale, żeby to wyjaśnić, twoja abstrakcyjna klasa podstawowa ma zaprogramowany ogólny algorytm; niektóre kroki tego algorytmu są zaimplementowane w klasach pochodnych.

2. Jeśli utworzysz wiele obiektów lub jeśli tworzenie obiektów w czasie wykonywania jest dla Ciebie ważne, możesz użyć Wzorca fabrycznego .

3. A jeśli chcesz dynamicznie zmieniać zachowanie, Stategy Pattern może działać. Na przykład, jeśli student regularnego programu nauczania zostanie uznany za osobę specjalną lub przejdzie do programu przyspieszonego. Działa to poprzez skomponowanie „ucznia” obiektu, który reprezentowałby klasę podstawową programu nauczania. Program nauczania zostanie przypisany do pochodnego programu nauczania w konstrukcji studenta (to brzmi dziwnie) i może zostać ponownie przypisany do innego pochodnego programu nauczania później.

(Tylko do Twojej wiadomości, jeśli używasz (3) Wzorca Strategii z C ++, będziesz musiał przeszacować wartości dla kompozycji.)

Aby przechowywać swoje obiekty i drugie obiekty, warto rozważyć wzorzec iteratora (aby je cyklicznie przełączać, dodawać, usuwać, sortować itp.).

Dobrym odniesieniem jest wzorce wzornictwa Head First , które obejmują wzorce, o których wspominam i ich implementację. Pracują w Javie.

Trudno mi uwierzyć, w obecności magazynu danych lub uporczywości, że trzeba mieć obiekty o takiej głębokości w dowolnym momencie w czasie wykonywania. Czy dotyczy to GUI CRUD? Jeśli tak, to sugeruję zmianę twojego podejścia od samego początku. TO ZNACZY:

Zidentyfikuj podbudowę niezbędną dla studenta, aby pokazać, a stanowo przechowywać swoje pochodzenie z powrotem do indeksu db i statelessly aktualizację, która, przechodząc do lub z widzenia i db backend.

Indywidualny kurs dla każdego ucznia do tego stopnia, że ​​oryginalny kurs jest nie do poznania, sugeruje, że oryginalny kurs jest po prostu „domyślnym” odniesieniem. Chciałbym stworzyć klasę o nazwie CustomizedCourse (lub ich listę) i mieć tę (lub jej listę) jako właściwość ucznia. Kurs CustomizedCourse może zawierać odniesienie do oryginalnego kursu dla „referencyjnego” użycia, ale główna praca i dane znajdują się w samym kursie CustomizedCourse.