Korzystanie z dziedziczenia obiektów biznesowych

Zanim założysz nowy obiekt biznesowy zastanów się, czy w projekcie nie istnieje już obiekt podobny. Jeśli taki istnieje, to być może nie powinieneś w ogóle tworzyć nowego obiektu, tylko rozszerzyć istniejący. Czasami jednak możesz założyć nowy obiekt ale dziedziczący po tamtym obiekcie, dzięki czemu unikniesz budowania obiektu od zera.

Kiedy nie tworzyć w ogóle nowego obiektu, tylko zmodyfikować istniejący?

Wyobraź sobie, że projektujesz aplikację WWW dla klientów i chcesz zrobić specjalne okno, w którym klient może przeglądać swoje faktury w postaci tabeli oraz wchodzić w szczegółowe dane tych faktur. Potrzebujesz do tego specjalnych okien. Nie możesz wykorzystać okien standardowych, gdyż zupełnie inne informacje o fakturach są istotne z punktu widzenia operatora, który wystawia fakturę, a klienta, który je otrzymuje. W standardowym oknie przeglądania faktur istnieją np pola KLIENT oraz AKCEPTACJA, gdyż okno takie gromadzi faktury dla różnych klientów i umożliwia pokazanie faktur niezaakceptowanych, które dopiero są wystawiane. Z punktu widzenia klienta takie informacje są nieistotne, gdyż klient powinien widzieć tylko faktury zaakceptowane, wystawione dla niego. Podobne różnice będą w oknie edycji. Dla operatora może być np. istotne na jakim magazynie wystawiono fakturę. Dla klienta natomiast symbolika magazynów w naszej firmie jest obca i nic nie mówi.

W takim przypadku znajdź obiekt, w którym zdefiniowano okna faktur (NAGFAK i POZFAK) i zdefiniuj w nim zupełnie nowe okna, obok istniejących. Nazwij okna tak aby kojarzyły się z celem zgodnie z którym zostały stworzone. Możesz więc założyć okna BROWSE4CUSTOMER i EDIT4CUSTOMER. Często okna te będą całkowicie nieedytowalne i będą miały inny zestaw przycisków z akcjami niż okna standardowe.

Nie dziedzicz obiektów NAGFAK i POZFAK i nie modyfikuj okien BROWSE i EDIT aby uzyskać pożądane rezultaty. Być może nawet uda Ci się osiągnąć zamierzony efekt tą metodą, ale pojawi się problem, że każde rozszerzenie standardowych okien obiektów NAGFAK i POZFAK od razu będzie widoczne w oknach dziedziczonych i za każdym razem będzie trzeba te okna poprawiać i ukrywać coraz więcej elementów. Jeśli się to zaniedba, to w aplikacji dla klienta mogą się pojawić informacje lub akcje, do których klient nie powinien mieć dostępu.

Kiedy utworzyć obiekt dziedziczący?

Wyobraź sobie, że potrzebujesz zrobić analizę, która w wyniku zwraca listę faktur. Analiza ma skomplikowane warunki i zwraca dodatkowe pola informacyjne i nie da się jej zrobić przez nałożenie filtracji na obiekt NAGFAK odpowiadający tabeli NAGFAK. Jednak wynik mógłby być pokazywany w podobnym oknie do standardowego okna listy faktur, gdyż akcje dostępne na standardowym oknie będą bardzo przydatne na wyniku analizy. Operator mógłby np wejść w okno edycji tej faktury albo wykonać na niej jakąś operację.

W takim przypadku załóż nowy obiekt, który dziedziczy po obiekcie NAGFAK. Zmień w tym obiekcie źródło danych z tabeli na zapytanie SQL i wpisz odpowiednie zapytanie. Dzięki temu, że obiekt dziedziczy po obiekcie NAGFAK od razu dostajesz pełną listę pól modelu danych, okna i akcje. Jeśli analiza zwraca dodatkowe pola, możesz je dodać do modelu danych. Jeśli te pola chcemy zobaczyć w oknie, dodaj je do podziedziczonych okien. Dzięki temu uzyskasz analizę, którą wyświetlisz w bardzo funkcjonalnym oknie, do którego operator jest przyzwyczajony. Jeśli standardowe okna ulegną rozwojowi, np w wyniku zmiany przepisów, te same zmiany automatycznie pojawią się w obiekcie dziedziczonym, co jest jak najbardziej słuszne.

