Arkitektura at Pattern sa Mobile Development: Ano Ito, Mga Uri at Paano Ilapat

Mga Pangunahing Pattern ng Arkitektura

Ang pattern ng arkitektura ay tumutukoy kung paano ipinamamahagi ang mga responsibilidad sa mga klase ng application. Ang pagpili ng pattern ay nakakaapekto sa kadalian ng pagdagdag ng mga bagong screen at pagsubok ng code.

MVC (Model-View-Controller)

MVC ay isang klasikong pattern kung saan ang Model ay humahawak ng data, View ng display, at Controller ng logic. Sa iOS, ang MVC ay default (UIViewController); sa Android, Activity. Ang disbentaha ay ang Controller ay madalas na nagiging "napakalaki" (Massive View Controller). Ayon sa isang survey ng iOS developers (Reddit, 2025), 62% ang nagsasabi na ang MVC ang pangunahing dahilan ng hindi nababasang code sa mga lumang proyekto.

MVP (Model-View-Presenter)

MVP ay naiiba dahil ang Presenter ay namamahala sa View sa pamamagitan ng isang interface, na nagpapabuti sa testability. Ang MVP ay sikat sa Android bago ang Jetpack, ngunit nahuhuli sa MVVM sa kaginhawahan.

MVVM (Model-View-ViewModel)

MVVM ay ang inirerekomendang pattern ng Google para sa Android at Apple para sa iOS. Ang ViewModel ay nag-iimbak ng estado, at ang View ay nag-subscribe sa mga pagbabago sa pamamagitan ng Data Binding o @Published. Ang ViewModel ay hindi umaasa sa View at madaling subukan. Sa IT Sectr, ginagamit namin ang MVVM bilang pangunahing pattern sa lahat ng proyekto.

MVI at VIPER

MVI ay isang reactive pattern kung saan ang bawat aksyon ay sumusunod sa cycle na Intent → Model → View. Ginagarantiyahan ng MVI ang predictable na estado. VIPER ay isang iOS pattern na may limang layer (View, Interactor, Presenter, Entity, Router), na nagbibigay ng maximum na isolation ngunit nangangailangan ng maraming boilerplate code.

Clean Architecture

Clean Architecture ay ang konsepto ni Robert Martin na naghahati sa isang application sa mga layer: ang mga panlabas na layer (UI, DB, network) ay umaasa sa mga panloob na layer (business logic, entities). Sa mobile development, ang Clean Architecture ay may kasamang tatlong layer: data (repositories), domain (Use Cases), at presentation (ViewModels, UI).

Repository Pattern ay isang pangunahing bahagi ng Clean Architecture na nag-aabstrak sa pinagmulan ng data. Ang repository ay nagpapasya kung kukuha ng data mula sa network o lokal na imbakan (Room, Core Data) at nagbabalik ng pinag-isang format. Ayon sa Google (Architecture Guide, 2025), ang Repository Pattern ay inirerekomenda para sa anumang app na may mga kahilingan sa network. Ang Clean Architecture ay makatwiran sa mga proyekto na may 3–5 screen o higit pa — para sa mga simpleng app, magsimula sa MVVM.

Mga Pattern ng Paglikha

Singleton

Singleton ay isang pattern ng arkitektura na ginagarantiyahan ang iisang instance ng isang klase at nagbibigay ng global access point dito. Ito ay ginagamit para sa database, manager ng mga setting, at cache. Sa Kotlin, ito ay nilikha sa pamamagitan ng object. Ang disbentaha ay pinapahirapan nito ang pagsubok dahil sa global na estado.

Factory at Builder

Factory ay nagde-delegate ng paglikha ng mga bagay sa isang factory method — sa halip na new, tinatawag mo ang factory. Builder ay isang pattern ng step-by-step na paggawa para sa mga kumplikadong bagay na may maraming parameter (AlertDialog.Builder, NotificationCompat.Builder). Pinapabuti ng Builder ang pagiging madaling basahin at pinapayagan ang mga bagay na manatiling hindi nababago pagkatapos ng pag-assemble.

Mga Pattern ng Istruktura at Pag-uugali

Adapter, Facade, Delegate, Protocol

Adapter ay isang pattern ng arkitektura na nagko-convert ng interface ng isang klase sa isang interface na inaasahan ng client. Sa Android, ito ay RecyclerView.Adapter. Facade ay nagbibigay ng pinasimpleng interface sa isang kumplikadong sistema — halimbawa, isang facade para sa isang API na nagtatago ng mga detalye ng authentication. Delegate ay isang iOS pattern kung saan ang isang bagay ay nagde-delegate ng isang gawain (UITableViewDelegate). Protocol ay ang katumbas ng interface sa Swift.

Observer at Strategy

