Mga Prinsipyo ng Arkitektura sa Mobile Development: Ano Ang mga Ito, Mga Uri, at Paano Ilapat

Mga Prinsipyo ng SOLID

Mga prinsipyo ng arkitektura — ay pundasyon ng de-kalidad na code. Ang SOLID ay isang acronym na ipinakilala ni Robert Martin («Uncle Bob») na naglalarawan ng limang prinsipyo ng object-oriented na disenyo. Ang pagsunod sa SOLID ay ginagawang mas nababaluktot, nasusuri at lumalaban sa pagbabago ang code. Ang paglabag sa mga prinsipyo ng arkitektura ay isa sa mga pangunahing sanhi ng teknikal na utang.

Tingnan natin ang bawat prinsipyo. Single Responsibility Principle (SRP) — bawat klase ay dapat magkaroon lamang ng isang dahilan upang magbago. Open/Closed Principle (OCP) — ang mga klase ay bukas para sa extension ngunit sarado para sa pagbabago. Liskov Substitution Principle (LSP) — ang mga bagay ng mga subtype ay dapat na palitan ang mga bagay ng base type nang hindi sinisira ang lohika. Interface Segregation Principle (ISP) — maraming espesyalisadong interface ang mas mabuti kaysa isang pangkalahatang interface. Dependency Inversion Principle (DIP) — umasa sa mga abstraksyon, hindi sa mga kongkretong implementasyon.

Ayon sa pagsusuri ng SonarQube (2025), ang paglabag sa mga prinsipyo ng SOLID ay nangyayari sa 68% ng mga komersyal na proyekto. Ang pinakakaraniwang problema ay paglabag sa SRP (35%) at ISP (22%). Sa IT Sectr, ipinapatupad namin ang SOLID sa yugto ng pagsusuri ng arkitektura — nakakatulong ito na matukoy ang mga problema bago sila maging teknikal na utang.

Single Responsibility Principle (SRP)

SRP (Prinsipyo ng Nag-iisang Responsibilidad) — ang pinakamahalaga at kasabay na pinakamadalas na nilalabag na prinsipyo ng SOLID. Ito ay nagsasaad: ang isang klase ay dapat magkaroon lamang ng isang dahilan upang magbago. Kung ang isang klase ay gumagawa ng sobra, mahirap itong subukan, baguhin at unawain.

Ang isang tipikal na paglabag ay isang klase na sabay na nagpoproseso ng data, nagse-save sa database, at nagpapadala ng mga email notification. Ang halimbawa sa ibaba ay nagpapakita ng paglabag sa SRP sa Kotlin at kung paano ito ayusin.

// Paglabag sa SRP — klase ay gumagawa ng tatlong magkakaibang bagay
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Pagpapatunay ng data
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. I-save sa database
        val user = User(email, name)
        database.save(user)
        
        // 3. Magpadala ng notification
        emailService.sendWelcomeEmail(email, name)
    }
}

// Pag-aayos — hatiin sa tatlong klase
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

Sa naayos na bersyon, ang bawat klase ay responsable para sa sarili nitong gawain: UserValidator — para sa pagpapatunay, UserRepository — para sa pag-save, NotificationService — para sa mga notification. Ginagawa nitong nasusuri at magagamit muli ang code — maaari mong palitan ang implementasyon ng database nang hindi binabago ang lohika ng pagpapatunay.

GRASP at Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — siyam na prinsipyo ng arkitektura para sa pamamahagi ng responsibilidad sa pagitan ng mga bagay, na inilarawan ni Craig Larman. Hindi tulad ng SOLID, sinasagot ng GRASP ang tanong na «aling klase ang dapat maglaman ng pamamaraang ito?». Mga pangunahing pattern: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, prinsipyo ng minimal na pagkakabit) — isang simpleng panuntunan: ang isang bagay ay dapat makipag-ugnayan lamang sa mga agarang kapitbahay nito. Hindi dapat magsulat ng a.getB().getC().doSomething() — lumilikha ito ng malakas na pagkakabit sa pagitan ng mga klase. Pinapabuti ng LoD ang muling paggamit at pinapasimple ang pagsubok.

