programmazione orientata agli oggetti Android

Sto scherzando con alcune programmazioni di base in Android utilizzando Eclipse. Attualmente sto esaminando un libro e sto giocando con alcuni esempi di codice scritti nel libro.programmazione orientata agli oggetti Android

Ho notato che in questo particolare libro, tutti gli esempi finora hanno un passo in Main-Activity. Non credo che questa sia una buona pratica di programmazione orientata agli oggetti come provengo da un tradizionale background Java.

È questa la pratica comune per le piattaforme mobili? Le classi non dovrebbero essere tutte contenute nei propri file?

fonte

2011-09-10 JCC

Puoi pubblicare alcuni esempi per illustrare meglio la tua domanda? – elevine

OOP non è sempre la migliore pratica; e la suddivisione in migliaia di file non produce sempre un buon programma OOP. –

Le classi non dovrebbero essere tutte contenute nei propri file?

Non necessariamente come Android Activity è una classe 'caso speciale'. Se non si è già fatto, vi consiglio di leggere Application Fundamentals ed in particolare la sezione 'Attività' sotto Application components ...

Un'attività rappresenta un unico schermo con un'interfaccia utente. Ad esempio, un'applicazione di posta elettronica potrebbe avere un'attività che mostra un elenco di nuove e-mail, un'altra attività per comporre un'email e un'altra attività per leggere le e-mail. Sebbene le attività lavorino insieme per formare un'esperienza utente coesa nell'applicazione di posta elettronica, ognuna è indipendente dalle altre. In quanto tale, un'applicazione diversa può avviare una qualsiasi di queste attività (se l'applicazione di posta elettronica lo consente). Ad esempio, un'applicazione fotocamera può avviare l'attività nell'applicazione di posta elettronica che compone la nuova posta, in modo che l'utente possa condividere un'immagine.

Nota la sezione di testo che ho evidenziato in grassetto. Il punto è che uno Activity di per sé non è l'app completa e, se consentito, qualsiasi app di terze parti può potenzialmente invocare un Activity in una delle tue app. Pertanto, è comune rendere un Activity il più autonomo possibile. Un esempio particolare è l'uso di qualcosa come un AsyncTask che fornisce metodi per eseguire un thread in background e manipolare l'interfaccia utente - l'nidificazione di una classe privata che estende AsyncTask è abbastanza comune e semplifica il codice. Le classi di nidificazione che si estendono BroadcastReceiver sono comuni anche per lo stesso motivo.

Detto questo, non c'è niente di sbagliato nell'usare file di classi Java separati per le classi di helper POJO, ad esempio, si tratta solo della complessità della tua app, ma può significare prendere in considerazione in modo particolare il funzionamento di certe classi di Android. AsyncTask class essendo uno in particolare se definito in un file di classe separato, provalo e vedrai cosa intendo. :-)

fonte

2011-09-10 22:17:23 Squonk

Il fatto che Activity sia quasi un'app da sola dovrebbe implicare l'opposto di quanto non sia interamente contenuto in una grande classe. Qualsiasi applicazione è più o meno "autonoma", questo non significa che tutto il codice dovrebbe essere in una singola classe. Come hai detto, * "le attività lavorano insieme per formare un'esperienza utente coesiva in (un)" applicazione "*, è in realtà previsto che parti dell'interfaccia utente e funzionalità siano condivise tra le attività. – Groo

@Groo: "Il fatto che Activity sia quasi un'app da solo ..." - no questo è esattamente ciò che molte persone nuove di Android credono, cioè pensano che "Activity" sia sinonimo di "app". In realtà, un'app può avere dozzine di componenti (Attività, Servizi, BroadcastReceivers, Content Provider). Non sto suggerendo che tutte le attività debbano contenere tutto, il mio punto è che le attività sono spesso semplici interfacce utente di una sola pagina che eseguono un'azione molto semplice e, come tali, possono spesso contenere tutto ciò di cui hanno bisogno. Se è necessario il codice condiviso, è possibile utilizzare le classi di supporto. – Squonk

+1 Ok, immagino di aver letto il post troppo superficialmente, ora capisco: hai fatto riferimento a un'attività "autonoma" come parte di un'applicazione completa. È vero che non è necessario dividere ogni parte della tua app in più file (o classi), ma quando si fa la programmazione TDD, è spesso bello poter testare separatamente ogni componente più piccolo, quindi tendo ad entrare quella direzione per la maggior parte del tempo. Ma poi di nuovo, TDD non è neanche un proiettile d'argento. E io uso classi private per scomporre parti complesse della funzionalità di una classe, e quindi refactoring quando (e se) necessario. – Groo

OO significa mettere funzionalità nelle classi. Il modo in cui scrivi queste classi definisce se è buono OO o meno (sebbene questo sia discutibile). Se tutte queste classi sono in un singolo o pochi file o ogni classe ha il proprio file, è una questione di gusti e non è direttamente un problema di OO.

Poiché si tratta di un libro con (penso) piccoli campioni, può essere altrettanto semplice da leggere nel modo in cui lo è, rispetto a quando tutte le classi si trovano in file separati.

fonte

2011-09-10 21:44:22 GolezTrol

Se si utilizza OOP corretto è possibile creare applicazioni basate su modello molto più rapidamente & in modo efficiente.

Si dovrebbe cercare di farlo, ad esempio se si dispone di un'app di database generica e più database possono essere utilizzati con modifiche minori.

fonte

2013-08-03 05:41:04

programmazione orientata agli oggetti Android

risposta

Problemi correlati