SoC sa mobile development: ano ito, mga prinsipyo at paghihiwalay ng responsibilidad

Ano ang ibig sabihin ng acronym na SoC

SoC ay nangangahulugang Separation of Concerns — "paghihiwalay ng responsibilidad" o "paghihiwalay ng mga lugar ng interes". Sa konteksto ng programming, ang terminong concern ay tumutukoy sa anumang mapaghihiwalay na functionality: pagpapakita ng user interface, pagproseso ng mga click, pag-validate ng data, network communication, o pagtatrabaho sa database. Ang prinsipyong SoC ay nag-uutos ng pag-grupo ng code sa paligid ng mga lugar na ito upang ang mga pagbabago sa isa ay hindi makaapekto sa iba.

Ang acronym na SoC ay malawakang ginagamit sa teknikal na literatura, mga talakayan ng arkitektura, at dokumentasyon ng mga framework. Halimbawa, sa dokumentasyon ng Android Architecture Components, ang SoC ay binabanggit nang paulit-ulit bilang motibasyon para sa paghihiwalay ng ViewModel at View. Sa iOS community, ang termino ay ginagamit kapag tinatalakay ang problema ng Massive View Controller — direktang resulta ng kawalan ng SoC.

Mahalagang maunawaan na ang SoC ay hindi isang beses na aksyon, kundi isang patuloy na proseso. Habang lumalaki ang application, lumilitaw ang mga bagong lugar ng responsibilidad at ang arkitektura ay kailangang suriin muli. Ang isang mahusay na codebase ay dumadaan sa ilang mga pag-ulit ng paghahati bago maabot ang isang matatag na estado kung saan ang bawat concern ay nakahiwalay at napapamahalaan.

SoC vs Separation of Concerns

Separation of Concerns at ang acronym nito na SoC ay tumutukoy sa parehong prinsipyo. Ang pagkakaiba ay nasa konteksto lamang ng paggamit: ang buong pangalan ay ginagamit sa mga pormal na dokumento, mga materyal na pang-edukasyon, at sa unang pagpapaliwanag ng konsepto sa mga bagong developer. Ang SoC ay maginhawa sa mga teknikal na talakayan, code review, at dokumentasyon kung saan mahalaga ang pagiging maikli.

Sa propesyonal na kapaligiran, ang parehong termino ay maaaring palitan. Maaaring sabihin ng isang developer na "dito nilabag ang SoC" o "ito ay lumalabag sa Separation of Concerns" — hindi nagbabago ang kahulugan. Gayunpaman, sa mga job posting at mga kinakailangan sa arkitektura, mas madalas lumilitaw ang buong pangalan, habang sa mga chat at code review — ang acronym. Ang kaalaman sa parehong variant ay kinakailangan para sa komportableng pagpasok sa industriya.

Mayroong terminological confusion: ang acronym na SoC ay ginagamit din sa hardware context para sa System-on-a-Chip (system sa isang chip). Sa mobile development, ang konteksto ay palaging malinaw mula sa kapaligiran — kung ang talakayan ay tungkol sa arkitektura ng code, ito ay tumutukoy sa Separation of Concerns. Sa artikulong ito, ang SoC sa lahat ng dako ay tumutukoy sa prinsipyo ng paghihiwalay ng responsibilidad.

Paano inilalapat ang SoC sa mobile architecture

Three-layer architecture — ang pinakakaraniwang paraan ng pagpapatupad ng SoC sa mga mobile application. Hinahati nito ang code sa Presentation (UI), Domain (business logic), at Data (pagtatrabaho sa mga source). Ang bawat layer ay naglalaman ng mahigpit na tinukoy na mga uri ng klase at nakahiwalay mula sa mga kapitbahay sa pamamagitan ng mga interface. Ang diskarte na ito ay parehong epektibo para sa iOS, Android, at Flutter projects.

Presentation layer at ViewModel

View at ViewModel ay bumubuo ng presentation layer. Ang View ay responsable para sa pag-render ng interface at pagpapadala ng mga kaganapan ng user. Ang ViewModel ay nag-iimbak ng estado ng screen at nagko-convert ng data mula sa Domain layer sa format na handa para sa pagpapakita. Ang ViewModel ay walang mga reference sa Activity, Fragment, o UIViewController — tinitiyak nito ang SoC sa pagitan ng UI at logic.

Halimbawa, sa Android Jetpack, ang ViewModel ay nabubuhay sa pag-ikot ng screen habang ang UI ay muling nilikha. Kung walang SoC, kailangan naming i-save ang estado sa Activity, na pinaghahalo ang pamamahala ng lifecycle sa data. Nilulutas ng ViewModel ang gawaing ito nang hiwalay, na nagpapakita ng dalisay na pagpapatupad ng prinsipyo ng paghihiwalay ng responsibilidad.

Domain layer at Use Cases

Use Cases ay naglalaman ng mga patakaran ng negosyo na independyente sa platform. Ang layer na ito ay hindi nag-i-import ng Android SDK, iOS UIKit, o Flutter framework. Ang Use Case ay tumatanggap ng data mula sa Repository, naglalapat ng business logic dito, at nagbabalik ng resulta. Dahil sa SoC, ang isang Use Case ay maaaring magamit muli sa iba't ibang mga screen at platform.

