Zaczęłam dodawać kolejną tabelkę do mojej aplikacji i CoNaObiadDbHelper zaczął się niebezpiecznie rozrastać o kolejne stałe typu MEAL_TABLE_NAME, MEAL_COLUMN_NAME_NAME leżące bardzo blisko od DINNER_TABLE_NAME. Jakoś nie dawało mi to spokoju i postanowiłam wydzielić je do osobnej klasy.
Żeby wyglądało na to, że wiem co robię dodałam nowy package o nazwie model, bo jakoś tak mi wygodnie w strukturze MVC znanej z aplikacji webowych, albo MV?, którą możemy tu zastosować 😉
I jak tam zaczęłam to przenosić to dotarło do mnie, że ten obiekt MEAL, to jednak nie jest tym o czym myślałam pierwotnie i postanowiłam go przechrzcić na DINNER. Takie zmiany zdarzają się czasem.
Na początek stworzyłam sobie klasę DinnerContract.java i zaczęłam przenosić do niej stałe typu TABLE_NAME, COLUMN_NAME_NAME, SQL_CREATE_ENTRIES. Później utworzyłam klasę MealContract.java, zaczęłam do niej przenosić stałe… zatrzymałam się i utworzyłam sobie jeszcze jedną klasę, tym razem abstrakcyjną – na razie nazwaną BaseTable.java, choć waham się nad BaseContract.java -> wyjdzie w praniu.
https://gist.github.com/jezinka/08834a1ce3fa11b7ff518eb16a2ee22c
Klasa MealContract.java z metodami dla siebie
https://gist.github.com/jezinka/0f08f97de42c5cbd94220435ece8a31d
i klasa DinnerContract.java czekająca na swoje użycie
https://gist.github.com/jezinka/edc50332bfaa02008f8fa2fa7c992be5
i jakoś tak od razu mi lżej jak patrzę na odchudzony CoNaObiadDbHelper.java
https://gist.github.com/jezinka/67ead062e9ca1ab84e7814ca360d6d07
Tylko jeszcze to pomieszanie konwencji nazewniczej, ale muszę nad tym jeszcze pomyśleć i dorobić gettery i settery jeśli zostawię je jako stałe – a tak by było chyba najbardziej poprawnie.