Separation of Concerns στην ανάπτυξη κινητών — τι είναι, αρχές και εφαρμογή

Τι είναι το Separation of Concerns

Separation of Concerns είναι η αρχή αποσύνθεσης ενός συστήματος λογισμικού σε ανεξάρτητα μέρη, καθένα από τα οποία επιλύει μία εργασία. Ο όρος concern (τομέας ευθύνης) υποδηλώνει οποιοδήποτε διαχωρίσιμο τμήμα λειτουργικότητας: εμφάνιση οθόνης, επεξεργασία κλικ, επικύρωση δεδομένων ή δικτυακή επικοινωνία. Η αρχή ορίζει την ομαδοποίηση κώδικα έτσι ώστε οι αλλαγές σε έναν τομέα να μην απαιτούν αλλαγές σε άλλους.

Στην ανάπτυξη κινητών, το SoC εκδηλώνεται σε πολλά επίπεδα: από τη διαίρεση της εφαρμογής σε οθόνες έως την οργάνωση κώδικα μέσα σε μία κλάση. Μια Activity ή ViewController που ταυτόχρονα φορτώνει δεδομένα από το δίκτυο, αναλύει JSON και σχεδιάζει UI παραβιάζει το Separation of Concerns — τέτοιος κώδικας είναι δύσκολο να συντηρηθεί, να δοκιμαστεί και να επεκταθεί. Εναλλακτική — μεταφορά κάθε τύπου ευθύνης σε ξεχωριστό στοιχείο.

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

Ιστορία και προέλευση της αρχής

Edsger Dijkstra διατύπωσε για πρώτη φορά την ιδέα του Separation of Concerns σε άρθρο του 1974 «On the Role of Scientific Thought». Υποστήριξε ότι η πολυπλοκότητα των συστημάτων λογισμικού μπορεί να ελεγχθεί διαιρώντας τα σε μέρη που αναλύονται απομονωμένα. Αυτή η προσέγγιση έρχονταν σε αντίθεση με τα μονολιθικά προγράμματα εκείνης της εποχής, όπου ο κώδικας αναμείγνυε υπολογισμούς, είσοδο-έξοδο και διεπαφή χρήστη.

Τη δεκαετία του 1980, η ιδέα αναπτύχθηκε από υποστηρικτές του δομημένου προγραμματισμού και στη συνέχεια της αντικειμενοστραφούς προσέγγισης. Γλώσσες όπως Smalltalk και C++ παρείχαν μηχανισμούς ενθυλάκωσης και αρθρωτότητας που έκαναν το SoC πρακτικό εργαλείο. Τα σύγχρονα αρχιτεκτονικά πρότυπα — MVC, MVP, MVVM και Clean Architecture — είναι άμεση ενσάρκωση της αρχής Separation of Concerns.

Στον κόσμο της ανάπτυξης κινητών, η Apple προώθησε το MVC ως πρότυπο για iOS, όπου το Model-View-Controller διαχωρίζει δεδομένα, εμφάνιση και λογική ελέγχου. Η Google για Android πρόσφερε αρχιτεκτονικές συστάσεις βασισμένες σε ViewModel και Repository — κάθε στοιχείο επιλύει τη δική του συγκεκριμένη εργασία. Χωρίς SoC, οι κινητές εφαρμογές μετατρέπονται σε Massive View Controller — κλάσεις με χιλιάδες γραμμές, όπου κάθε αλλαγή κινδυνεύει να σπάσει ολόκληρη τη λειτουργικότητα.

Επίπεδα διαχωρισμού στην κινητή αρχιτεκτονική

Τέσσερα κύρια επίπεδα σχηματίζουν την τυπική αρχιτεκτονική μιας κινητής εφαρμογής που υλοποιεί το Separation of Concerns. Κάθε επίπεδο είναι υπεύθυνο μόνο για τον τομέα του και αλληλεπιδρά με τα γειτονικά επίπεδα μέσω διεπαφών.

Επίπεδο UI: View και ViewModel

