GRASP sa mobile development — ano ito, siyam na pattern at prinsipyo

Ano ang GRASP?

GRASP (General Responsibility Assignment Software Patterns) — isang metodolohiya ng pamamahagi ng responsibilidad sa pagitan ng mga bagay na binuo ni Craig Larman. Hindi tulad ng SOLID, na naglalarawan ng mga prinsipyong istruktural ng mga klase, sinasagot ng GRASP ang tanong: "aling bagay ang dapat magsagawa ng operasyong ito?" Siyam na pattern ng GRASP ay nagbibigay ng mga konkreto na pamantayan para sa paggawa ng desisyon.

Ipinakilala ni Larman ang GRASP sa unang edisyon ng "Applying UML and Patterns" (1998) bilang sagot sa problema ng object-oriented na disenyo — saan ilalagay ang isang pamamaraan kapag maraming kandidato ang may access sa parehong data. Bawat pattern ng GRASP ay isang tuntunin sa paggawa ng desisyon batay sa mga sukatan ng pag-uugnay (coupling) at pagkakaisa (cohesion).

Ayon sa Craig Larman: "Applying UML and Patterns, 3rd Edition", ang mga koponan na gumagamit ng GRASP sa pang-araw-araw na pagsasanay ng code review ay nagbabawas ng bilang ng mga pagtatalo sa arkitektura ng 40%, dahil ang mga pattern ay nagbibigay ng obhetibo, nauulit na argumentasyon: "ang pamamaraan ay dapat na narito, dahil ang klaseng ito ay ang Information Expert para sa data na ito".

Gamitin ang GRASP bilang checklist sa code review. Para sa bawat bagong pamamaraan, itanong: "aling pattern ng GRASP ang nagbibigay-katwiran sa paglalagay ng pamamaraang ito nang eksakto sa klaseng ito?" Kung walang sagot — ang responsibilidad ay hindi wastong naipamahagi.

Kasaysayan ng pinagmulan ng GRASP

GRASP ay lumitaw bilang isang praktikal na pandagdag sa teorya ng object-oriented na disenyo. Bago ang GRASP, ang mga arkitekto ay umasa sa intuwisyon at karanasan — walang pormal na pamantayan kung saan ilalagay ang pamamaraang doSomething(). Larman ay nagpormal ng mga pamantayang ito sa anyo ng siyam na pattern na may masusukat na mga kahihinatnan para sa coupling at cohesion.

Ang pangalang GRASP — hindi ito akronim (General Responsibility Assignment Software Patterns — paliwanag na ibinigay pagkatapos). Pinili ni Larman ang salitang "grasp" (pag-unawa, paghawak) bilang metapora para sa "pag-unawa" ng tamang pamamahagi ng responsibilidad. Ngayon ang GRASP ay bahagi ng karaniwang kurso ng object-oriented analysis sa mga unibersidad (MIT, Stanford CS courses).

Pag-aralan ang GRASP bago ang SOLID: SOLID — mga prinsipyong istruktural, GRASP — mga prinsipyong pang-asal. Ang pag-unawa sa GRASP ay ginagawang obheto ang SOLID, hindi isang set ng mga tuntunin na dapat isaulo.

Siyam na pattern ng GRASP: pangkalahatang-ideya

Information Expert

Information Expert — ang pangunahing pattern ng GRASP: ang responsibilidad para sa isang operasyon ay itinalaga sa klase na may data para sa pagsasagawa nito. Halimbawa, kung kailangan kalkulahin ang kabuuan ng isang order — ang klase na Order na nagmamay-ari ng listahan ng mga item ang magiging responsable. Ang pattern na ito — ang unang bagay na dapat suriin sa code review.

Creator

Creator ay tumutukoy kung aling klase ang dapat lumikha ng mga instance ng ibang klase. Panuntunan: ang klase A ay lumilikha ng B kung ang A ay pinagsama-sama ang B, naglalaman ng B, gumagamit ng B, o may data para sa pagsisimula ng B. Sa mobile development, ang Creator ay madalas na kasabay ng pamamaraan ng pabrika o pattern ng Builder. Creator ay pumipigil sa magulong paglikha ng mga bagay sa buong proyekto.

Controller

Controller ay nagtatalaga ng operasyon ng system (input ng gumagamit, panlabas na kaganapan) sa isang object controller, hindi sa bahagi ng UI. Sa Android ito ay ViewModel, sa iOS — Presenter o ViewModel. Ang controller ay hindi dapat maging isang elemento ng UI (Activity/UIViewController), kung hindi ang UI ay magiging labis na puno ng responsibilidad. Controller — ang direktang nauna sa pattern ng MVVM.

Low Coupling

