ISP — ano ito, prinsipyo ng paghihiwalay ng interface sa pag-develop

Ano ang ISP (Interface Segregation Principle)?

ISP (Interface Segregation Principle) — prinsipyo ng paghihiwalay ng interface na nagbabawal sa paglikha ng “matataba” na mga interface na may mga pamamaraan na hindi ginagamit ng lahat ng kliyente. Sa halip na isang interface na may sampung pamamaraan, idinidisenyo ang ilang maliliit na interface, bawat isa para sa sarili nitong grupo ng mga kliyente.

Ang prinsipyo ay ipinakilala ni Robert Martin bilang solusyon sa problema ng “pagkontamina ng interface”, kapag ang isang klase ay napipilitang magpatupad ng mga pamamaraan na hindi nito kailangan dahil lamang idineklara ang mga ito sa isang karaniwang interface. Sa mga wikang may static typing, ito ay nagreresulta sa mga walang laman na implementasyon o paghagis ng mga exception — isang direktang tanda ng paglabag sa ISP.

ISP at SRP ay nagpupuno sa isa't isa: ang SRP ay tungkol sa responsibilidad ng klase, ang ISP ay tungkol sa mga kontrata ng interface. Sinasabi ng SRP “isang klase — isang dahilan para magbago”, sinasabi ng ISP “isang interface — isang senaryo ng kliyente”. Sama-sama silang bumubuo ng modular na arkitektura kung saan ang bawat elemento ng sistema ay may malinaw na mga hangganan.

Mga matatabang interface at ang kanilang mga kahihinatnan

Fat Interface — isang interface na naglalaman ng mas maraming pamamaraan kaysa sa kailangan ng isang partikular na kliyente. Halimbawa, ang interface na Worker na may mga pamamaraang work, eat, sleep. Ang isang robot na manggagawa ay hindi dapat magpatupad ng eat at sleep, ngunit napipilitan. Solusyon — hatiin sa Workable, Eatable, Sleepable. Bawat kliyente ay nakakakuha ng eksaktong kailangan nito.

Sa mobile development, ang mga matatabang interface ay matatagpuan sa mga protokol ng delegate at DataSource. Ang isang protokol ay maaaring maglaman ng mga pamamaraan para sa dalawang magkaibang senaryo (pag-edit + pagpapakita), kahit na ang isang partikular na screen ay gumagamit lamang ng isa sa mga ito.

Paano gumagana ang prinsipyo ng paghihiwalay ng interface

Pagpapatupad ng ISP ay nagsisimula sa pagsusuri ng mga kliyente ng bawat interface. Kung ang dalawang kliyente ay gumagamit ng magkaibang set ng mga pamamaraan ng parehong interface — ang interface ay dapat hatiin. Ang bawat bagong interface ay naggrupo ng mga pamamaraan na tinatawag nang magkasama sa loob ng isang senaryo.

Mekanismo ng paghahati: ang orihinal na interface ay hinahati sa ilang makitid na interface, bawat isa ay nagmamana ng karaniwang bahagi (kung mayroon). Ang mga kliyente ay lumilipat sa pag-asa sa kinakailangang makitid na interface sa halip na sa pangkalahatan. Ang mga klase na nagpatupad ng orihinal na interface ay nagpapatupad na lamang ng mga makitid na interface na talagang kailangan nila.

Mahalagang paglilinaw: ang antas ng paghahati ay tinutukoy ng bilang ng mga kliyente at kanilang mga senaryo. Ang ISP ay hindi nangangailangan ng pinakamataas na paghahati (mga micro-interface na may isang pamamaraan). Ito ay hahantong sa labis na pagiging kumplikado. Ang layunin ay alisin ang pag-asa ng mga kliyente sa mga hindi kinakailangang pamamaraan, hindi mabawasan ang laki ng bawat interface.

Mga palatandaan ng paglabag sa ISP