W tym przypadku nie jesteś w stanie zdefiniować osobnych okien w obiekcie NAGFAK, gdyż bez zmiany obiektu nie zmienisz źródła danych. Możesz, co prawda zrobić nowy obiekt zupełnie niezależny od obiektu NAGFAK, ale wtedy czeka Cię dużo mozolnej pracy z przepisywaniem funkcjonalności.

Uwaga!

Jeśli robisz analizę zwracającą np dokumenty spedycyjne, poszukaj obiektu LISTYWYSD odpowiadającemu tabeli o tej samej nazwie. Jeśli nie znajdziesz takiego obiektu, to nie rób analizy od zera. Najpierw załóż obiekt dla tabeli LISTYWYSD, wygeneruj w nim pola modelu danych i załóż okno BROWSE a dopiero potem załóż obiekt dziedziczący po obiekcie LISTYWYSD na potrzeby swojej analizy. Oddasz tym samym przysługę komuś, kto potem będzie rozwijał obiekt bazowy. A ktoś, kto rozwinie obiekt bazowy odda przysługę Tobie, gdyż Twoja analiza dzięki dziedziczeniu automatycznie zyska na funkcjonalności.

Kiedy utworzyć obiekt dziedziczący z przykryciem?

Normalnie, podczas rozwijania aplikacji standardowych, nie masz potrzeby tworzyć obiektów dziedziczących z przykryciem. Jednak w środowisku klienta jest to jedyny sposób na wprowadzenie szybkiej poprawki do projektu standardowego (np COMMON) lub wykonania customizacji funkcjonalności standardowej. Pamiętaj, że w środowisku klienta, projekty standardowe są w postaci spakowanej i nie podlegają modyfikowaniu. Jeśli musisz więc coś w nich zmienić, w indywidualnym projekcie klienta (np. w projekcie LOBOS) podziedzicz po odpowiednim obiekcie projektu standardowego w trybie z przykryciem i dokonaj zmian w tym obiekcie. Dodaj pola X-owe do modelu danych, zmodyfikuj okna, itp.

Jeśli np utworzysz obiekt LOBOS.KLIENCI dziedziczący po COMMON.KLIENCI z przykryciem i dodasz w nim jakieś pole X-owe, które pokażesz także na oknie, to każde odwołanie w akcji neosowej do obiektu COMMON.KLIENCI zostanie od razu przekierowane do obiektu przykrywającego. Nie musisz więc modyfikować wszystkich akcji aby zamiast COMMON.KLIENCI używały LOBOS.KLIENCI, gdyż dzieje się to samoczynnie.

Uwaga!

Takie przykrycie obiektu KLIENCI zadziała tylko wtedy, gdy bieżącym projektem w pliku app jest projekt LOBOS a nie jakiś standardowy projekt. Projekt LOBOS ponadto musi posiadać projekt COMMON na liście referencji.

Kiedy utworzyć obiekt niezależny?

Wyobraź sobie, że potrzebujesz zrobić analizę, która zwraca różne dokumenty klienta w jednym gridzie (faktury, zamówienia, dokumenty magazynowe). Mógłbyś podziedziczyć po obiekcie bazowym, ale nie do końca wiadomo, który wybrać (NAGFAK?, NAGZAM?). Ponadto zestaw akcji będzie całkiem odmienny, bo wszystkie akcje muszą uwzględniać to na jakiego rodzaju rekordzie działają. Gdybyś wykorzystał dziedziczenie mocno musiałbyś modyfikować funkcje, okna itp. W takim wypadku najlepiej stworzyć od zera obiekt, który po niczym nie dziedziczy i oprogramować go tylko do celu tej analizy.