Observer ay isang pattern ng subscription para sa mga pagbabago: ang subject ay nagpapaalam sa mga subscriber tungkol sa mga update. Sa mobile development, ang Observer ay ang pundasyon ng LiveData, StateFlow, RxJava at Combine. Strategy ay isang pattern ng mga mapagpapalitang algorithm: ikinakabit mo ang ibang strategy (pag-uuri, pagpapatunay) nang walang maraming if-else statement.

Injection ng Dependency at Pamamahala ng Estado

Dependency Injection ay isang pattern ng arkitektura kung saan ang isang bagay ay tumatanggap ng mga dependency nito mula sa labas sa halip na likhain ang mga ito mismo. Sa halip na new Database(), ipinapasa mo ang database sa pamamagitan ng constructor. Pinapasimple ng DI ang pagsubok — maaari kang gumamit ng Mock sa halip na isang tunay na database — at pinapadali ang pagpapalit ng mga implementasyon. Mga sikat na DI framework: Dagger at Hilt (Android), Swinject (iOS), Koin (Kotlin). Ang Hilt — isang wrapper sa paligid ng Dagger na inirerekomenda ng Google — ay nagbabawas ng DI setup ng 3 beses.

Service Locator ay isang alternatibo sa DI na may central registry ng mga dependency. Mas simple na ipatupad, ngunit itinatago nito ang mga dependency ng klase, na nagpapahirap sa pagsubok. Mas gusto ng mga modernong proyekto ang DI sa pamamagitan ng Hilt o Koin.

Pamamahala ng Estado sa Flutter

Sa Flutter, ang pamamahala ng estado ay isang hiwalay na ecosystem. Redux — isang Store na may mga pagbabago sa pamamagitan ng Actions → Reducer → State. Ang BLoC ng Google ay naghihiwalay ng mga event at estado sa pamamagitan ng Stream. Provider — isang simpleng DI container na inirerekomenda ng Google para sa Flutter hanggang 2023. Riverpod — isang pinahusay na Provider na lumulutas ng mga problema sa compilation at pagsubok. GetX — isang micro-framework na may routing, DI at pamamahala ng estado. Para sa mga baguhang Flutter developer, inirerekomenda namin ang Provider o Riverpod bilang mga pinaka-dokumentadong solusyon.

Mga Prinsipyo ng SOLID at DRY

Bukod sa mga tiyak na pattern, may mga pangkalahatang prinsipyo ng disenyo ng arkitektura na naaangkop sa anumang wika at framework.

SOLID — limang prinsipyo ng object-oriented na disenyo: Single Responsibility (isang klase — isang gawain), Open-Closed (bukas para sa extension, sarado para sa pagbabago), Liskov Substitution (mga subclass ay pumapalit sa parent class), Interface Segregation (maliit na interface), Dependency Inversion (umaasa sa mga abstraction). Sa mobile development, ang SRP ay ang pinaka-kapaki-pakinabang na prinsipyo: bawat klase ay gumagawa lamang ng isang bagay. Ayon sa karanasan ng IT Sectr, ang paglabag sa SRP ay sanhi ng 70% ng mga problema sa pagsubok sa mga komersyal na proyekto.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

Ang halimbawa ng Kotlin ay nagpapakita kung paano namin ginagawang apat na klase na may tig-iisang responsibilidad ang isang UserManager class na may apat na responsibilidad. Ang ganitong code ay mas madaling subukan, baguhin at gamitin muli.

DRY (Don't Repeat Yourself) — iwasan ang pag-uulit ng code. Ilabas ang paulit-ulit na logic sa mga shared method o klase. KISS (Keep It Simple, Stupid) — ang pagiging simple ay mas mahalaga kaysa elegance. YAGNI (You Aren't Gonna Need It) — huwag magsulat ng code para sa isang bagay na maaaring hindi kailangan. Ang mga prinsipyong ito ay tumutulong sa pagsulat ng malinis, napapanatiling code nang walang redundancy.

Mga Pattern ng Platform ng Android

ViewModel (Android) ay isang bahagi ng arkitektura ng Jetpack para sa pag-iimbak ng UI state, lumalaban sa pag-ikot ng screen. Ang ViewModel ay walang mga reference sa Activity at awtomatikong nalilinis. LiveData — isang observable na lalagyan ng data na may kamalayan sa lifecycle. StateFlow — isang modernong kapalit para sa LiveData batay sa Kotlin Flow. SharedFlow — isang Hot Flow para sa isang beses na mga event (navigation, toast).

Data Binding at Two-Way Binding — mga mekanismo para sa pag-binding ng UI at data sa Android. Ang Data Binding ay nagdedeklara ng koneksyon sa XML; ang Two-Way Binding ay awtomatikong nag-a-update ng field sa ViewModel. Unidirectional Data Flow — isang prinsipyo kung saan ang data ay dumadaloy sa isang direksyon: State → UI → Event → State. Sa IT Sectr, ginagamit namin ang Unidirectional Data Flow sa lahat ng bagong proyekto — binabawasan nito ang bilang ng mga bug na dulot ng hindi inaasahang pagbabago ng estado.