GRASP στην κινητή ανάπτυξη — τι είναι, εννέα μοτίβα και αρχές

Τι είναι το GRASP;

GRASP (General Responsibility Assignment Software Patterns) — μια μεθοδολογία κατανομής ευθυνών μεταξύ αντικειμένων που αναπτύχθηκε από τον Craig Larman. Σε αντίθεση με το SOLID, που περιγράφει δομικές αρχές κλάσεων, το GRASP απαντά στην ερώτηση: "ποιο αντικείμενο πρέπει να εκτελέσει αυτή τη λειτουργία;" Εννέα μοτίβα GRASP δίνουν συγκεκριμένα κριτήρια για τη λήψη αποφάσεων.

Ο Larman εισήγαγε το GRASP στην πρώτη έκδοση του "Applying UML and Patterns" (1998) ως απάντηση στο πρόβλημα του αντικειμενοστρεφούς σχεδιασμού — πού να τοποθετήσετε μια μέθοδο όταν πολλοί υποψήφιοι έχουν πρόσβαση στα ίδια δεδομένα. Κάθε μοτίβο GRASP είναι ένας κανόνας λήψης αποφάσεων βασισμένος σε μετρήσεις σύζευξης (coupling) και συνοχής (cohesion).

Σύμφωνα με Craig Larman: "Applying UML and Patterns, 3rd Edition", ομάδες που χρησιμοποιούν GRASP στην καθημερινή πρακτική code review μειώνουν τον αριθμό των αρχιτεκτονικών διαφωνιών κατά 40%, επειδή τα μοτίβα παρέχουν αντικειμενική, αναπαραγώγιμη επιχειρηματολογία: "η μέθοδος πρέπει να είναι εδώ, γιατί αυτή η κλάση είναι το Information Expert για αυτά τα δεδομένα".

Χρησιμοποιήστε το GRASP ως λίστα ελέγχου στο code review. Για κάθε νέα μέθοδο, ρωτήστε: "ποιο μοτίβο GRASP δικαιολογεί την τοποθέτηση αυτής της μεθόδου ακριβώς σε αυτήν την κλάση;" Αν δεν υπάρχει απάντηση — η ευθύνη κατανέμεται λανθασμένα.

Ιστορία της δημιουργίας του GRASP

GRASP προέκυψε ως πρακτικό συμπλήρωμα στη θεωρία του αντικειμενοστρεφούς σχεδιασμού. Πριν από το GRASP, οι αρχιτέκτονες βασίζονταν στη διαίσθηση και την εμπειρία — δεν υπήρχε επίσημο κριτήριο για το πού να τοποθετήσουν τη μέθοδο doSomething(). Ο Larman επισημοποίησε αυτά τα κριτήρια με τη μορφή εννέα μοτίβων με μετρήσιμες συνέπειες για το coupling και το cohesion.

Το όνομα GRASP — δεν είναι ακρωνύμιο (General Responsibility Assignment Software Patterns — μεταγενέστερη εξήγηση). Ο Larman επέλεξε τη λέξη "grasp" (κατανόηση, σύλληψη) ως μεταφορά για τη "σύλληψη" της σωστής κατανομής ευθυνών. Σήμερα το GRASP αποτελεί μέρος του τυπικού μαθήματος αντικειμενοστρεφούς ανάλυσης στα πανεπιστήμια (MIT, Stanford CS μαθήματα).

Μάθετε το GRASP πριν από το SOLID: SOLID — δομικές αρχές, GRASP — συμπεριφορικές αρχές. Η κατανόηση του GRASP καθιστά το SOLID προφανές, όχι ένα σύνολο κανόνων προς απομνημόνευση.

Εννέα μοτίβα GRASP: επισκόπηση

Information Expert

Information Expert — το βασικό μοτίβο GRASP: η ευθύνη για μια λειτουργία ανατίθεται στην κλάση που έχει τα δεδομένα για την εκτέλεσή της. Για παράδειγμα, αν χρειαστεί να υπολογιστεί το σύνολο μιας παραγγελίας — υπεύθυνη θα είναι η κλάση Order που κατέχει τη λίστα των στοιχείων. Αυτό το μοτίβο — το πρώτο πράγμα που πρέπει να ελέγξετε στο code review.

Creator

