Programowanie obiektowe z Androidem

Oszukuję z podstawowym programowaniem w Androidzie za pomocą Eclipse. Obecnie przeglądam książkę i gram z przykładowym kodem, który jest napisany w książce.Programowanie obiektowe z Androidem

Zauważyłem, że w tej konkretnej książce wszystkie przykłady do tej pory nadążają za główną aktywnością. Nie wierzę, że jest to bardzo dobra praktyka programowania zorientowana obiektowo, ponieważ pochodzę z tradycyjnego środowiska Java.

Czy to powszechna praktyka w przypadku platform mobilnych? Czy wszystkie klasy nie powinny być zawarte w ich własnych plikach?

Źródło

2011-09-10 JCC

Czy możesz zamieścić kilka przykładów, aby lepiej zobrazować swoje pytanie? – elevine

OOP nie zawsze jest najlepszą praktyką; a podzielenie na tysiące plików nie zawsze daje dobry program OOP. –

Czy nie wszystkie klasy powinny zawierać się w ich plikach?

Niekoniecznie jako Android Activity to klasa "specjalnych przypadków". Jeśli nie zostało to jeszcze zrobione, polecam lekturę Application Fundamentals aw szczególności rozdział „działalność” pod Application components ...

Działalność reprezentuje pojedynczy ekran z interfejsem użytkownika. Na przykład aplikacja e-mail może mieć jedno działanie, które pokazuje listę nowych wiadomości e-mail, inną czynność związaną z tworzeniem wiadomości e-mail i inną czynnością dotyczącą czytania wiadomości e-mail. Mimo że działania współdziałają w celu zapewnienia spójnego doświadczenia użytkownika w aplikacji poczty e-mail, każda z nich jest niezależna od innych. W związku z tym inna aplikacja może uruchomić dowolną z tych czynności (jeśli aplikacja e-mailowa na to zezwala). Na przykład aplikacja aparatu fotograficznego może uruchomić działanie w aplikacji e-mail, która tworzy nową pocztę, aby użytkownik mógł udostępnić zdjęcie.

Zwróć uwagę na wyróżniony fragment tekstu wyróżniony pogrubieniem. Chodzi o to, że sama Activity nie jest kompletną aplikacją i jeśli jest to dozwolone, każda aplikacja innej firmy może potencjalnie wywołać Activity w jednej z twoich aplikacji. W związku z tym powszechnym jest, aby Activity był jak najbardziej niezależny. Jednym z konkretnych przykładów jest użycie czegoś takiego jak AsyncTask, który zapewnia metody wykonywania wątku w tle, a także manipulowania interfejsem użytkownika - zagnieżdżanie klasy prywatnej, która rozszerza się o AsyncTask, jest dość powszechne i upraszcza kod. Zagnieżdżanie klas o rozszerzeniu BroadcastReceiver jest również powszechne z tego samego powodu.

To powiedziawszy, nie ma nic złego w korzystaniu z oddzielnych plików klas Java dla klas pomocnika POJO, na przykład sprowadza się to tylko do złożoności aplikacji, ale może to oznaczać, że bierze się pod uwagę działanie niektórych klas Androida - AsyncTask klasa będąca jednym z nich, jeśli jest zdefiniowany w osobnym pliku klasy, spróbuj, a zobaczysz, co mam na myśli. :-)

Źródło

2011-09-10 22:17:23 Squonk

Sam fakt, że Activity jest prawie samą aplikacją, powinien sugerować, że jest całkowicie odwrotny, niż jest całkowicie zawarty w dużej klasie. Każda aplikacja jest mniej lub bardziej "samowystarczalna", co nie oznacza, że cały kod powinien należeć do jednej klasy. Jak już cytujesz, * "działania współdziałają, tworząc spójny interfejs użytkownika w aplikacji (an)" *, faktycznie oczekuje się, że części interfejsu i funkcjonalności będą współdzielone pomiędzy Aktywnościami. – Groo

@Groo: "Fakt, że Activity jest prawie samą aplikacją ..." - nie jest to dokładnie to, co wielu nowych użytkowników Androida uważa, tzn. Uważają, że "Activity" jest synonimem "app". W rzeczywistości aplikacja może zawierać dziesiątki komponentów (Działania, Usługi, Nadawcy, Dostawcy treści). Nie sugeruję, że wszystkie Działania powinny zawierać wszystko - moim celem jest to, że Działania są często bardzo prostymi pojedynczymi "stronicowymi" interfejsami użytkownika, które wykonują bardzo proste działania i jako takie często mogą zawierać wszystko, czego potrzebują. Jeśli istnieje potrzeba wspólnego kodu, można użyć klas pomocniczych. – Squonk

+1 OK, myślę, że przeczytałem post zbyt powierzchownie, teraz rozumiem: odniosłeś się do "samodzielnego" działania jako części kompletnej aplikacji. To prawda, że nie musisz dzielić każdej części swojej aplikacji na kilka plików (lub klas), ale podczas programowania TDD często dobrze jest móc przetestować każdy najmniejszy komponent osobno, więc mam tendencję do wchodzenia w tym kierunku przez większość czasu. Ale także TDD nie jest też srebrną kulą. I używam klas prywatnych do rozłożenia złożonych części funkcjonalności klasy, a następnie ich refaktoryzacji, kiedy (i jeśli) potrzebne. – Groo

OO polega na umieszczaniu funkcjonalności w klasach. Sposób, w jaki piszesz te klasy, określa, czy jest dobry, czy nie (chociaż jest to dyskusyjne). To, czy wszystkie te klasy znajdują się w jednym lub kilku plikach, czy też każda klasa ma własny plik, jest kwestią gustu i nie jest bezpośrednio problemem OO.

Ponieważ jest to książka z (jak sądzę) małymi próbkami, może być równie łatwa do odczytania, jak jest, niż wtedy, gdy wszystkie klasy są w oddzielnych plikach.

Źródło

2011-09-10 21:44:22 GolezTrol

Jeśli użyjesz odpowiedniego OOP, możesz efektywniej tworzyć aplikacje oparte na szablonach.

Powinieneś dążyć do tego, na przykład, jeśli masz ogólną aplikację bazodanową i możesz korzystać z wielu baz danych z niewielkimi zmianami.

Źródło

2013-08-03 05:41:04

Programowanie obiektowe z Androidem

Odpowiedz

Powiązane problemy