Το λογισμικό γραφής είναι μια πράξη δημιουργίας και η ανάπτυξη Android δεν αποτελεί εξαίρεση. Είναι κάτι περισσότερο από το να κάνεις κάτι να λειτουργεί. Πρόκειται για το σχεδιασμό εφαρμογών που μπορούν να αναπτυχθούν, να προσαρμοστούν και να παραμείνουν διαχειρίσιμες με την πάροδο του χρόνου.

Ως προγραμματιστής Android που έχει αντιμετωπίσει αμέτρητες αρχιτεκτονικές προκλήσεις, ανακάλυψα ότι η τήρηση των αρχών SOLID μπορεί να μετατρέψει ακόμη και τις πιο μπερδεμένες βάσεις κώδικα σε καθαρά συστήματα. Αυτές δεν είναι αφηρημένες αρχές, αλλά προσανατολισμένοι στα αποτελέσματα και αναπαραγόμενοι τρόποι για τη σύνταξη ισχυρού, επεκτάσιμου και διατηρήσιμου κώδικα.

Αυτό το άρθρο θα παρέχει πληροφορίες για το πώς οι αρχές SOLID μπορούν να εφαρμοστούν στην ανάπτυξη Android μέσω πραγματικών παραδειγμάτων, πρακτικών τεχνικών και εμπειρίας από την ομάδα Meta WhatsApp.

Κατανόηση των αρχών SOLID

Οι αρχές SOLID, που προτάθηκαν από τον Robert C. Martin, είναι πέντε αρχές σχεδιασμού για αντικειμενοστραφή προγραμματισμό που εγγυώνται καθαρή και αποτελεσματική αρχιτεκτονική λογισμικού.

• Αρχή Ενιαίας Ευθύνης (SRP): Μια τάξη πρέπει να έχει έναν και μόνο λόγο να αλλάξει.
• Αρχή ανοιχτού/κλειστού (OCP): Οι οντότητες λογισμικού θα πρέπει να είναι ανοιχτές για επέκταση αλλά κλειστές για τροποποίηση.
• Αρχή αντικατάστασης Liskov (LSP): Οι υποτύποι πρέπει να μπορούν να υποκατασταθούν για τους βασικούς τους τύπους.
• Αρχή διαχωρισμού διεπαφής (ISP): Οι διεπαφές πρέπει να είναι συγκεκριμένες για τον πελάτη και να μην επιβάλλουν την εφαρμογή αχρησιμοποίητων μεθόδων.
• Αρχή αντιστροφής εξάρτησης (DIP): Οι ενότητες υψηλού επιπέδου πρέπει να εξαρτώνται από αφαιρέσεις, όχι από ενότητες χαμηλού επιπέδου.

Ενσωματώνοντας αυτές τις αρχές στην ανάπτυξη Android, μπορούμε να δημιουργήσουμε εφαρμογές που είναι πιο εύκολο να κλιμακωθούν, να δοκιμαστούν και να διατηρηθούν.

Ενιαία Αρχή Ευθύνης (SRP): Εξορθολογισμός των ευθυνών

Η Αρχή της Ενιαίας Ευθύνης είναι το θεμέλιο της σύνταξης διατηρήσιμου κώδικα. Αναφέρει ότι κάθε τάξη πρέπει να έχει ένα μόνο μέλημα για το οποίο αναλαμβάνει την ευθύνη. Ένα συνηθισμένο αντί-μοτίβο θεωρεί ότι οι Δραστηριότητες ή τα Fragments είναι κάποιες «τάξεις του Θεού» που χειρίζονται ευθύνες ξεκινώντας από την απόδοση διεπαφής χρήστη, μετά την ανάκτηση δεδομένων, τον χειρισμό σφαλμάτων κ.λπ. Αυτή η προσέγγιση κάνει εφιάλτη για τη δοκιμή και τη συντήρηση.

Με το SRP, διαχωρίστε διαφορετικές ανησυχίες σε διαφορετικά στοιχεία: για παράδειγμα, σε μια εφαρμογή για ειδήσεις, δημιουργήστε ή διαβάστε ειδήσεις.

class NewsRepository {
    fun fetchNews(): List {
        // Handles data fetching logic
    }
}

class NewsViewModel(private val newsRepository: NewsRepository) {
    fun loadNews(): LiveData<List> {
        // Manages UI state and data flow
    }
}