Creator καθορίζει ποια κλάση πρέπει να δημιουργεί στιγμιότυπα μιας άλλης κλάσης. Κανόνας: η κλάση Α δημιουργεί τη Β αν η Α συγκεντρώνει τη Β, περιέχει τη Β, χρησιμοποιεί τη Β ή έχει δεδομένα για την αρχικοποίηση της Β. Στην κινητή ανάπτυξη, το Creator συχνά συμπίπτει με τη μέθοδο εργοστασίου ή το μοτίβο Builder. Creator αποτρέπει τη χαοτική δημιουργία αντικειμένων σε ολόκληρο το έργο.

Controller

Controller αναθέτει τη λειτουργία συστήματος (είσοδος χρήστη, εξωτερικό συμβάν) σε ένα αντικείμενο ελεγκτή, όχι σε στοιχείο UI. Στο Android είναι το ViewModel, στο iOS — Presenter ή ViewModel. Ο ελεγκτής δεν πρέπει να είναι στοιχείο UI (Activity/UIViewController), διαφορετικά το UI υπερφορτώνεται με ευθύνη. Controller — ο άμεσος προκάτοχος του μοτίβου MVVM.

Low Coupling

Low Coupling — μέτρηση: όσο λιγότερα γνωρίζει μια κλάση για άλλες κλάσεις, τόσο πιο εύκολο είναι να τροποποιηθεί και να δοκιμαστεί. Η μείωση της σύζευξης επιτυγχάνεται μέσω έγχυσης εξαρτήσεων, διεπαφών και συμβάντων. Στην κινητή ανάπτυξη, η σύζευξη είναι ιδιαίτερα κρίσιμη: οι άκαμπτες συνδέσεις μεταξύ μονάδων επιβραδύνουν τη μεταγλώττιση (Gradle incremental build). Χαμηλή σύζευξη — μέτρηση στόχος, όχι συγκεκριμένη ενέργεια.

High Cohesion

High Cohesion — αντίστροφη μέτρηση: όσο πιο εστιασμένη είναι μια κλάση σε μία εργασία, τόσο καλύτερα. Μια κλάση με 3 μεθόδους που κάνουν διαφορετικά πράγματα έχει χαμηλή συνοχή. Μια κλάση με 15 μεθόδους που εκτελούν μία εργασία — υψηλή συνοχή. SOLID-SRP — άμεση συνέπεια του High Cohesion. Στην κινητή ανάπτυξη, το High Cohesion επιτυγχάνεται μέσω μικρών κλάσεων με σαφή τομέα ευθύνης.

Polymorphism

Polymorphism στο GRASP — δεν αφορά τον γλωσσικό πολυμορφισμό, αλλά τη συμπεριφορά που ποικίλλει ανά τύπο: αντί για if-else ανά τύπο, χρησιμοποιήστε διεπαφές με διαφορετικές υλοποιήσεις. Στο Android: διαφορετικές υλοποιήσεις RecyclerView.Adapter για διαφορετικούς τύπους κελιών. Στο iOS: διαφορετικές υλοποιήσεις UITableViewDataSource. Polymorphism στο GRASP — αφορά την αντικατάσταση δομών υπό όρους (if/switch) με πολυμορφικές κλήσεις.

Pure Fabrication

Pure Fabrication — μοτίβο που επιτρέπει τη δημιουργία κλάσεων που δεν αντιστοιχούν στο μοντέλο τομέα για τη βελτίωση του low coupling και του high cohesion. Παράδειγμα: Repository — μια κλάση που δεν υπάρχει στον τομέα του προβλήματος, αλλά είναι απαραίτητη για τον διαχωρισμό της πηγής δεδομένων από την επιχειρηματική λογική. Pure Fabrication δικαιολογεί την εισαγωγή επιπέδων που δεν υπάρχουν στην πραγματικότητα (Service, Provider, Manager).

Indirection

Indirection — μοτίβο που εισάγει ένα ενδιάμεσο αντικείμενο για επικοινωνία μεταξύ δύο στοιχείων, μειώνοντας τη σύζευξη. Παράδειγμα: Adapter μεταξύ RecyclerView και δεδομένων, Coordinator μεταξύ ViewController και πλοήγησης. Indirection — σημαίνει "απλά προσθέστε ένα ενδιάμεσο επίπεδο" όταν η άμεση σύνδεση δημιουργεί πολύ ισχυρή σύζευξη.