Isang klasikong halimbawa — ValidateAndSaveUseCase para sa form ng pagpaparehistro. Sinusuri nito ang kawastuhan ng email at password, tinatawagan ang UserRepository para i-save, at nagbabalik ng ValidationResult. Ni ang UI o ang database ay hindi alam ang mga patakaran ng pag-validate — sila ay nakatuon sa isang lugar, na nagpapadali sa kanilang pagbabago.

Data layer at Repository

Repository ay nag-abstrak ng mga source ng data mula sa iba pang bahagi ng application. Hindi alam ng ViewModel kung saan nanggagaling ang data — REST API, GraphQL, lokal na database, o cache. Nagpapasya ang Repository kung aling source ang gagamitin at itinatago ang lohika na ito sa likod ng isang interface. Ito ang SoC sa pagitan ng pagkuha ng data at pagkonsumo nito.

Ang DataSource ay nagbibigay ng mas malalim na paghihiwalay: ang RemoteDataSource ay responsable lamang para sa mga HTTP request, ang LocalDataSource — para sa pagtatrabaho sa Room, CoreData, o SharedPreferences. Pinagsasama sila ng Repository na naglalapat ng mga caching strategy. Ang bawat DataSource ay maaaring palitan nang nakapag-iisa, na kritikal sa paglipat sa pagitan ng mga server o database.

Ang ganitong multi-level na DataSource system ay nagpapatupad ng SoC sa antas ng imprastraktura: network communication, lokal na storage, at caching — magkakahiwalay na concerns, bawat isa ay may sariling lohika at lifecycle. Kapag pinapalitan ang HTTP client, tanging ang RemoteDataSource ang nagbabago, habang ang Repository at mas matataas na layer ay nananatiling hindi nagagalaw, na nagpapatunay sa praktikal na halaga ng paghihiwalay ng responsibilidad.

SoC sa mga pattern ng arkitektura

MVP (Model-View-Presenter) — isa sa mga unang pattern na tahasang nagpapatupad ng SoC sa mobile development. Ang Presenter ay naglalaman ng logic at namamahala sa View sa pamamagitan ng isang interface. Ang View ay pasibo — ipinapakita lamang nito ang sinasabi ng Presenter. Ang paghihiwalay ay nagpapasimple ng pag-test: ang Presenter ay sinusuri nang walang emulator, at ang View ay nananatiling napakasimple na walang masisira.

MVVM ay nagdagdag ng reactive binding: ang View ay nag-subscribe sa mga pagbabago sa ViewModel sa pamamagitan ng Observable o StateFlow. Ang ViewModel ay hindi nag-iimbak ng reference sa View, na nag-aalis ng panganib ng memory leak at mas malakas na naghihiwalay ng concerns. Sa Android, ang MVVM ay naging pamantayan salamat sa Jetpack ViewModel at LiveData, sa iOS — salamat sa Combine at RxSwift.

Clean Architecture ni Robert Martin ay nagdadala ng SoC sa radikal na paghahati sa mga bilog. Ang panlabas na bilog (frameworks at drivers) ay nakadepende sa panloob na bilog (entities), ngunit hindi ang kabaligtaran. Sa praktika, ang mga mobile project ay bihirang nagpapatupad ng lahat ng apat na bilog — ang Domain at Data layers sa paligid ng Presentation ay sapat na. Ngunit ang prinsipyo ng dependency "papasok" ay nagbibigay ng makabuluhang mga pakinabang kapag nagpapalit ng frameworks.

// View — tanging pagpapakita, walang logic
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — naglalaman ng screen logic, hindi alam ang UIKit
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — business logic, hindi nakadepende sa platform
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

Ang halimbawa ay nagpapakita ng tatlong antas ng SoC: ang LoginViewController ay nagpapadala lamang ng mga kaganapan, ang LoginViewModel ay namamahala ng estado, ang LoginUseCase ay naglalaman ng mga patakaran ng negosyo. Ang bawat klase ay sinusuri nang nakapag-iisa, at ang pagpapalit ng UI framework ay hindi nakakaapekto sa Use Case.

Mga karaniwang paglabag sa SoC sa mga mobile project

Massive View Controller — ang pinakakaraniwang paglabag sa SoC sa iOS. Isang klase na namamahala sa UI, nagpoproseso ng mga network request, nagpa-parse ng JSON, at nag-iimbak ng data, lumalabag sa prinsipyo sa lahat ng antas. Solusyon — i-extract ang bawat responsibilidad sa isang hiwalay na component: NetworkingService, JSONParser, CoreDataStack, iiwan lamang sa ViewController ang pamamahala ng View.

Sa Android, may katulad na problema — God Activity o God Fragment. Isang aktibidad na naglo-load ng data, nagba-validate ng mga form, nagpapakita ng mga dialog, at nag-a-update ng UI. Ginagamot sa pamamagitan ng pagpapakilala ng ViewModel at Repository, na pumapalit sa pamamahala ng estado at data. Pinoprotektahan din ng ViewModel laban sa pagkawala ng data sa pag-ikot ng screen.

Ang ikatlong paglabag — paghahalo ng platform at business code. Halimbawa, paglalagay ng HTTP request nang direkta sa SwiftUI View o Android Composable. Ginagawa nitong hindi portable at mahirap subukan ang code. Tamang diskarte — i-extract ang request sa Repository na tinatawag sa pamamagitan ng Use Case, at ang View ay nag-subscribe lamang sa resulta. Ang bawat elemento ng system ay lumulutas ng sarili nitong gawain at hindi lumalampas sa mga hangganan nito.