class NewsActivity : AppCompatActivity() {
    // Handles only UI rendering
}

Κάθε τάξη έχει μόνο μία ευθύνη. Ως εκ τούτου, είναι εύκολο να δοκιμαστεί και να τροποποιηθεί χωρίς παρενέργειες.

Στη σύγχρονη ανάπτυξη Android, το SRP εφαρμόζεται κυρίως μαζί με τη συνιστώμενη αρχιτεκτονική χρησιμοποιώντας το Jetpack. Για παράδειγμα, η λογική που σχετίζεται με τη λογική χειρισμού δεδομένων μπορεί να βρίσκεται μέσα στο ViewModel, ενώ οι Δραστηριότητες ή τα Fragments θα πρέπει απλώς να ενδιαφέρονται για τη διεπαφή χρήστη και τις αλληλεπιδράσεις. Η ανάκτηση δεδομένων μπορεί να ανατεθεί σε κάποιο ξεχωριστό χώρο αποθήκευσης, είτε από τοπικές βάσεις δεδομένων όπως το δωμάτιο ή από επίπεδα δικτύου όπως το Retrofit. Αυτό μειώνει τον κίνδυνο φουσκώματος των κλάσεων διεπαφής χρήστη, καθώς κάθε στοιχείο έχει μόνο μία ευθύνη. Ταυτόχρονα, ο κώδικάς σας θα είναι πολύ πιο εύκολο να δοκιμαστεί και να υποστηριχθεί.

Open/Closed Principle (OCP): Σχεδιασμός για επέκταση

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

Το καλύτερο παράδειγμα του τρόπου χρήσης της αρχής OCP σε εφαρμογές Android είναι οι διεπαφές και οι αφηρημένες τάξεις. Για παράδειγμα:

interface PaymentMethod {
    fun processPayment(amount: Double)
}

class CreditCardPayment : PaymentMethod {
    override fun processPayment(amount: Double) {
        // Implementation for credit card payments
    }
}

class PayPalPayment : PaymentMethod {
    override fun processPayment(amount: Double) {
        // Implementation for PayPal payments
    }
}

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

Σε εφαρμογές που δημιουργήθηκαν για συσκευές Android, η Αρχή Ανοιχτού/Κλειστού είναι πολύ χρήσιμη όταν πρόκειται για εναλλαγές και διαμορφώσεις που λαμβάνονται δυναμικά. Για παράδειγμα, σε περίπτωση που η εφαρμογή σας έχει μια βασική διεπαφή AnalyticsTracker που αναφέρει συμβάντα σε διαφορετικές υπηρεσίες αναλυτικών στοιχείων, Firebase και Mixpanel και προσαρμοσμένες εσωτερικές συσκευές παρακολούθησης, κάθε νέα υπηρεσία μπορεί να προστεθεί ως ξεχωριστή κλάση χωρίς αλλαγές στον υπάρχοντα κώδικα. Αυτό διατηρεί την ενότητα αναλυτικών στοιχείων σας ανοιχτή για επέκταση - μπορείτε να προσθέσετε νέα προγράμματα παρακολούθησης - αλλά κλειστή για τροποποίηση: δεν ξαναγράφετε υπάρχουσες κλάσεις κάθε φορά που προσθέτετε μια νέα υπηρεσία.

Αρχή αντικατάστασης Liskov (LSP): Εξασφάλιση εναλλαξιμότητας

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

Για παράδειγμα, μια εφαρμογή σχεδίασης:

abstract class Shape {
    abstract fun calculateArea(): Double
}

class Rectangle(private val width: Double, private val height: Double) : Shape() {
    override fun calculateArea() = width * height
}

class Circle(private val radius: Double) : Shape() {
    override fun calculateArea() = Math.PI * radius * radius
}

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

Σκεφτείτε το Android RecyclerView.Adapter υποκατηγορίες. Κάθε υποκατηγορία του προσαρμογέα εκτείνεται από RecyclerView.Adapter και παρακάμπτει βασικές λειτουργίες όπως onCreateViewHolder, onBindViewHolder, να getItemCount. ο RecyclerView μπορεί να χρησιμοποιήσει οποιαδήποτε υποκλάση εναλλακτικά, εφόσον αυτές οι μέθοδοι εφαρμόζονται σωστά και δεν παραβιάζουν τη λειτουργικότητα της εφαρμογής σας. Εδώ, το LSP διατηρείται και το RecyclerView μπορεί να είναι ευέλικτο για να αντικαταστήσει οποιαδήποτε υποκατηγορία προσαρμογέα κατά βούληση.