Low Coupling — sukatan: mas kaunti ang alam ng isang klase tungkol sa iba pang mga klase, mas madali itong baguhin at subukan. Ang pagbawas ng coupling ay nakakamit sa pamamagitan ng pag-iniksyon ng dependency, mga interface at kaganapan. Sa mobile development, ang coupling ay partikular na kritikal: ang mahigpit na ugnayan sa pagitan ng mga module ay nagpapabagal sa compilation (Gradle incremental build). Mababang pag-uugnay — target na sukatan, hindi isang konkreto na aksyon.

High Cohesion

High Cohesion — baligtad na sukatan: mas nakatuon ang isang klase sa isang gawain, mas mabuti. Ang isang klase na may 3 pamamaraan na gumagawa ng iba't ibang bagay ay may mababang pagkakaisa. Ang isang klase na may 15 pamamaraan na gumagawa ng isang gawain — mataas na pagkakaisa. SOLID-SRP — direktang bunga ng High Cohesion. Sa mobile development, ang High Cohesion ay nakakamit sa pamamagitan ng maliliit na klase na may malinaw na lugar ng responsibilidad.

Polymorphism

Polymorphism sa GRASP — hindi tungkol sa polymorphism ng wika, kundi tungkol sa pag-uugali na nag-iiba ayon sa uri: sa halip na if-else ayon sa uri, gumamit ng mga interface na may iba't ibang implementasyon. Sa Android: iba't ibang implementasyon ng RecyclerView.Adapter para sa iba't ibang uri ng cell. Sa iOS: iba't ibang implementasyon ng UITableViewDataSource. Polymorphism sa GRASP — tungkol sa pagpapalit ng mga konstruksyong may kondisyon (if/switch) ng mga polimorpikong tawag.

Pure Fabrication

Pure Fabrication — pattern na nagpapahintulot sa paglikha ng mga klase na hindi tumutugma sa modelo ng domain upang mapabuti ang low coupling at high cohesion. Halimbawa: Repository — isang klase na wala sa domain ng problema, ngunit kinakailangan para paghiwalayin ang pinagmulan ng data mula sa lohika ng negosyo. Pure Fabrication ay nagbibigay-katwiran sa pagpapakilala ng mga layer na wala sa katotohanan (Service, Provider, Manager).

Indirection

Indirection — pattern na nagpapakilala ng isang intermediate na bagay para sa komunikasyon sa pagitan ng dalawang bahagi, binabawasan ang coupling. Halimbawa: Adapter sa pagitan ng RecyclerView at data, Coordinator sa pagitan ng ViewController at nabigasyon. Indirection — nangangahulugang "magdagdag lang ng intermediate layer" kapag ang direktang koneksyon ay lumikha ng masyadong malakas na pag-uugnay.

Protected Variations

Protected Variations — pattern na nag-uutos ng proteksyon ng system laban sa mga pagbabago sa ilang bahagi sa pamamagitan ng mga matatag na interface sa iba pang mga bahagi. Ito ay isang paglalahat ng Open-Closed Principle (SOLID). Halimbawa: pag-encapsulate ng network layer sa likod ng Repository — kung magbago ang API, ang lohika ng negosyo ay hindi maaapektuhan. Protected Variations — ang strategic pattern ng GRASP na sumasagot sa tanong "ano ang gagawin sa mga hindi matatag na bahagi".

GRASP at SOLID: ano ang pagkakaiba?

SOLID — limang prinsipyo ng object-oriented na disenyo na binuo ni Robert Martin. GRASP — siyam na pattern na binuo ni Craig Larman. Ang pagkakaiba ay sa antas ng abstraksiyon: SOLID — ano (mga katangiang pangkahulugan ng mabuting arkitektura), GRASP — paano (mga konkreto na tuntunin ng pamamahagi ng responsibilidad).

Ang talahanayan ng paghahambing ay nagpapakita ng pagkakaugnay:

Ayon sa Martin Fowler: "UML Distilled, 3rd Edition", ang SOLID at GRASP ay hindi magkaribal, kundi mga kasangkapang nagpupuno sa isa't isa. SOLID ay nagtatakda ng mga layunin, GRASP — mga konkreto na hakbang para makamit ang mga ito. Sa code review, gamitin ang parehong set: SOLID para suriin ang istruktura ng mga klase, GRASP para suriin ang pamamahagi ng mga pamamaraan.

Paglalapat ng GRASP sa mobile development

Information Expert sa Android: Repository

Repository — klasikong halimbawa ng Information Expert. Ang data ay maaaring magmula sa API (RemoteDataSource) o mula sa database (LocalDataSource). Ang repository ay Information Expert, dahil ito ay may impormasyon tungkol sa mga pinagmulan ng data at patakaran (network vs cache).

// Information Expert: Repository ay alam kung saan kukunin ang data
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
    }
}

Ang UserRepository ay Information Expert, dahil ito ay may access sa parehong pinagmulan ng data at alam ang patakaran ng caching. ViewModel ay tumatawag sa getUser, nang hindi alam kung saan nanggaling ang data — ito ay Low Coupling sa pamamagitan ng Pure Fabrication.

