[krasnoludkolo]

Hejka
Napisałem sobie pierwszą apke, nic skomplikowanego, prosty TODOList. Zobaczyłby może ktoś z was co robię źle, co można zrobić lepiej? ;)
Kod

[krasnoludkolo]

@MacDada: czyli zrobić tak:
Klasa Task zostaje jak jest
Zrobić klase TaskCollection która ma samą listę, metody sortowania itp
Klase repo zmienic tak zeby miala w sobie TaskCollection plus metody na zapisywanie itp?

[MacDada]

@krasnoludkolo: Tak, repo zapisuje i udostępnia obiekt lub ich kolekcję.

Z czego „zapisuje” to tak jakby „w domyśle” – bo wyobraź sobie, że pamięć nie jest problemem, aplikacje żyją wiecznie i cała aplikacja siedzi w RAMie. Tak właśnie należy traktować repo – jako miejsce, które te dane przechowuje. Ale, że żyjemy w świecie nieidealnym, to repo zazwyczaj udaje tę perfekcję przez zapisywanie i odczytywanie skądś (bazki, pliku, etc).

[krasnoludkolo]

@MacDada: jeszcze tylko jedno pytanie. TaskCollection moze dziedziczyć po ArrayList czy lepiej jak liste ma jako pole? ;)

[MacDada]

@krasnoludkolo: Obojętne, ale zauważ, że ArrayList już jest kolekcją, implementuje Collection: https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html

[krasnoludkolo]

@MacDada: czy repo ma mieć jakąś metode sortBy która wywoła metode z TaskCollection sortującą? Jeśli nie to jak inaczej?

[MacDada]

@krasnoludkolo: Nie, repo może mieć co najwyżej metodę zwracającą posortowaną kolekcję, np (pseudokod):

Collection tasksSortedByPriority = taskRepo.getAllSortedBy('priority');
Collection tasksSortedByPriority = taskRepo.getAllSortedByPriority();

Korzystający z repo nie może polegać na tym, że repo „pamięta” kolejność elementów w kolekcji:

// kolekcja tasków jest zwracana w domyślnej kolejności
Collection tasks = taskRepo.getAll();

// tutaj sortowanie tasks
sortTasks(tasks);

// to nie powinno nam dać posortowanych danych, ale kolekcję w domyślnej kolejności
Collection tasks2 = taskRepo.getAll(); 

Ale

[krasnoludkolo]

@MacDada: a co w wypadku kiedy chce posortować ale nie chce jej zwracać? Zrobić coś takiego taskRepository.getTaskCollection.sortBy(costam) czy to wygląda brzydko? ;)

[MacDada]

@krasnoludkolo: kolekcja może mieć opcję sortowania:

tasks = repo.getAll();
tasks.sortByPriority(); // posortowane

[krasnoludkolo]

@MacDada: zerkniesz czy w miare poprawnie to jest? ;)
Klasy w których grzebałem

Użycie sortowania (btw mozna tu zostawić tego switch'a?)

[MacDada]

@krasnoludkolo:

1. Robisz taskRepository.getTaskCollection().sortBy(SortType.NAME); – naruszając Law of Demeter. Osobiście nie traktuję tego jako „błąd” (też mi się zdarza), ale raczej staram się w takich przypadkach zastanowić czy na pewno to musi być w ten sposób.

2. Po co Ci settery 1 2 ? Jeśli te obiekty są wymagane do działania – wymagaj ich w konstruktorze. Settery możesz zostawić jeśli faktycznie będziesz chciał móc podmienić te obiekty później.

3. Taki

[MacDada]

@krasnoludkolo: Pomyśl o tym jeszcze tak:

Jeśli robisz taskRepository.getTaskCollection().sortBy(SortType.NAME); to repo nie powinno się nazywać TaskRepository tylko TaskCollectionRepository – bo służy wtedy do przechowywania obiektów TaskCollection, a nie obiektów Task ;-)

[MacDada]

W każdym razie kolekcja to oddzielny byt od repo – można element usunąć z kolekcji, ale nie powinien on automatycznie wylecieć też z repo.

W sumie automat byłby akceptowalny (jeśli chodzi o dodawanie/usuwanie), ale tylko w ten sposób, że kolekcja przyjmuje w konstruktorze repo – i jak usuwasz element na kolekcji – to kolekcja usuwa wtedy element na repo (kaskadowo).

Ale nie odwrotnie (że usuwanie z repo wywala automatycznie z kolekcji) i

[MacDada]

@krasnoludkolo: Używałeś http://hibernate.org/orm/ ? Podpatrz sobie jak tam wykorzystuje się repozytoria.

[krasnoludkolo]

@MacDada: dzięki wielkie ;) zajmę się tym wszystkim po powrocie ;)
na szybko co do pkt 2 i 3 to nie tworze tych obiektów przez new tylko pobieram z widoku (androidowe api) a ten drugi konstruktor wlasnie do tego jest (android se z niego korzysta)