Αρχιτεκτονική και Μοτίβα στην Ανάπτυξη Κινητών: Τι Είναι, Τύποι και Πώς να Εφαρμοστούν

Κύρια Αρχιτεκτονικά Μοτίβα

Ένα αρχιτεκτονικό μοτίβο καθορίζει πώς κατανέμονται οι ευθύνες μεταξύ των κλάσεων της εφαρμογής. Η επιλογή μοτίβου επηρεάζει την ευκολία προσθήκης νέων οθονών και δοκιμής κώδικα.

MVC (Model-View-Controller)

MVC είναι ένα κλασικό μοτίβο όπου το Model διαχειρίζεται δεδομένα, το View την εμφάνιση και το Controller τη λογική. Στο iOS, το MVC είναι προεπιλογή (UIViewController); στο Android, το Activity. Το μειονέκτημα είναι ότι ο Controller συχνά γίνεται "μαζικός" (Massive View Controller). Σύμφωνα με έρευνα προγραμματιστών iOS (Reddit, 2025), το 62% αναφέρει το MVC ως την κύρια αιτία μη αναγνώσιμου κώδικα σε παλαιότερα έργα.

MVP (Model-View-Presenter)

MVP διαφέρει στο ότι ο Presenter διαχειρίζεται το View μέσω μιας διεπαφής, βελτιώνοντας τη δοκιμασιμότητα. Το MVP ήταν δημοφιλές στο Android πριν από το Jetpack, αλλά υστερεί σε ευκολία σε σχέση με το MVVM.

MVVM (Model-View-ViewModel)

MVVM είναι το προτεινόμενο μοτίβο από την Google για Android και την Apple για iOS. Το ViewModel αποθηκεύει κατάσταση και το View εγγράφεται σε αλλαγές μέσω Data Binding ή @Published. Το ViewModel δεν εξαρτάται από το View και είναι εύκολο να δοκιμαστεί. Στην IT Sectr, χρησιμοποιούμε το MVVM ως κύριο μοτίβο σε όλα τα έργα.

MVI και VIPER

MVI είναι ένα αντιδραστικό μοτίβο όπου κάθε ενέργεια ακολουθεί τον κύκλο Intent → Model → View. Το MVI εγγυάται προβλέψιμη κατάσταση. Το VIPER είναι ένα μοτίβο iOS με πέντε επίπεδα (View, Interactor, Presenter, Entity, Router), που παρέχει μέγιστη απομόνωση αλλά απαιτεί πολύ πρότυπο κώδικα.

Clean Architecture

Clean Architecture είναι η ιδέα του Robert Martin που χωρίζει μια εφαρμογή σε επίπεδα: τα εξωτερικά επίπεδα (UI, DB, δίκτυο) εξαρτώνται από τα εσωτερικά (επιχειρηματική λογική, οντότητες). Στην ανάπτυξη κινητών, το Clean Architecture περιλαμβάνει τρία επίπεδα: data (αποθετήρια), domain (Use Cases) και presentation (ViewModels, UI).

Repository Pattern είναι ένα βασικό συστατικό του Clean Architecture που αφαιρεί την πηγή δεδομένων. Το αποθετήριο αποφασίζει αν θα λάβει δεδομένα από το δίκτυο ή από την τοπική αποθήκευση (Room, Core Data) και επιστρέφει ενοποιημένη μορφή. Σύμφωνα με την Google (Architecture Guide, 2025), το Repository Pattern συνιστάται για οποιαδήποτε εφαρμογή με αιτήματα δικτύου. Το Clean Architecture δικαιολογείται σε έργα με 3–5 οθόνες ή περισσότερες — για απλές εφαρμογές, ξεκινήστε με MVVM.

Δημιουργικά Μοτίβα

Singleton