Mga pangunahing palatandaan ng paglabag sa ISP ay kinabibilangan ng: mga klase na nagpapatupad ng interface na may mga walang laman na pamamaraan (fictitious na implementasyon), paghagis ng exception na UnsupportedOperationException sa mga implementasyon, malaking bilang ng mga parameter o return type na hindi ginagamit ng ilang kliyente, at madalas na pagbabago ng interface na nakakaapekto lamang sa ilang kliyente.

Sa Android development, isang tipikal na halimbawa ng paglabag sa ISP ay ang interface na OnItemClickListener na naglalaman ng mga pamamaraan para sa click, long click, at swipe. Kung ang isang partikular na screen ay gumagamit lamang ng click — ang natitirang mga pamamaraan ay nananatiling walang laman. Solusyon — hatiin sa OnItemClickListener, OnItemLongClickListener, OnItemSwipeListener.

Sa iOS development, ang paglabag sa ISP ay makikita sa mga delegate ng UIKit: isang protokol ay naglalaman ng mga pamamaraan para sa iba't ibang estado ng isang component. Ang UITableViewDelegate ay naglalaman ng mga pamamaraan para sa pagpapakita, pagpili, pag-edit, at mga swipe-action. Madalas na ipinapatupad ng mga developer ang buong protokol na may sampung walang laman na pamamaraan. Ang paghahati sa ilang protokol ayon sa mga grupo ng responsibilidad ay lumulutas ng problema.

Pag-asa sa mga hindi ginagamit na pamamaraan

Ang problema ay hindi lamang sa estetika ng code. Kapag nagbago ang interface (may idinagdag na bagong pamamaraan), lahat ng nagpapatupad na klase ay dapat i-update — kahit ang mga hindi nangangailangan ng bagong pamamaraan. Sa mobile development na may dose-dosenang screen, ito ay humahantong sa mga cascade na pagbabago. Inihihiwalay ng ISP ang bawat kliyente mula sa mga pagbabagong hindi nauugnay sa kanila.

Hindi direktang paglabag sa ISP ay nangyayari sa pamamagitan ng mga parameter ng configuration. Kung ang isang pamamaraan ay tumatanggap ng isang bagay na may malaking bilang ng mga field, habang ang kliyente ay gumagamit lamang ng 2-3 sa mga ito — ito ay isang senyales para sa paghahati. Alternatibo: ilang espesyalisadong pamamaraan na may pinakamababang set ng mga parameter.

Sa Android development, nilalabag ang ISP kapag gumagamit ng isang SharedPreferencesManager para sa pagbasa at pagsulat ng lahat ng setting ng app. Ang isang Fragment na kailangan lamang basahin ang tema ay nakakakuha ng pag-asa sa pandaigdigang manager na may dose-dosenang pamamaraan para sa iba't ibang uri ng data. Ang paghahati sa ThemePreferenceProvider, AuthPreferenceProvider, FeatureFlagProvider — paglalapat ng ISP sa antas ng mga serbisyo ng configuration. Bawat provider ay naglalaman ng eksaktong mga pamamaraan na kailangan ng mga kliyente nito.

Mga halimbawa ng ISP sa mga mobile app

Tingnan natin ang halimbawa ng Android na may interface para sa pagtatrabaho sa data. Paglabag sa ISP — isang interface para sa lahat ng operasyon ng CRUD, kahit na hindi lahat ng kliyente ay nangangailangan ng lahat ng operasyon.

// Paglabag sa ISP: matabang interface
interface UserRepository {
    fun getAll(): List<User>
    fun getById(id: Int): User
    fun save(user: User)
    fun delete(id: Int)
}

// Pagkatapos ng paglalapat ng ISP: makitid na mga interface
interface UserReader {
    fun getAll(): List<User>
    fun getById(id: Int): User
}

interface UserWriter {
    fun save(user: User)
    fun delete(id: Int)
}

// Ang ReadOnlyViewModel ay hindi umaasa sa mga pamamaraan ng pagsulat
class ReadOnlyViewModel(
    private val reader: UserReader
)