Protected Variations

Protected Variations — μοτίβο που προστάζει την προστασία του συστήματος από αλλαγές σε ορισμένα μέρη μέσω σταθερών διεπαφών σε άλλα μέρη. Αυτό είναι μια γενίκευση της Open-Closed Principle (SOLID). Παράδειγμα: ενθυλάκωση του επιπέδου δικτύου πίσω από το Repository — αν αλλάξει το API, η επιχειρηματική λογική δεν θα επηρεαστεί. Protected Variations — το στρατηγικό μοτίβο GRASP που απαντά στην ερώτηση "τι να κάνουμε με τα ασταθή στοιχεία".

GRASP και SOLID: ποια είναι η διαφορά;

SOLID — πέντε αρχές αντικειμενοστρεφούς σχεδιασμού που διατύπωσε ο Robert Martin. GRASP — εννέα μοτίβα που διατύπωσε ο Craig Larman. Η διαφορά είναι στο επίπεδο αφαίρεσης: SOLID — τι (ποιοτικά χαρακτηριστικά καλής αρχιτεκτονικής), GRASP — πώς (συγκεκριμένοι κανόνες κατανομής ευθυνών).

Ο συγκριτικός πίνακας δείχνει τη διασύνδεση:

Σύμφωνα με Martin Fowler: "UML Distilled, 3rd Edition", τα SOLID και GRASP δεν είναι ανταγωνιστές, αλλά συμπληρωματικά εργαλεία. Το SOLID θέτει στόχους, το GRASP — συγκεκριμένα βήματα για την επίτευξή τους. Στο code review, χρησιμοποιήστε και τα δύο σύνολα: SOLID για έλεγχο δομής κλάσεων, GRASP για έλεγχο κατανομής μεθόδων.

Εφαρμογή του GRASP στην κινητή ανάπτυξη

Information Expert στο Android: Repository

Repository — κλασικό παράδειγμα Information Expert. Τα δεδομένα μπορεί να προέρχονται από API (RemoteDataSource) ή από βάση δεδομένων (LocalDataSource). Το αποθετήριο είναι Information Expert, επειδή κατέχει πληροφορίες σχετικά με τις πηγές δεδομένων και την πολιτική (δίκτυο vs προσωρινή μνήμη).

// Information Expert: Το Repository γνωρίζει από πού να λάβει δεδομένα
class UserRepository(
    private val api: UserApi,
    private val db: UserDao
) {
    suspend fun getUser(id: String): User {
        val cached = db.getUser(id)
        if (cached != null) return cached
        val remote = api.fetchUser(id)
        db.insert(remote)
        return remote
    }
}

Το UserRepository είναι Information Expert, επειδή έχει πρόσβαση και στις δύο πηγές δεδομένων και γνωρίζει την πολιτική προσωρινής αποθήκευσης. ViewModel καλεί το getUser, χωρίς να γνωρίζει από πού προήλθαν τα δεδομένα — αυτό είναι Low Coupling μέσω Pure Fabrication.

Controller στο iOS: Presenter

Στο iOS το μοτίβο Controller GRASP υλοποιείται μέσω Presenter (ή ViewModel). Το UIViewController λαμβάνει το συμβάν (πάτημα κουμπιού) και το μεταβιβάζει στο Presenter που περιέχει την επιχειρηματική λογική. Το UIViewController δεν πρέπει να γνωρίζει πώς γίνεται η επεξεργασία του πατήματος.