Singleton είναι ένα αρχιτεκτονικό μοτίβο που εγγυάται ένα μοναδικό στιγμιότυπο μιας κλάσης και παρέχει ένα καθολικό σημείο πρόσβασης σε αυτήν. Χρησιμοποιείται για βάσεις δεδομένων, διαχειριστές ρυθμίσεων και προσωρινή μνήμη. Στην Kotlin, δημιουργείται μέσω object. Το μειονέκτημα είναι ότι περιπλέκει τη δοκιμή λόγω καθολικής κατάστασης.

Factory και Builder

Factory αναθέτει τη δημιουργία αντικειμένων σε μια εργοστασιακή μέθοδο — αντί για new, καλείτε το εργοστάσιο. Builder είναι ένα μοτίβο σταδιακής κατασκευής για σύνθετα αντικείμενα με πολλές παραμέτρους (AlertDialog.Builder, NotificationCompat.Builder). Το Builder βελτιώνει την αναγνωσιμότητα και επιτρέπει στα αντικείμενα να παραμένουν αμετάβλητα μετά τη συναρμολόγηση.

Δομικά και Συμπεριφορικά Μοτίβα

Adapter, Facade, Delegate, Protocol

Adapter είναι ένα αρχιτεκτονικό μοτίβο που μετατρέπει τη διεπαφή μιας κλάσης σε μια διεπαφή που αναμένει ο πελάτης. Στο Android, αυτό είναι το RecyclerView.Adapter. Facade παρέχει μια απλοποιημένη διεπαφή σε ένα σύνθετο σύστημα — για παράδειγμα, μια πρόσοψη για ένα API που κρύβει λεπτομέρειες αυθεντικοποίησης. Delegate είναι ένα μοτίβο iOS όπου ένα αντικείμενο αναθέτει μια εργασία (UITableViewDelegate). Protocol είναι το αντίστοιχο μιας διεπαφής στη Swift.

Observer και Strategy

Observer είναι ένα μοτίβο εγγραφής για αλλαγές: το υποκείμενο ειδοποιεί τους συνδρομητές για ενημερώσεις. Στην ανάπτυξη κινητών, ο Observer είναι η βάση των LiveData, StateFlow, RxJava και Combine. Strategy είναι ένα μοτίβο εναλλάξιμων αλγορίθμων: συνδέετε μια διαφορετική στρατηγική (ταξινόμηση, επικύρωση) χωρίς πολλαπλές εντολές if-else.

Έγχυση Εξαρτήσεων και Διαχείριση Κατάστασης

Dependency Injection είναι ένα αρχιτεκτονικό μοτίβο όπου ένα αντικείμενο λαμβάνει τις εξαρτήσεις του από έξω αντί να τις δημιουργεί το ίδιο. Αντί για new Database(), περνάτε τη βάση δεδομένων μέσω του κατασκευαστή. Το DI απλοποιεί τη δοκιμή — μπορείτε να χρησιμοποιήσετε Mock αντί για πραγματική βάση δεδομένων — και διευκολύνει την εναλλαγή υλοποιήσεων. Δημοφιλή πλαίσια DI: Dagger και Hilt (Android), Swinject (iOS), Koin (Kotlin). Το Hilt — ένα περιτύλιγμα γύρω από το Dagger που προτείνεται από την Google — μειώνει τη ρύθμιση DI κατά 3 φορές.

Service Locator είναι μια εναλλακτική λύση στο DI με κεντρικό μητρώο εξαρτήσεων. Πιο απλό στην υλοποίηση, αλλά κρύβει τις εξαρτήσεις της κλάσης, δυσκολεύοντας τη δοκιμή. Τα σύγχρονα έργα προτιμούν DI μέσω Hilt ή Koin.

Διαχείριση Κατάστασης στο Flutter

