Αρχιτεκτονικές αρχές στην κινητή ανάπτυξη: τι είναι, τι είδη υπάρχουν και πώς να εφαρμοστούν

Αρχές SOLID

Οι αρχιτεκτονικές αρχές — είναι το θεμέλιο του ποιοτικού κώδικα. Το SOLID είναι ένα ακρωνύμιο που εισήχθη από τον Robert Martin («Θείος Μπομπ») και περιγράφει πέντε αρχές αντικειμενοστρεφούς σχεδιασμού. Η τήρηση του SOLID κάνει τον κώδικα πιο ευέλικτο, πιο ελέγξιμο και ανθεκτικό σε αλλαγές. Η παραβίαση των αρχιτεκτονικών αρχών είναι μία από τις κύριες αιτίες τεχνικής οφειλής.

Ας εξετάσουμε κάθε αρχή. Single Responsibility Principle (SRP) — κάθε κλάση πρέπει να έχει μόνο έναν λόγο για αλλαγή. Open/Closed Principle (OCP) — οι κλάσεις είναι ανοιχτές για επέκταση αλλά κλειστές για τροποποίηση. Liskov Substitution Principle (LSP) — τα αντικείμενα υποτύπων πρέπει να αντικαθιστούν αντικείμενα βασικού τύπου χωρίς να σπάζουν τη λογική. Interface Segregation Principle (ISP) — πολλά εξειδικευμένα interfaces είναι καλύτερα από ένα γενικό. Dependency Inversion Principle (DIP) — εξάρτηση από αφαιρέσεις, όχι από συγκεκριμένες υλοποιήσεις.

Σύμφωνα με ανάλυση SonarQube (2025), παραβίαση των αρχών SOLID εμφανίζεται στο 68% των εμπορικών έργων. Τα πιο κοινά προβλήματα είναι παραβίαση SRP (35%) και ISP (22%). Στην IT Sectr, εφαρμόζουμε το SOLID στο στάδιο αρχιτεκτονικής ανασκόπησης — αυτό βοηθά στον εντοπισμό προβλημάτων πριν εξελιχθούν σε τεχνική οφειλή.

Single Responsibility Principle (SRP)

SRP (Αρχή Μοναδικής Ευθύνης) — η πιο σημαντική και ταυτόχρονα η πιο συχνά παραβιαζόμενη αρχή SOLID. Λέει: μια κλάση πρέπει να έχει μόνο έναν λόγο για αλλαγή. Αν μια κλάση κάνει πάρα πολλά, είναι δύσκολο να ελεγχθεί, να τροποποιηθεί και να κατανοηθεί.

Μια τυπική παραβίαση είναι μια κλάση που ταυτόχρονα επεξεργάζεται δεδομένα, τα αποθηκεύει στη βάση δεδομένων και στέλνει ειδοποιήσεις email. Το παρακάτω παράδειγμα δείχνει παραβίαση SRP στην Kotlin και πώς να τη διορθώσετε.

// Παραβίαση SRP — η κλάση κάνει τρία διαφορετικά πράγματα
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Επικύρωση δεδομένων
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Αποθήκευση στη βάση
        val user = User(email, name)
        database.save(user)
        
        // 3. Αποστολή ειδοποίησης
        emailService.sendWelcomeEmail(email, name)
    }
}

// Διόρθωση — διαίρεση σε τρεις κλάσεις
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

Στη διορθωμένη έκδοση, κάθε κλάση είναι υπεύθυνη για τη δική της εργασία: UserValidator — για επικύρωση, UserRepository — για αποθήκευση, NotificationService — για ειδοποιήσεις. Αυτό κάνει τον κώδικα ελέγξιμο και επαναχρησιμοποιήσιμο — μπορείτε να αντικαταστήσετε την υλοποίηση βάσης δεδομένων χωρίς να αλλάξετε τη λογική επικύρωσης.

GRASP και Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — εννέα αρχιτεκτονικές αρχές για κατανομή ευθύνης μεταξύ αντικειμένων, που περιγράφηκαν από τον Craig Larman. Σε αντίθεση με το SOLID, το GRASP απαντά στην ερώτηση «ποια κλάση πρέπει να περιέχει αυτή τη μέθοδο;». Βασικά μοτίβα: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, αρχή ελάχιστης σύζευξης) — ένας απλός κανόνας: ένα αντικείμενο πρέπει να επικοινωνεί μόνο με τους άμεσους γείτονές του. Δεν πρέπει να γράφετε a.getB().getC().doSomething() — αυτό δημιουργεί ισχυρή σύζευξη μεταξύ κλάσεων. Το LoD βελτιώνει την επαναχρησιμοποίηση και απλοποιεί τη δοκιμή.

Στην IT Sectr, ελέγχουμε τη συμμόρφωση με το LoD κατά την Ανασκόπηση Κώδικα. Αν μια μέθοδος «περνάει» μέσα από τρία ή περισσότερα αντικείμενα, είναι σήμα ότι η αρχιτεκτονική χρειάζεται απλοποίηση. Η παραβίαση LoD είναι ένα από τα πιο κοινά Code Smell σε μεγάλα έργα.

DRY / KISS / YAGNI

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

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