Το View είναι αποκλειστικά υπεύθυνο για την εμφάνιση δεδομένων και την επεξεργασία συμβάντων χρήστη. Στο iOS είναι UIViewController και UIView, στο Android — Fragment ή Activity. Το ViewModel περιέχει την κατάσταση οθόνης και τη λογική μετατροπής δεδομένων σε μορφή έτοιμη για εμφάνιση. Ο διαχωρισμός εγγυάται ότι η αντικατάσταση του UIKit με SwiftUI ή η επανεγγραφή οθόνης σε Jetpack Compose δεν θα επηρεάσει την επιχειρηματική λογική.

Η δοκιμή του ViewModel δεν απαιτεί εκκίνηση εξομοιωτή ή προσομοιωτή — αρκούν οι μοναδιαίες δοκιμές που ελέγχουν τη μετατροπή δεδομένων και την αντίδραση σε ενέργειες χρήστη. Αυτό είναι άμεση συνέπεια του Separation of Concerns: το UI δεν αναμιγνύεται με επιχειρηματικούς κανόνες και κάθε στοιχείο δοκιμάζεται απομονωμένα.

Επίπεδο επιχειρηματικής λογικής: Use Cases και Interactors

Use Case (ή Interactor) περιέχει τους επιχειρηματικούς κανόνες της εφαρμογής — υπολογισμούς, επικυρώσεις, ενορχήστρωση κλήσεων σε δεδομένα. Αυτό το επίπεδο δεν γνωρίζει την ύπαρξη UI και πλαισίων πλατφόρμας. Το Use Case λαμβάνει δεδομένα από το Repository, εφαρμόζει λογική και επιστρέφει το έτοιμο αποτέλεσμα στο ViewModel. Ο διαχωρισμός επιτρέπει την επαναχρησιμοποίηση ενός Use Case σε διαφορετικές οθόνες.

Για παράδειγμα, το LoginUseCase ελέγχει την εγκυρότητα email, καλεί το AuthRepository για αυθεντικοποίηση και επιστρέφει το αποτέλεσμα. Δεν εξαρτάται από το πώς φαίνεται η οθόνη σύνδεσης — SwiftUI, UIKit ή Compose. Αν αλλάξουν οι επιχειρηματικοί κανόνες, αρκεί να τροποποιηθεί ένα Use Case χωρίς να αγγιχτεί το UI και η βάση δεδομένων.

Επίπεδο δεδομένων: Repository και DataSource

Το Repository αφαιρεί τις πηγές δεδομένων: απομακρυσμένο API, τοπική βάση δεδομένων ή προσωρινή μνήμη. Το ViewModel και το Use Case δεν γνωρίζουν από πού ακριβώς προέρχονται τα δεδομένα — το Repository αποφασίζει αν θα φορτώσει από το δίκτυο ή από την προσωρινή μνήμη. Αυτός ο διαχωρισμός επιτρέπει την αλλαγή υλοποίησης αποθήκευσης χωρίς να επηρεάζεται η επιχειρηματική λογική και το UI.

Το DataSource είναι ένας ακόμη χαμηλότερου επιπέδου διαχωρισμός: το NetworkDataSource είναι υπεύθυνο μόνο για αιτήματα HTTP, το LocalDataSource — για εργασία με Room ή CoreData. Το Repository συνδυάζει κλήσεις σε διαφορετικά DataSource σε μια ενιαία συνεπή διεπαφή. Κάθε DataSource δοκιμάζεται ανεξάρτητα με χρήση mock ή ψεύτικων διακομιστών.

Η σωστή υλοποίηση του επιπέδου DataSource εγγυάται ότι η αλλαγή σχήματος βάσης δεδομένων ή η αντικατάσταση REST API με GraphQL θα επηρεάσει μόνο ένα DataSource, αλλά όχι το Repository και τους καταναλωτές του. Αυτό είναι άμεση συνέπεια του Separation of Concerns σε επίπεδο υποδομής: κάθε technical concern είναι απομονωμένο και αντικαταστάσιμο χωρίς αλυσιδωτές αλλαγές.

SoC στα πρότυπα σχεδίασης

MVVM (Model-View-ViewModel) — το πιο δημοφιλές πρότυπο για ανάπτυξη κινητών, που υλοποιεί άμεσα το Separation of Concerns. Το Model περιέχει δεδομένα και επιχειρηματική λογική, το View είναι υπεύθυνο για την εμφάνιση και το ViewModel τα συνδέει μέσω αντιδραστικών μηχανισμών. Στο Flutter, παρόμοιο ρόλο παίζει το BLoC με διαχωρισμό σε συμβάντα, καταστάσεις και επιχειρηματική λογική.