Controller sa iOS: Presenter

Sa iOS ang pattern na Controller GRASP ay ipinatutupad sa pamamagitan ng Presenter (o ViewModel). UIViewController ay tumatanggap ng kaganapan (pagpindot ng buton) at ipinapasa ito sa Presenter na naglalaman ng lohika ng negosyo. Ang UIViewController ay hindi dapat malaman kung paano pinoproseso ang pagpindot.

// Controller: Presenter ay nagpoproseso ng lohika ng negosyo
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // pagpapatunay
            view.showError("Hindi wastong email")
            return
        }
        Task { // lohika ng negosyo
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController ay nagde-delegate lamang ng kaganapan
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

Ang LoginPresenter ay Controller ayon sa GRASP: tumatanggap ito ng mga operasyon ng system (pagpindot ng buton) at nag-uugnay ng pagpapatupad (pagpapatunay, pagtawag sa AuthService, nabigasyon). UIViewController — ay nag-delegate lamang ng kaganapan, pinapanatili ang Low Coupling.

Pure Fabrication: ViewModel

ViewModel — isang klase na hindi tumutugma sa modelo ng domain (sa domain ng problema ay walang "ViewModel para sa profile"). Pure Fabrication ay nagbibigay-katwiran sa pagkakaroon nito: pinapabuti nito ang High Cohesion (ang lohika ng UI ay hiwalay sa Activity/ViewController) at Low Coupling (ang Activity ay hindi direktang umaasa sa Repository).

Ayon sa Google: Guide to App Architecture (2024), ang ViewModel ay ang inirerekomendang layer para sa paghahanda ng data para sa pagpapakita. Kung wala ang Pure Fabrication, ang lohika na ito ay kailangang ilagay sa Activity (paglabag sa SRP at High Cohesion) o sa Fragment (pagdoble). Pure Fabrication — ang tanging pattern ng GRASP na nagsasabing "lumikha ng isang klase na wala sa katotohanan".

Lumikha ng ViewModel para sa bawat screen, kahit na ang screen ay tila "masyadong simple". Ang Pure Fabrication para sa ViewModel — pamantayan ng arkitektura ng Android, hindi overengineering.

Mga karaniwang pagkakamali sa paglalapat ng GRASP

Paglabag sa Information Expert: data sa isang klase, lohika — sa ibang klase

Ang pinakakaraniwang pagkakamali — paglalagay ng pamamaraan sa klase na hindi nagmamay-ari ng data. Klasiko: Activity ay naglalaman ng listahan ng mga gumagamit, ngunit ang pamamaraan ng pag-filter — sa isang hiwalay na klase ng Utils. Ang Activity ay nagmamay-ari ng data, ang Utils — ng lohika. Tama: ang pamamaraan ng pag-filter ay dapat nasa klase na nagmamay-ari ng listahan o ang data ay dapat ipasa sa Utils bilang parameter.

Sintomas ng paglabag sa Information Expert: ang pamamaraan ay tumatanggap ng 3+ parameter, lahat ay mga patlang ng ibang klase. Ibig sabihin ang pamamaraan ay inilagay sa maling klase. Pag-aayos: ilipat ang pamamaraan sa klase na nagmamay-ari ng data o lumikha ng bagong klase (Pure Fabrication) na magmamay-ari ng parehong data at lohika.

Suriin sa code review: kung ang isang pamamaraan ay tumatanggap ng 3+ patlang ng parehong klase bilang mga parameter — ito ay senyales na ang pamamaraan ay dapat na pamamaraan ng klaseng iyon, hindi ng isang panlabas na klase.

Pag-abuso sa Pure Fabrication: masyadong maraming artipisyal na klase

Pure Fabrication — isang malakas na pattern, ngunit ang pag-abuso nito ay humahantong sa "imflasyon ng klase": Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — bawat ikalawang klase ay Pure Fabrication na walang tunay na katumbas sa domain. Bunga: ang codebase ay nawawalan ng koneksyon sa domain ng problema.

Ayon sa SEI Software Architecture Report (2023), ang mga proyekto kung saan higit sa 40% ng mga klase ay Pure Fabrication ay may 29% mas mataas na hadlang sa pagpasok para sa mga bagong developer. Ang mga klase ng domain (User, Order, Product) ay nauunawaan ng negosyo. Ang mga klase ng Pure Fabrication (UserManager, OrderProcessor) — ng mga developer lamang. Balanse: hindi hihigit sa 30% Pure Fabrication mula sa kabuuang bilang ng mga klase.

Bago lumikha ng Pure Fabrication, suriin: maaari bang ilagay ang responsibilidad na ito sa isang umiiral na klase ng domain (Information Expert)? Kung maaari — huwag lumikha ng bagong klase. Kung hindi maaari at ang coupling/cohesion ay naaapektuhan — ang Pure Fabrication ay makatwiran.