Στο Flutter, η διαχείριση κατάστασης είναι ένα ξεχωριστό οικοσύστημα. Redux — ένα μοναδικό Store με αλλαγές μέσω Actions → Reducer → State. Το BLoC της Google διαχωρίζει γεγονότα και καταστάσεις μέσω Stream. Provider — ένα απλό δοχείο DI που προτείνεται από την Google για Flutter έως το 2023. Riverpod — ένα βελτιωμένο Provider που λύνει προβλήματα μεταγλώττισης και δοκιμής. GetX — ένα μικρο-πλαίσιο με δρομολόγηση, DI και διαχείριση κατάστασης. Για αρχάριους προγραμματιστές Flutter, συνιστούμε Provider ή Riverpod ως τις καλύτερα τεκμηριωμένες λύσεις.

Αρχές SOLID και DRY

Εκτός από συγκεκριμένα μοτίβα, υπάρχουν γενικές αρχές σχεδίασης αρχιτεκτονικής που ισχύουν σε οποιαδήποτε γλώσσα και πλαίσιο.

SOLID — πέντε αρχές αντικειμενοστραφούς σχεδίασης: Single Responsibility (μία κλάση — μία εργασία), Open-Closed (ανοιχτό για επέκταση, κλειστό για τροποποίηση), Liskov Substitution (οι υποκλάσεις αντικαθιστούν τη γονική κλάση), Interface Segregation (μικρές διεπαφές), Dependency Inversion (εξάρτηση από αφαιρέσεις). Στην ανάπτυξη κινητών, το SRP είναι η πιο χρήσιμη αρχή: κάθε κλάση κάνει μόνο ένα πράγμα. Σύμφωνα με την εμπειρία της IT Sectr, η παραβίαση του SRP είναι η αιτία του 70% των προβλημάτων δοκιμής σε εμπορικά έργα.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

Το παράδειγμα Kotlin δείχνει πώς μετατρέπουμε μία κλάση UserManager με τέσσερις ευθύνες σε τέσσερις κλάσεις με μία ευθύνη η καθεμία. Τέτοιος κώδικας είναι ευκολότερος στη δοκιμή, την τροποποίηση και την επαναχρησιμοποίηση.

DRY (Don't Repeat Yourself) — αποφύγετε την επανάληψη κώδικα. Εξάγετε επαναλαμβανόμενη λογική σε κοινές μεθόδους ή κλάσεις. KISS (Keep It Simple, Stupid) — η απλότητα είναι πιο σημαντική από την κομψότητα. YAGNI (You Aren't Gonna Need It) — μην γράφετε κώδικα για κάτι που μπορεί να μην χρειαστεί. Αυτές οι αρχές βοηθούν στη σύνταξη καθαρού, συντηρήσιμου κώδικα χωρίς πλεονασμό.

Μοτίβα Πλατφόρμας Android

ViewModel (Android) είναι ένα στοιχείο αρχιτεκτονικής Jetpack για αποθήκευση κατάστασης UI, ανθεκτικό στην περιστροφή οθόνης. Το ViewModel δεν περιέχει αναφορές στο Activity και καθαρίζεται αυτόματα. LiveData — ένα παρατηρήσιμο δοχείο δεδομένων με επίγνωση κύκλου ζωής. StateFlow — ένα σύγχρονο υποκατάστατο για το LiveData βασισμένο στο Kotlin Flow. SharedFlow — ένα Hot Flow για εφάπαξ γεγονότα (πλοήγηση, toast).

Data Binding και Two-Way Binding — μηχανισμοί σύνδεσης UI και δεδομένων στο Android. Το Data Binding δηλώνει τη σύνδεση σε XML; το Two-Way Binding ενημερώνει αυτόματα το πεδίο στο ViewModel. Unidirectional Data Flow — μια αρχή όπου τα δεδομένα ρέουν προς μία κατεύθυνση: State → UI → Event → State. Στην IT Sectr, χρησιμοποιούμε το Unidirectional Data Flow σε όλα τα νέα έργα — μειώνει τον αριθμό σφαλμάτων που προκαλούνται από απροσδόκητες αλλαγές κατάστασης.