Clean Architecture του Robert Martin (Uncle Bob) φέρνει το SoC στο μέγιστο: το σύστημα χωρίζεται σε ανεξάρτητους δακτυλίους — οντότητες, use cases, προσαρμογείς και πλαίσια. Οι εσωτερικοί δακτύλιοι (οντότητες) δεν εξαρτώνται από τους εξωτερικούς (πλαίσια). Αυτό επιτρέπει την αλλαγή βάσης δεδομένων, πλαισίου UI και ακόμη και πλατφόρμας χωρίς επανεγγραφή της βασικής λογικής της εφαρμογής.

Στην πράξη, τα κινητά έργα σπάνια υλοποιούν πλήρη Clean Architecture — για τις περισσότερες εφαρμογές αρκεί η τριών επιπέδων αρχιτεκτονική: UI, Domain και Data. Το επίπεδο Domain περιέχει Use Cases και επιχειρηματικά μοντέλα και είναι πλήρως απομονωμένο από το Android SDK ή iOS SDK. Ένας τέτοιος διαχωρισμός δίνει 80% όφελος με 20% προσπάθεια.

// Data layer — υπεύθυνο μόνο για τη λήψη δεδομένων
class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User = api.fetchUser(id)
}

// Domain layer — επιχειρηματική λογική, δεν γνωρίζει API ή βάση
class GetUserNameUseCase(
    private val repo: UserRepository
) {
    suspend fun invoke(id: String): String {
        val user = repo.getUser(id)
        return "${user.firstName} ${user.lastName}"
    }
}

// UI layer — μόνο εμφάνιση
class UserViewModel(
    private val getUserName: GetUserNameUseCase
) {
    fun onUserLoaded(id: String) {
        viewModelScope.launch {
            _name.value = getUserName.invoke(id)
        }
    }
}

Ο παραπάνω κώδικας δείχνει καθαρό διαχωρισμό: το UserRepository λειτουργεί μόνο με API, το GetUserNameUseCase περιέχει επιχειρηματική λογική μορφοποίησης ονόματος και το UserViewModel διαχειρίζεται την κατάσταση UI. Κάθε κλάση έχει έναν λόγο αλλαγής, που είναι η ουσία του Separation of Concerns.

Πλεονεκτήματα και περιορισμοί του Separation of Concerns

Το κύριο πλεονέκτημα του SoC — η συντηρησιμότητα. Ο κώδικας που χωρίζεται σε ανεξάρτητα επίπεδα είναι ευκολότερο να αναλυθεί: ο προγραμματιστής κοιτάζει μόνο το επίπεδο όπου συμβαίνει το σφάλμα και δεν αποσπάται από τα υπόλοιπα. Σε μακροπρόθεσμα έργα, αυτό μειώνει τον χρόνο αναζήτησης και διόρθωσης σφαλμάτων κατά 30–50% σε σύγκριση με μονολιθικό κώδικα.

Το δεύτερο σημαντικό πλεονέκτημα — η δυνατότητα δοκιμής. Όταν η επιχειρηματική λογική είναι απομονωμένη από UI και πλαίσια, καλύπτεται από μοναδιαίες δοκιμές χωρίς εκκίνηση εξομοιωτή. Τα έργα Android και iOS με υψηλή κάλυψη μοναδιαίων δοκιμών έχουν σημαντικά λιγότερες παλινδρομήσεις κατά την προσθήκη νέων λειτουργιών.

Ο κύριος περιορισμός — η αύξηση πολυπλοκότητας. Ο υπερβολικός κατακερματισμός σε μικροεπίπεδα και αφαιρέσεις οδηγεί στο ότι για την προσθήκη ενός απλού κουμπιού ο προγραμματιστής επεξεργάζεται πέντε αρχεία. Η αρχή Separation of Concerns απαιτεί λογική ισορροπία: διαχωρίστε μόνο εκείνους τους τομείς που αλλάζουν πραγματικά ανεξάρτητα. Για μικρά έργα, αρκεί ο βασικός διαχωρισμός σε UI, λογική και δεδομένα χωρίς πρόσθετες αφαιρέσεις.