Sa IT Sectr, sinusuri namin ang pagsunod sa LoD sa panahon ng Pagsusuri ng Code. Kung ang isang pamamaraan ay «dumadaan» sa tatlo o higit pang mga bagay, ito ay senyales na ang arkitektura ay kailangang gawing simple. Ang paglabag sa LoD ay isa sa mga pinakakaraniwang Code Smell sa malalaking proyekto.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) at YAGNI (You Ain't Gonna Need It) — tatlong pangunahing prinsipyo ng arkitektura na alam ng bawat developer. Sa kabila ng kanilang pagiging simple, ang mga paglabag ay patuloy na nangyayari.

DRY — huwag dumoble ng code. Kung ang parehong lohika ay lumitaw sa dalawang lugar, i-extract ito sa isang karaniwang pamamaraan o klase. Ang pagdodoble ay pangunahing pinagmumulan ng mga bug: ang pag-aayos sa isang lugar ay nakalimutang ilapat sa iba. Ang DRY ay hindi nangangahulugang hindi ka maaaring magkaroon ng katulad na code — ang mahalaga ay ang lohika ng negosyo ay hindi nauulit.

KISS — kung gaano kasimple, mas mabuti. Ang mga komplikadong solusyon na may maraming abstraksyon at pamana ay madalas na labis. Magsimula sa isang simpleng solusyon at gawin itong mas kumplikado lamang kung kinakailangan. YAGNI — huwag sumulat ng code para sa functionality na maaaring kailanganin «balang araw mamaya». Ito ay humahantong sa paglobo ng codebase at pagtaas ng komplikasyon ng pagpapanatili.

DRY — Don't Repeat Yourself

DRY — hindi lamang ito tungkol sa kawalan ng copy-paste. Ito ay isang prinsipyo ayon sa kung saan ang bawat piraso ng kaalaman o lohika ay dapat magkaroon ng isang solong, hindi malabong representasyon sa sistema. Ang pagdodoble ay maaaring tahas (kinopyang code) at hindi tahas (parehong lohika sa iba't ibang layer).

Sa IT Sectr, gumagamit kami ng mga sukatan ng pagsusuri ng code upang matukoy ang pagdodoble. Ang mga tool tulad ng SonarQube at Detekt ay nagpapakita ng porsyento ng nadobleng code. Ang halagang higit sa 5% ay dahilan para sa refactoring. Gayunpaman, mahalagang tandaan: ang DRY ay hindi dapat makamit sa halaga ng mga maling abstraksyon — minsan mas mabuting iwan ang dalawang magkatulad na piraso ng code kung ano sila kung ang pagsasama-sama ng mga ito ay magpapakomplikado sa pag-unawa.

Separation of Concerns at Modularity

Separation of Concerns (SoC) — isang prinsipyo ng arkitektura kung saan ang isang sistema ay nahahati sa mga independiyenteng bahagi (concerns), bawat isa ay nilulutas ang sarili nitong gawain. Ang isang klasikong halimbawa ay paghahati sa mga layer: presentasyon, lohika ng negosyo, pag-access sa data. Ang bawat layer ay nakadepende lamang sa layer sa ibaba nito.

Modularity — ang antas kung saan ang isang sistema ay maaaring hatiin sa mga modyul. Ang isang modyul ay isang lohikal na nauugnay na grupo ng mga klase na may mahusay na tinukoy na interface. Ang mga modyul ay dapat na maluwag na magkabit (low coupling) at matinding magkaisa (high cohesion).

Cohesion vs Coupling

Cohesion (pagkakaisa) — isang sukatan kung gaano magkakaugnay ang mga elemento sa loob ng parehong modyul. Ang mataas na pagkakaisa ay mabuti: ang isang klase ay gumagawa ng isang bagay at ginagawa ito nang maayos. Mababang coupling (pagkakabit) — isang sukatan kung gaano independyente ang mga modyul sa isa't isa. Ang mababang pagkakabit ay mabuti: ang pagbabago ng isang modyul ay hindi sumisira sa iba.

Ang perpektong arkitektura ay mataas na pagkakaisa at mababang pagkakabit. Sa praktika, ito ay nangangahulugang: ang isang klase ay naglalaman ng mga pamamaraan na gumagana sa parehong data (pagkakaisa), at nakadepende lamang sa mga abstraksyon, hindi sa mga kongkretong implementasyon (pagkakabit). Ang kawalan ng balanse ay humahantong sa «Diyos na Bagay» o «spaghetti code».

Teknikal na Utang at Code Smell

Teknikal na utang (Technical Debt) — isang metapora na ipinakilala ni Ward Cunningham na naglalarawan ng «interes» na binabayaran ng isang koponan para sa hindi optimal na mga desisyon sa arkitektura at paglabag sa mga prinsipyo ng arkitektura. Tulad ng utang pinansyal, ang teknikal na utang ay maaaring sinasadya (nagpasya kaming gawin ito nang mabilis, gagawin namin itong muli mamaya) at hindi sinasadya (masamang arkitektura dahil sa kakulangan ng karanasan).

Code Smell — mababaw na mga palatandaan ng malalim na problema sa code. Ang termino ay pinasikat ni Martin Fowler sa aklat na «Refactoring». Mga karaniwang Code Smell: mahabang pamamaraan, malalaking klase, mahabang chain ng tawag, pagdodoble ng code, labis na paggamit ng mga komento (sa halip na malinaw na code).

Sa IT Sectr, ang teknikal na utang ay sinusubaybayan sa Jira bilang magkakahiwalay na gawain. Bawat sprint, naglalaan kami ng 20% ng oras para sa refactoring at pagbabayad ng utang. Ang sistematikong paggawa sa teknikal na utang ay ang tanging paraan upang maiwasan ang sitwasyon kung saan ang pagdaragdag ng bagong feature ay mas tumatagal kaysa sa pag-develop nito mula sa simula.