Cohesion (Pagkakaisa) sa Mobile Development: Mga Batayan, Antas at Paano Pagbutihin

Ano ang Cohesion

Cohesion (pagkakaisa) — metrik na sinusuri kung gaano lohikal na magkakaugnay ang mga metodo, field at katangian sa loob ng isang klase o modyul. Ang isang modyul na may mataas na pagkakaisa ay gumagawa ng isang gawain at naglalaman lamang ng mga elementong kailangan para sa pagpapatupad nito. Ang isang modyul na may mababang pagkakaisa ay sumusubok na gumawa ng maraming bagay nang sabay-sabay — ang mga metodo ay mahina ang pagkakaugnay sa kahulugan.

Sa konteksto ng object-oriented programming, ang cohesion ay malapit na nauugnay sa Single Responsibility Principle (S). Kung ang isang klase ay may isang malinaw na responsibilidad, ang cohesion nito ay karaniwang mataas. Kung ang isang klase ay humahawak ng UI, lohika ng negosyo at komunikasyon sa network — ang cohesion ay mababa at ang naturang klase ay dapat hatiin sa maraming magkakahiwalay na klase na may mas makitid na responsibilidad.

Ang pag-unawa sa cohesion ay tumutulong sa developer na gumawa ng mga desisyon tungkol sa refactoring. Kapag nakita mo na sa isang klase ay may metodo na hindi gumagamit ng mga field ng klase, ito ay senyales ng mababang pagkakaisa. Ang naturang metodo ay maaaring hindi kailangan sa klase, o ang klase ay hindi maayos na dinisenyo. Ang pagsusumikap para sa mataas na pagkakaisa — ay patuloy na trabaho sa pagpapabuti ng arkitektura sa bawat antas ng code.

Mga Uri at Antas ng Pagkakaisa

Sa software engineering mayroong pitong antas ng cohesion, na nakaayos mula sa pinakamasama hanggang sa pinakamahusay. Ang pag-unawa sa iskalang ito ay nagbibigay-daan sa obhetibong pagtatasa ng kalidad ng modyul at pagtukoy kung saang direksyon gagalaw sa refactoring. Kung mas mataas ang antas, mas magiging maintainable at mauunawaan ang code.

Mababang pagkakaisa: nagkataon, lohikal at temporal

Nagkataon (coincidental) — pinakamasamang antas, kapag ang mga elemento sa modyul ay pinagsama-sama nang nagkataon, walang anumang lohikal na koneksyon. Halimbawa: klase ng Utilities, kung saan pinagsama ang mga metodo para sa pag-format ng petsa, pagpapadala ng email at pagkalkula ng diskwento. Ang naturang klase ay hindi mauunawaan nang hindi binabasa ang lahat ng metodo, at ang pagbabago ng isang metodo ay maaaring sirain ang iba dahil lang magkatabi sila.

Lohikal (logical) pagkakaisa — ang mga elemento ay gumaganap ng mga lohikal na nauugnay ngunit magkakaibang mga gawain. Ang isang klase na may mga metodo parseJSON, parseXML at parseCSV ay lohikal na nauugnay sa paksang „parsing”, ngunit ang bawat metodo ay gumagawa ng fundamentally ibang trabaho. Problema: sa pagdagdag ng bagong format (YAML), lumalaki ang klase at nagiging bloated ang interface nito.

Temporal (temporal) pagkakaisa — ang mga elemento ay pinagsama ayon sa oras ng pagpapatupad. Ang klase AppInitializer, na nag-configure ng database, nag-load ng config, nag-initialize ng analytics — lahat ito ay nangyayari sa pagsisimula ng application, ngunit ang mga gawain mismo ay hindi nauugnay. Mas mainam na hatiin ang mga ito sa magkakahiwalay na Initializer para sa bawat lugar ng responsibilidad.

Katamtamang pagkakaisa: prosidyural at komunikasyonal