KISS — όσο πιο απλό, τόσο καλύτερα. Οι πολύπλοκες λύσεις με πολλές αφαιρέσεις και κληρονομικότητες είναι συχνά υπερβολικές. Ξεκινήστε με μια απλή λύση και κάντε την πιο περίπλοκη μόνο όταν χρειαστεί. YAGNI — μην γράφετε κώδικα για λειτουργικότητα που μπορεί να χρειαστεί «κάποτε αργότερα». Αυτό οδηγεί σε φούσκωμα της βάσης κώδικα και αυξημένη πολυπλοκότητα συντήρησης.

DRY — Don't Repeat Yourself

DRY — δεν αφορά μόνο την απουσία αντιγραφής-επικόλλησης. Είναι μια αρχή σύμφωνα με την οποία κάθε κομμάτι γνώσης ή λογικής πρέπει να έχει μια ενιαία, σαφή αναπαράσταση στο σύστημα. Η επανάληψη μπορεί να είναι ρητή (αντιγραμμένος κώδικας) και σιωπηρή (ίδια λογική σε διαφορετικά επίπεδα).

Στην IT Sectr, χρησιμοποιούμε μετρήσεις ανάλυσης κώδικα για την ανίχνευση επαναλήψεων. Εργαλεία όπως το SonarQube και το Detekt δείχνουν το ποσοστό επαναλαμβανόμενου κώδικα. Μια τιμή άνω του 5% είναι λόγος για αναδιάρθρωση. Ωστόσο, είναι σημαντικό να θυμάστε: το DRY δεν πρέπει να επιτυγχάνεται εις βάρος λανθασμένων αφαιρέσεων — μερικές φορές είναι καλύτερο να αφήνετε δύο παρόμοια κομμάτια κώδικα ως έχουν αν η συνένωσή τους θα περιέπλεκε την κατανόηση.

Separation of Concerns και Modularity

Separation of Concerns (SoC) — μια αρχιτεκτονική αρχή όπου ένα σύστημα χωρίζεται σε ανεξάρτητα μέρη (concerns), το καθένα επιλύοντας τη δική του εργασία. Ένα κλασικό παράδειγμα είναι ο διαχωρισμός σε επίπεδα: παρουσίαση, επιχειρηματική λογική, πρόσβαση δεδομένων. Κάθε επίπεδο εξαρτάται μόνο από το υποκείμενο επίπεδο.

Modularity (αρθρωτότητα) — ο βαθμός στον οποίο ένα σύστημα μπορεί να χωριστεί σε ενότητες. Μια ενότητα είναι μια λογικά συσχετισμένη ομάδα κλάσεων με καλά καθορισμένο interface. Οι ενότητες πρέπει να είναι χαλαρά συζευγμένες (low coupling) και ισχυρά συνεκτικές (high cohesion).

Συνοχή vs Σύζευξη

Συνοχή (Cohesion) — ένα μέτρο του πόσο τα στοιχεία μέσα στην ίδια ενότητα σχετίζονται μεταξύ τους. Η υψηλή συνοχή είναι καλή: μια κλάση κάνει ένα πράγμα και το κάνει καλά. Χαμηλή σύζευξη (Low coupling) — ένα μέτρο του πόσο ανεξάρτητες είναι οι ενότητες μεταξύ τους. Η χαμηλή σύζευξη είναι καλή: η αλλαγή μιας ενότητας δεν σπάει τις άλλες.

Η ιδανική αρχιτεκτονική είναι υψηλή συνοχή και χαμηλή σύζευξη. Στην πράξη, αυτό σημαίνει: μια κλάση περιέχει μεθόδους που εργάζονται στα ίδια δεδομένα (συνοχή) και εξαρτάται μόνο από αφαιρέσεις, όχι από συγκεκριμένες υλοποιήσεις (σύζευξη). Μια ανισορροπία οδηγεί σε «Αντικείμενα Θεό» ή «κώδικα μακαρόνια».

Τεχνική οφειλή και Code Smell

Τεχνική οφειλή (Technical Debt) — μια μεταφορά που εισήχθη από τον Ward Cunningham που περιγράφει τους «τόκους» που πληρώνει μια ομάδα για μη βέλτιστες αρχιτεκτονικές αποφάσεις και παραβίαση αρχιτεκτονικών αρχών. Όπως η οικονομική οφειλή, η τεχνική οφειλή μπορεί να είναι σκόπιμη (αποφασίσαμε να το κάνουμε γρήγορα, θα το ξανακάνουμε αργότερα) και ακούσια (κακή αρχιτεκτονική λόγω έλλειψης εμπειρίας).

Code Smell — επιφανειακά σημάδια βαθιών προβλημάτων στον κώδικα. Ο όρος διαδόθηκε από τον Martin Fowler στο βιβλίο «Refactoring». Τυπικά Code Smell: μακριές μέθοδοι, μεγάλες κλάσεις, μακριές αλυσίδες κλήσεων, επανάληψη κώδικα, υπερβολική χρήση σχολίων (αντί για σαφή κώδικα).

Στην IT Sectr, η τεχνική οφειλή παρακολουθείται στο Jira ως ξεχωριστές εργασίες. Κάθε sprint, διαθέτουμε το 20% του χρόνου για αναδιάρθρωση και αποπληρωμή οφειλής. Η συστηματική εργασία με την τεχνική οφειλή είναι ο μόνος τρόπος να αποφευχθεί μια κατάσταση όπου η προσθήκη μιας νέας λειτουργίας διαρκεί περισσότερο από την ανάπτυξή της από το μηδέν.