Halimbawa ng iOS na may paghahati ng mga protokol para sa pagtatrabaho sa media:

// Paglabag sa ISP: isang protokol para sa lahat ng trabaho sa media
protocol MediaService {
    func play(url: URL)
    func pause()
    func stop()
    func upload(data: Data) async -> URL
    func download(url: URL) async -> Data
}

// Pagkatapos ng ISP: paghahati sa mga protokol ayon sa responsibilidad
protocol MediaPlayer {
    func play(url: URL)
    func pause()
    func stop()
}

protocol MediaTransfer {
    func upload(data: Data) async -> URL
    func download(url: URL) async -> Data
}

// Ang PlayerViewModel ay hindi umaasa sa mga pamamaraan ng pagkarga
class PlayerViewModel {
    private let player: MediaPlayer
}

Praktikal na konklusyon: Pinoprotektahan ng ISP ang mga kliyente mula sa mga pagbabago sa mga bahagi ng interface na hindi nauugnay sa kanila. Ang paghahati ng UserRepository sa UserReader at UserWriter ay nangangahulugan na ang mga pagbabago sa save ay hindi nakakaapekto sa ReadOnlyViewModel at kabaliktaran. Bawat kliyente ay nakahiwalay mula sa functionality na hindi nito ginagamit at hindi nangangailangan ng mga pagbabago kapag ang ibang bahagi ng sistema ay pinahusay.

ISP at SOLID: kaugnayan sa iba pang mga prinsipyo

ISP at SRP — isang natural na pares. Tinutukoy ng SRP na ang isang klase ay dapat magkaroon ng isang dahilan para magbago. Inilalapat ng ISP ang parehong lohika sa mga interface: ang isang interface ay dapat magsilbi ng isang senaryo ng kliyente. Ang isang klase ay maaaring magpatupad ng ilang makitid na interface (bawat isa ay tumutugma sa isang responsibilidad), na mas malinis kaysa isang matabang interface na may maraming responsibilidad.

ISP at OCP ay nauugnay din: ang makitid na interface ay mas madaling palawakin. Ang pagdaragdag ng bagong pamamaraan sa isang makitid na interface ay nakakaapekto lamang sa mga kliyente nito. Ang pagdaragdag ng pamamaraan sa isang matabang interface ay nakakaapekto sa lahat ng kliyente — posibleng lumabag sa OCP, kung ang mga kliyente ay mapipilitang baguhin ang kanilang implementasyon.

ISP at DIP ay nagtutulungan: ang DIP ay nangangailangan ng pag-asa sa mga abstraction. Ginagawa ng ISP ang mga abstraction na ito na makitid at nakatuon. Ang pag-asa sa isang malawak na interface ay pag-asa pa rin sa abstraction, ngunit isang “masamang” abstraction mula sa pananaw ng ISP. Apat na prinsipyo (SRP, OCP, ISP, DIP) ay bumubuo ng “pyramid ng modularity”: ang SRP at ISP ay tumutukoy ng mga hangganan, ang OCP at DIP — mga paraan ng pagpapalawak at pag-uugnay.

Paglalapat ng ISP sa arkitektura ng component

Arkitektura ng component sa mga mobile project (mga module, feature, layer) ay nakikinabang mula sa ISP sa antas ng mga pampublikong API. Bawat module ay nag-e-export ng makitid na interface para sa mga consumer nito, hindi isang karaniwang facade. Ito ay nagpapahintulot sa pagbabago ng panloob na implementasyon ng module nang hindi naaapektuhan ang mga consumer na gumagamit lamang ng bahagi ng functionality nito.

Sa mga Android project na may Clean Architecture, ang ISP ay inilalapat sa UseCase: bawat UseCase ay isang hiwalay na interface na may isang pamamaraang invoke o execute. Ang kliyente (ViewModel) ay nakadepende lamang sa UseCase na kailangan nito, hindi sa buong repository. Ginagawa nitong transparent at nasusuri ang mga dependency.