Andke näiteid 'SOLID' põhimõtete rikkumistest standardraamatukogudes.

En suure osa Apple'i standardraamatukogudest järgitakse SOLID põhimõtteid kõrgel tasemel. Kuid leidub näiteid, kus nende rakendamine ei ole nii range või on erandeid:

• Ühe vastutuse põhimõte (SRP): Mõned UIKit või Foundation klassid täidavad mitmeid ühendamata ülesandeid. Näiteks võib UIViewController olla vastutav mitte ainult vaadete haldamise eest, vaid ka andmete töötlemise, navigatsiooni jms eest.
• Avatus/suletavus põhimõte (OCP): Mõnikord nõuab mõnede standardklasside funktsionaalsuse laiendamine klassi enda muutmist, mitte selle alamklassi loomist või protokolli kasutamist. Näiteks uue funktsionaalsuse lisamine olemasolevale UITableViewDataSource-le ilma, et oleks võimalik selle käitumist lihtsalt asendada.
• Liskovi asenduspõhimõte (LSP): Mõnedes klassi hierarhiates, näiteks žestide töötlemisel (UIGestureRecognizer ja selle alamklassid), ei ole alati võimalik baasklassiga asendada selle alamklassiga ilma käitumist muutmata.
• Liidese jagamise põhimõte (ISP): Mõned standardraamatukogude protokollid võivad sisaldada liiga palju meetodeid, millest kõik ei ole vajalikud kõigile nende rakendajatele. Näiteks UITableViewDelegate-il on palju valikulisi meetodeid.
• Sõltuvuse pööramise põhimõte (DIP): Kuigi sõltuvuse süstimine on kaasaegses iOS arendamises aktiivselt kasutusel, võivad vanemate raamatukogude sõltuvused olla rangelt seotud, mis raskendab testimist ja komponentide asendamist.

Oluline on märkida, et need "rikkumised" on sageli kompromissid, mis tulenevad arendusajaloost, jõudlusest või API lihtsustamisest kasutusstsenaariumites. Enamikul juhtudel võimaldab nutikas rakenduse projekteerimine standardraamatukogude peal järgida SOLID põhimõtteid.