// Controller: Το Presenter επεξεργάζεται την επιχειρηματική λογική
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // επικύρωση
            view.showError("Μη έγκυρο email")
            return
        }
        Task { // επιχειρηματική λογική
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// Το UIViewController απλά μεταβιβάζει το συμβάν
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

Το LoginPresenter είναι Controller σύμφωνα με το GRASP: λαμβάνει λειτουργίες συστήματος (πάτημα κουμπιού) και συντονίζει την εκτέλεση (επικύρωση, κλήση AuthService, πλοήγηση). UIViewController — απλά αναθέτει το συμβάν, διατηρώντας το Low Coupling.

Pure Fabrication: ViewModel

ViewModel — μια κλάση που δεν αντιστοιχεί στο μοντέλο τομέα (στον τομέα του προβλήματος δεν υπάρχει "ViewModel για προφίλ"). Pure Fabrication δικαιολογεί την ύπαρξή του: βελτιώνει το High Cohesion (η λογική UI διαχωρίζεται από το Activity/ViewController) και το Low Coupling (το Activity δεν εξαρτάται άμεσα από το Repository).

Σύμφωνα με Google: Guide to App Architecture (2024), το ViewModel είναι το συνιστώμενο επίπεδο για την προετοιμασία δεδομένων προς εμφάνιση. Χωρίς Pure Fabrication, αυτή η λογική θα έπρεπε να τοποθετηθεί στο Activity (παραβίαση SRP και High Cohesion) ή στο Fragment (διπλασιασμός). Pure Fabrication — το μοναδικό μοτίβο GRASP που λέει "δημιουργήστε μια κλάση που δεν υπάρχει στην πραγματικότητα".

Δημιουργήστε ViewModel για κάθε οθόνη, ακόμα κι αν η οθόνη φαίνεται "πολύ απλή". Το Pure Fabrication για ViewModel — το πρότυπο αρχιτεκτονικής Android, όχι υπερβολικός σχεδιασμός.

Συνηθισμένα λάθη κατά την εφαρμογή του GRASP

Παραβίαση Information Expert: δεδομένα σε μία κλάση, λογική — σε άλλη

Το πιο συνηθισμένο λάθος — τοποθέτηση της μεθόδου στην κλάση που δεν κατέχει τα δεδομένα. Κλασικό: το Activity περιέχει τη λίστα χρηστών, αλλά η μέθοδος φιλτραρίσματος — σε ξεχωριστή κλάση Utils. Το Activity κατέχει τα δεδομένα, το Utils — τη λογική. Σωστά: η μέθοδος φιλτραρίσματος πρέπει να είναι στην κλάση που κατέχει τη λίστα ή τα δεδομένα πρέπει να μεταβιβαστούν στο Utils ως παράμετρος.

Σύμπτωμα παραβίασης Information Expert: η μέθοδος δέχεται 3+ παραμέτρους, όλες πεδία άλλης κλάσης. Αυτό σημαίνει ότι η μέθοδος τοποθετήθηκε σε λάθος κλάση. Διόρθωση: μετακινήστε τη μέθοδο στην κλάση που κατέχει τα δεδομένα ή δημιουργήστε μια νέα κλάση (Pure Fabrication) που θα κατέχει τόσο τα δεδομένα όσο και τη λογική.

Ελέγξτε στο code review: αν μια μέθοδος δέχεται 3+ πεδία της ίδιας κλάσης ως παραμέτρους — αυτό είναι σημάδι ότι η μέθοδος πρέπει να είναι μέθοδος αυτής της κλάσης, όχι εξωτερική.

Κατάχρηση Pure Fabrication: πάρα πολλές τεχνητές κλάσεις

Pure Fabrication — ένα ισχυρό μοτίβο, αλλά η κατάχρησή του οδηγεί σε "πληθωρισμό κλάσεων": Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — κάθε δεύτερη κλάση είναι Pure Fabrication χωρίς πραγματικό ισοδύναμο τομέα. Συνέπεια: η βάση κώδικα χάνει τη σύνδεση με τον τομέα του προβλήματος.

Σύμφωνα με SEI Software Architecture Report (2023), έργα όπου πάνω από το 40% των κλάσεων είναι Pure Fabrication έχουν 29% υψηλότερο όριο εισόδου για νέους προγραμματιστές. Οι κλάσεις τομέα (User, Order, Product) είναι κατανοητές στην επιχείρηση. Οι κλάσεις Pure Fabrication (UserManager, OrderProcessor) — μόνο σε προγραμματιστές. Ισορροπία: όχι περισσότερο από 30% Pure Fabrication από τον συνολικό αριθμό κλάσεων.

Πριν δημιουργήσετε Pure Fabrication, ελέγξτε: μπορεί αυτή η ευθύνη να τοποθετηθεί σε υπάρχουσα κλάση τομέα (Information Expert); Αν ναι — μην δημιουργήσετε νέα κλάση. Αν όχι και το coupling/cohesion υποφέρουν — το Pure Fabrication είναι δικαιολογημένο.