Pateikite pavyzdžių, kaip pažeidžiami 'SOLID' principai standartinėse bibliotekose.

Daugelyje standartinių Apple bibliotekų SOLID principai yra laikomasi aukštu lygiu. Tačiau galima rasti pavyzdžių, kur jų taikymas nėra toks griežtas arba yra išimčių:

• Vienos atsakomybės principas (SRP): Kai kurie UIKit ar Foundation klasės atlieka kelis nesusijusius uždavinius. Pavyzdžiui, UIViewController gali būti atsakingas ne tik už vaizdų valdymą, bet ir už duomenų apdorojimą, navigaciją ir kt.
• Atvirumo / uždarymo principas (OCP): Kai kurių standartinių klasių funkcionalumo plėtra kartais reikalauja paties klases modifikavimo, o ne jos pogrupio kūrimo ar protokolo naudojimo. Pavyzdžiui, pridėti naują funkcionalumą prie esamo UITableViewDataSource be galimybės lengvai pakeisti jo elgesio dalį.
• Barbaros Liskov įstatymo (LSP): Kai kuriose klasių hierarchijose, pavyzdžiui, gestų apdorojime (UIGestureRecognizer ir jo pogrupiuose), ne visada galima pakeisti bazinį klasę jos pogrupiu be elgesio pakeitimo programoje.
• Sąsajos padalijimo principas (ISP): Kai kurios standartinių bibliotekų protokolai gali turėti per daug metodų, kurių ne visi reikalingi visoms jų įgyvendinančioms klasėms. Pavyzdžiui, UITableViewDelegate, kuris turi daug pasirinktinų metodų.
• Priklausomybės inversijos principas (DIP): Nors dependency injection aktyviai naudojamas šiuolaikiniame iOS programavime, kai kuriose senesnėse bibliotekose priklausomybės gali būti griežtai susietos, kas apsunkina testavimą ir komponentų keitimą.

Svarbu pažymėti, kad šie "pažeidimai" dažnai yra kompromisai, kuriuos lemia programavimo istorija, našumas arba API supaprastinimas naudojimo scenarijuose. Daugeliu atvejų, protingas programėlės projektavimas virš standartinių bibliotekų leidžia laikytis SOLID principų.