Prosidyural (procedural) pagkakaisa ay lumilitaw kapag ang mga elemento ay pinagsama ng pagkakasunod-sunod ng pagpapatupad. Ang modyul na „Pagproseso ng Order” ay naglalaman ng mga metodo validateCart, processPayment, sendConfirmation — bawat metodo ay tinatawag nang mahigpit pagkatapos ng nauna. Ito ay mas mahusay kaysa sa nagkataon o lohikal na pagkakaisa, ngunit hindi pa rin perpekto: bawat hakbang ay maaaring i-extract sa magkahiwalay na modyul.

Komunikasyonal (communicational) pagkakaisa — ang mga elemento ay gumagawa sa parehong data. Ang klase UserService na may mga metodo getUser, updateUser, deleteUser ay pinag-isa ng karaniwang entidad na User. Ito ay mas mahusay kaysa sa prosidyural na pagkakaisa: ang klase ay may malinaw na domain. Karamihan sa mga klase ng Repository sa mga mobile project ay may komunikasyonal na pagkakaisa.

Mataas na pagkakaisa: functional

Functional (functional) pagkakaisa — pinakamataas na antas, kapag ang bawat elemento ng modyul ay lumalahok sa pagpapatupad ng isang gawain. Ang klase PasswordValidator na may nag-iisang metodo validate, na sumusuri sa haba, pagkakaroon ng mga character at pagiging kumplikado ng password — halimbawa ng functional na pagkakaisa. Kung ang naturang klase ay magbabago, ito ay dahil lang nagbago ang mga patakaran sa pag-validate ng password.

Ang pagkamit ng functional na pagkakaisa — pangunahing layunin ng arkitektural na refactoring. Bawat klase ay dapat magkaroon ng eksaktong isang dahilan para magbago. Sa mobile development, ang functional na pagkakaisa ay nakakamit sa pamamagitan ng paghihiwalay ng mga Use Case, custom View, formatter at validator. Bawat naturang klase ay kumpletong bloke ng gusali na may malinaw na lugar ng responsibilidad.

Cohesion vs Coupling

Cohesion at coupling — dalawang panig ng parehong kalidad. Kung mas mataas ang cohesion sa loob ng modyul, karaniwang mas mababa ang coupling sa pagitan ng mga modyul. Ang isang maayos na dinisenyong sistema ay sabay-sabay na nagsusumikap para sa mataas na pagkakaisa sa loob at mahinang pagkakaugnay sa labas. Ang patakarang ito ay itinuturing na pundamental sa software engineering mula noong 1970s.

Ang relasyon ng cohesion-coupling ay maaaring ituring bilang balanse. Kung isasakripisyo ng developer ang cohesion sa pamamagitan ng pagsasama ng maraming gawain sa isang klase, ang mga kalapit na modyul ay makakakuha ng mas maraming dependencies — kailangan nilang sumangguni sa overloaded na klase para sa iba’t ibang layunin, na nagpapataas ng coupling. At kabaligtaran, ang paghahati sa maliliit na may mataas na pagkakaisa na mga klase ay nagbabawas ng bilang ng mga punto ng interaksyon sa pagitan ng mga modyul.

Sa praktika ito ay nangangahulugan: kapag nag-extract ka ng bagong klase na may functional na pagkakaisa, sabay-sabay mong pinalalaya ang ibang modyul mula sa pangangailangang malaman ang mga detalye ng implementasyon nito. Halimbawa, sa pag-extract ng EncryptionManager sa isang hiwalay na klase na may functional na pagkakaisa, nagbibigay ka sa ibang modyul ng simpleng interface encrypt/decrypt nang hindi nila kailangang maintindihan ang mga detalye ng algorithm ng encryption.

// Mababang pagkakaisa — ginagawa ng klase ang lahat nang sabay-sabay
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// Mataas na pagkakaisa — bawat klase ay lumulutas ng isang gawain
class UserRepository {
    fun fetchUser(id: String): User { }
}

class UserJsonParser {
    fun parse(json: String): User { }
}

class UserNameFormatter {
    fun format(user: User): String { }
}

class EmailValidator {
    fun isValid(email: String): Boolean { }
}

