Wątek przeniesiony 2019-01-17 11:46 z Algorytmy i struktury danych przez somekind.

Problem ze strukturą projektu. Podejście obiektowe.

0

Posiadam klasę BazaPrzestępstw ma ona w sobie liste obiektów typu Osoba. Każda Osoba ma w sobie listę obiektów typu Przestępstwo. Przestępstwo posiada datę nadania. Problem jak w najlepszy sposób i gdzie stworzyć metodę usuwającą przestępstwo po 15 latach?

1

Powiedział bym Ci ale skoro sprawa dotyczy prawa karnego to takich rzeczy nie zamieszcza się publicznie.

A tak serio to skoro masz obiekt reprezentujący jaka zbiór danych (a więc repozytorium/bazę) to właśnie tam powinieneś mieć metodę za pomocą której możesz usunąć obiekty.

EDIT: nie doczytałem. Skoro chodzi o usunięcie przestępstw to taka logikę powinienna posiadać Osoba. Z tym że powodem dla którego nie jest to dla Ciebie jasne jest to że próbujesz użyć oddzielnej klasy do reprezentowania bazy, mimo że (zakładam) rzeczywistej bazy nie masz. Normalnie chodziło by o usunięcie przestępstwa z osoby, a następnie zapisanie tej osoby raz jeszcze, tym razem ze zaktualizowaną liczbą przestępstw.

1

To nie ma totalnie nic związanego z prawem karym, taki sobie projekt wymyśliłem. Równie dobrze można zmienić BazaOsóbKtórychLizakNadajeSięDoZjedzenia a listę Przestępst zamienić na listę Lizaków gdzie każdy Lizak ma datę produkcji. Po 2 tygodniach lizak nie nadawać się do zjedzenia więc trzeba go usunąć i tyle :)

0

Myślę, że taka metoda powinna się znaleźć w klasie kontenera przechowującego. Usuwałaby ona wszystkie przedawnione sprawy.

2

Ja bym powiedział że nigdzie. Usuwanie danych to zwykle niepożądana rzecz. Ja bym jednak zaimplmentował pobieranie danych tak zeby filtrowało te przedawnione wpisy.

0

Moim zdaniem powinien znajdować się jakiś job/cron, który co x czasu sprawdzałby przestępstwa i flagował je jako przedawnione. Osoba nie powinna sama zarządzać swoimi przestępstwami, tak naprawdę to czasem przedawnienia zarządza hmm czas ;) Ewentualnie jakiś sąd czy coś w ten deseń. W każdym razie jest to zewnętrzna instytucja/proces, co popiera mój pomysł.
Tak jak @Shalom napisał, nie powienieś tego usuwać, a raczej dodaj flagę w klasie Przestępstwo boolean expired. Ewentualnie dodaj drugą listę w stylu przeterminowanePrzestępstwa i w przypadku przedawnienia przenoś z jednej do drugiej.

2

Crony i inne tego typu rozwiązania, w tym przypadku to zwykle średni pomysł. Joby mogą się nie odpalić. Ktoś może pechowo ustawić złą datę na serwerze. Potem zostajemy z expired = true, ale nie wiadomo dlaczego. Raczej warto w **Przestępstwach ** wpisać datę wygaśnięcia i filtrować po tym (względem aktualnej daty). Aczkolwiek mogą tu wchodzić jakieś regulacje prawne. Nie znam się na tym.

0
Shalom napisał(a):

Ja bym powiedział że nigdzie. Usuwanie danych to zwykle niepożądana rzecz. Ja bym jednak zaimplmentował pobieranie danych tak zeby filtrowało te przedawnione wpisy.

Od bidy można by przenosić do osobnej tabeli/kolekcji/storage'u

1

Nie zgadzam się z tymi, którzy twierdzą, że w ogóle nie należy kasować wpisów. W polskich przepisach istnieje pojęcie "zatarcie skazania". I program powinien dać możliwość skasowania - nie polemizować z obowiązującymi z przepisami, tylko umożliwić działanie z nich wynikające.

A odnośnie tego, do którego z zaproponowanych obiektów przypisać funkcjonalność kasowania. Wyobraźmy sobie postać analogową problemu, że mamy papierowe archiwum z aktami. Nie pracuję w takowym, ale wyobrażam sobie jak może to funkcjonować:

  1. Usuwanie wpisów następuje w momencie, gdy ktoś sięgnął do danego zbioru danych w jakimś innym celu, przejrzał teczkę danej osoby i zauważył, że coś jest nieaktualne. Wtedy na siłę można by to przypisać obiektowi "TeczkaOsoby", chociaż i tak słabo oddawałoby to rzeczywistość, bo w rzeczywistości to pracownik archiwum czyści teczkę, a nie teczka sama siebie.
  2. Okresowo robimy coś w rodzaju remanentu i kasujemy wszystkie przedawnione przestępstwa - wtedy należałoby to zadanie przypisać całemu archiwum (czy tutaj bazie danych), a nie teczce osoby ani w żadnym razie przestępstwu.

Oczywiście, co sugeruje choćby już sam mój nick, odradzam w tym przypadku podejście "obiektowe". Chyba że jest to jakaś forma projektu, gdzie wybór metodyki ma podłoże ideologiczne a nie praktyczne (np. projekt zaliczeniowy u prowadzącego będącego wiernym wyznawcą OOP). Jak zresztą sam widzisz, nikomu w tym wątku nie udało się zaproponować sensownego i jednocześnie zgodnego z OOP podziału, tylko odpowiedzi zeszły na temat poboczny, jakim jest czy kasować wpisy czy ich nie kasować.

2

Nie zgadzam się z tymi, którzy twierdzą, że w ogóle nie należy kasować wpisów. W polskich przepisach istnieje pojęcie "zatarcie skazania". I program powinien dać możliwość skasowania - nie polemizować z obowiązującymi z przepisami, tylko umożliwić działanie z nich wynikające.

Nadinterpretujesz przepisy. Takie zatarcia oznacza że z prawnego punktu widzenia (!) skazane nie miało miejsca i jesteś traktowany jako osoba która nigdy nie miała wyroku. Ale to NIE znaczy że należy nagle zniszczyć wszystkie rekordy! Przecież sądy nie palą nagle akt sprawy i nie modyfikują dzienników!
Analogicznie tutaj: sugerujemy żeby dane w taki czy inny sposób oznaczyć jako "usunięte" czy "nieaktywne", ale fizycznie nie usuwać ich z systemu.

To jest generalnie powszechnie przyjęta praktyka i zaręczam że większość systemów nigdy twoich danych nie usuwa, nawet jeśli "skasujesz konto". Wyjątek w tej chwili stanowi RODO, bo faktycznie pewne informacje, na wyraźne żądanie, należy teraz kasować. Niemniej nadal nie kasuje się kont użytkowników, tylko podmienia dane na placeholdery.

1 użytkowników online, w tym zalogowanych: 0, gości: 1