Αρχή διαχωρισμού διεπαφής (ISP): Λιτές και εστιασμένες διεπαφές

Σε μεγαλύτερες εφαρμογές, είναι σύνηθες να ορίζονται διεπαφές με υπερβολική ευθύνη, ειδικά γύρω από τη δικτύωση ή την αποθήκευση δεδομένων. Αντίθετα, σπάστε τα σε μικρότερες, πιο στοχευμένες διεπαφές. Για παράδειγμα, μια διεπαφή ApiAuth που είναι υπεύθυνη για τα τελικά σημεία ελέγχου ταυτότητας χρήστη θα πρέπει να διαφέρει από μια διεπαφή ApiPosts που είναι υπεύθυνη για αναρτήσεις ιστολογίου ή τελικά σημεία ροής κοινωνικής δικτύωσης. Αυτός ο διαχωρισμός θα αποτρέψει τους πελάτες που χρειάζονται μόνο τις μετα-σχετικές μεθόδους από το να εξαναγκαστούν να εξαρτώνται και να εφαρμόζουν κλήσεις ελέγχου ταυτότητας, διατηρώντας έτσι τον κωδικό σας, καθώς και τη δοκιμαστική κάλυψη, πιο λιτή.

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

Για παράδειγμα, αντί να έχετε μια μεγάλη διεπαφή που αντιπροσωπεύει τις ενέργειες των χρηστών, σκεφτείτε τον κώδικα kotlin:

interface Authentication {
    fun login()
    fun logout()
}

interface ProfileManagement {
    fun updateProfile()
    fun deleteAccount()
}

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

Αρχή αντιστροφής εξάρτησης (DIP): Αφαίρεση εξαρτήσεων

Η Αρχή Αντιστροφής Εξάρτησης προωθεί την αποσύνδεση διασφαλίζοντας ότι οι ενότητες υψηλού επιπέδου εξαρτώνται από αφαιρέσεις και όχι από συγκεκριμένες υλοποιήσεις. Αυτή η αρχή ευθυγραμμίζεται τέλεια με τις σύγχρονες πρακτικές ανάπτυξης του Android, ειδικά με τα πλαίσια έγχυσης εξάρτησης όπως το Dagger και το Hilt.

Για παράδειγμα:

class UserRepository @Inject constructor(private val apiService: ApiService) {
    fun fetchUserData() {
        // Fetches user data from an abstraction
    }
}

Εδώ, UserRepository εξαρτάται από την αφαίρεση ApiService, καθιστώντας το ευέλικτο και ελεγχόμενο. Αυτή η προσέγγιση μάς επιτρέπει να αντικαταστήσουμε την υλοποίηση, όπως τη χρήση μιας εικονικής υπηρεσίας κατά τη διάρκεια της δοκιμής.

Πλαίσια όπως το Hilt, το Dagger και το Koin διευκολύνουν την ένεση εξάρτησης παρέχοντας έναν τρόπο παροχής εξαρτήσεων σε στοιχεία Android, εξαλείφοντας την ανάγκη άμεσης δημιουργίας τους. Σε ένα αποθετήριο, για παράδειγμα, αντί να δημιουργήσετε μια εφαρμογή Retrofit, θα εισάγετε μια αφαίρεση - για παράδειγμα, μια διεπαφή ApiService. Με αυτόν τον τρόπο, θα μπορούσατε εύκολα να αλλάξετε την εφαρμογή δικτύου - για παράδειγμα, μια υπηρεσία εικονικής μνήμης για τοπικές δοκιμές - και δεν θα χρειαστεί να αλλάξετε τίποτα στον κώδικα του αποθετηρίου σας. Σε εφαρμογές της πραγματικής ζωής, μπορείτε να διαπιστώσετε ότι οι τάξεις σχολιάζονται με @Inject ή @Provides για να παρέχουν αυτές τις αφαιρέσεις, καθιστώντας έτσι την εφαρμογή σας σπονδυλωτή και φιλική προς τις δοκιμές.

Πρακτικά οφέλη των αρχών SOLID

Η υιοθέτηση ΣΤΕΡΕΩΝ αρχών στην ανάπτυξη Android αποφέρει απτά οφέλη:

1. Βελτιωμένη δυνατότητα δοκιμής: Οι εστιασμένες κλάσεις και διεπαφές διευκολύνουν τη σύνταξη δοκιμών μονάδας.
2. Βελτιωμένη δυνατότητα συντήρησης: Ο σαφής διαχωρισμός των ανησυχιών απλοποιεί τον εντοπισμό σφαλμάτων και τις ενημερώσεις.
3. Ευελιξία: Τα αρθρωτά σχέδια επιτρέπουν απρόσκοπτες προσθήκες χαρακτηριστικών.
4. Συνεργασία: Ο καλά δομημένος κώδικας διευκολύνει την ομαδική εργασία και μειώνει τον χρόνο ενσωμάτωσης για νέους προγραμματιστές.
5. Βελτιστοποίηση απόδοσης: Οι λιτές, αποτελεσματικές αρχιτεκτονικές ελαχιστοποιούν την περιττή χρήση επεξεργασίας και μνήμης.

Εφαρμογές πραγματικού κόσμου

Σε εφαρμογές πλούσιες σε χαρακτηριστικά, όπως το ηλεκτρονικό εμπόριο ή οι εφαρμογές κοινωνικής δικτύωσης, η εφαρμογή των αρχών SOLID μπορεί να μειώσει σημαντικά τον κίνδυνο παλινδρόμησης κάθε φορά που προστίθεται μια νέα δυνατότητα ή υπηρεσία. Για παράδειγμα, εάν μια νέα απαίτηση απαιτεί ροή αγορών εντός εφαρμογής, μπορείτε να εισαγάγετε μια ξεχωριστή ενότητα που θα υλοποιεί τις απαιτούμενες διεπαφές (Πληρωμή, Analytics) χωρίς να αγγίζετε τις υπάρχουσες λειτουργικές μονάδες. Αυτό το είδος σπονδυλωτής προσέγγισης, που καθοδηγείται από το SOLID, επιτρέπει στην εφαρμογή σας Android να προσαρμόζεται γρήγορα στις απαιτήσεις της αγοράς και εμποδίζει τη βάση κώδικα να μετατραπεί σε σπαγγέτι με την πάροδο του χρόνου.

Ενώ εργάζεστε σε ένα μεγάλο έργο που απαιτεί τη συνεργασία πολλών προγραμματιστών, συνιστάται ιδιαίτερα να διατηρείτε μια πολύπλοκη βάση κώδικα με αρχές ΣΤΕΡΕΑΣ. Για παράδειγμα, ο διαχωρισμός της ανάκτησης δεδομένων, της επιχειρηματικής λογικής και του χειρισμού διεπαφής χρήστη στη λειτουργική μονάδα συνομιλίας βοήθησε στη μείωση της πιθανότητας παλινδρόμησης κατά την κλιμάκωση του κώδικα με νέες δυνατότητες. Ομοίως, η εφαρμογή του DIP ήταν ζωτικής σημασίας για αφηρημένες λειτουργίες δικτύου, επομένως ήταν σε θέση να αλλάξει χωρίς σχεδόν καμία διακοπή μεταξύ των πελατών δικτύου.

Συμπέρασμα

Περισσότερο από έναν θεωρητικό οδηγό, οι αρχές του SOLID είναι στην πραγματικότητα η πρακτική φιλοσοφία για τη δημιουργία ανθεκτικού, προσαρμόσιμου και συντηρήσιμου λογισμικού. Στον ταχέως εξελισσόμενο κόσμο της ανάπτυξης Android, με τις απαιτήσεις να αλλάζουν σχεδόν όσο συχνά αλλάζουν οι τεχνολογίες, η τήρηση αυτών των αρχών παρέχει ένα σταθερό έδαφος στο οποίο μπορεί να θεμελιωθεί η επιτυχία.

Ο καλός κώδικας δεν έχει να κάνει μόνο με τη δημιουργία ενός συστήματος που μπορεί να συνεχίσει να λειτουργεί και να αναπτύσσεται με τις εξελισσόμενες ανάγκες. Υιοθετώντας τις αρχές SOLID, όχι μόνο θα γράψετε καλύτερο κώδικα, αλλά θα δημιουργήσετε και εφαρμογές που είναι ευχάριστο να αναπτύσσονται, να κλιμακώνονται και να διατηρούνται.