Ang halimbawa ay nagpapakita ng pagkakaiba: ang UserManager ay may lohikal na pagkakaisa — lahat ng metodo ay tungkol sa mga user, ngunit bawat isa ay gumagawa ng fundamentally ibang trabaho. Pagkatapos ng refactoring, bawat klase ay may functional na pagkakaisa, at bumababa ang coupling dahil ang ibang modyul ay umaasa lamang sa klase na kailangan nila, hindi sa buong UserManager.

Paano Sukatin ang Pagkakaisa sa Code

LCOM (Lack of Cohesion of Methods) — pinakakilalang metrik para sa pagsukat ng pagkakaisa ng klase. Binibilang ng LCOM kung ilang pares ng metodo ang hindi gumagamit ng mga karaniwang field. Ang halagang 0 ay nangangahulugang perpektong pagkakaisa (lahat ng metodo ay gumagawa sa parehong field), mataas na halaga — mababang pagkakaisa. Ang LCOM4 (pinahusay na bersyon) ay isinasaalang-alang ang mga transitibong koneksyon sa pamamagitan ng ibang metodo.

Sa pag-develop ng Android, ang mga metrik ng pagkakaisa ay maaaring makuha sa pamamagitan ng Detekt na may panuntunang TooManyFunctions. Ang mga klase na may dose-dosenang metodo na gumagamit ng iba’t ibang grupo ng field ay malamang na may mababang pagkakaisa. Sa iOS, ang SwiftLint ay may mga panuntunang file_length at function_body_length — hindi direktang indicator: ang mahahabang file at metodo ay madalas na nagpapahiwatig ng mababang cohesion.

Manu-manong paraan ng pagtatasa: itanong „Magbabago ba ang klase na ito dahil sa isang dahilan o maraming dahilan?” Kung maaari kang magbanggit ng higit sa isang independiyenteng dahilan — ang klase ay may mababang pagkakaisa. Pangalawang test: „Maaari bang hatiin ang klase na ito sa dalawang independiyenteng klase?” Kung oo — gawin ito. Ang regular na pagsusuri ng cohesion sa code review ay pumipigil sa paglitaw ng mga God class at nagbabawas ng technical debt.

Paano Pagbutihin ang Cohesion sa Mobile Project

Unang hakbang — ilapat ang Single Responsibility Principle. Bawat klase ay dapat magkaroon ng isang malinaw na responsibilidad. Kung sa isang klase ay may metodo na hindi kabilang sa pangunahing gawain nito, i-extract ito sa magkahiwalay na klase. Ang teknik na Extract Class o Extract Delegate sa IDE ay nag-automate ng prosesong ito. Pagkatapos ng extraction, suriin kung ang orihinal na klase ay naging mas nakatutok.

Ikalawang hakbang — gamitin ang pattern na Facade para pasimplehin ang interface. Kung ang isang klase ay nagbibigay ng 20 metodo, kung saan ang mga kliyente ay gumagamit lamang ng 3-4, marahil ang klase ay may mababang pagkakaisa — nag-aalok ito ng masyadong maraming iba’t ibang functionality. I-grupo ang mga metodo ayon sa paksa at mag-extract ng magkakahiwalay na klase para sa bawat grupo, at gawing facade ang orihinal na klase o tanggalin ito.

Ikatlong hakbang — pansinin ang mga grupo ng field. Kung ang isang klase ay may mga field na ginagamit lamang ng bahagi ng mga metodo — ito ay indicator ng mababang cohesion. Hatiin ang klase ayon sa mga grupo ng field. Halimbawa, kung ang klase ay naglalaman ng mga field na userRepository, networkClient at analyticsTracker, ngunit ang mga metodo ng unang grupo ay gumagamit lamang ng userRepository, at ang pangalawa — networkClient — ito ay dalawang magkaibang klase.

Ikaapat na hakbang — iwasan ang paggawa ng mga “utility” na klase na may mga arbitraryong static na metodo. Bawat static na metodo na nasa klase ng Utils o Helpers ay kandidato para i-extract sa isang specialized na klase. Ang FormatUtils.dateToString ay mas mainam na ilipat sa DateFormatter, at ang ValidationUtils.isValidEmail — sa EmailValidator. Ito ay nagpapataas ng cohesion ng bawat klase at ginagawang self-documenting ang code.