Sniedziet piemērus par 'SOLID' principu pārkāpumiem standarta bibliotēkās.

Lielākajā daļā standarta Apple bibliotēku SOLID principi tiek ievēroti augstā līmenī. Tomēr ir piemēri, kur to piemērošana nav tik stingra vai ir izņēmumi:

• Vienas atbildības princips (SRP): Dažas UIKit vai Foundation klases veic vairākus nesasaistītus uzdevumus. Piemēram, UIViewController var būt atbildīgs ne tikai par skatu pārvaldību, bet arī par datu apstrādi, navigāciju un tā tālāk.
• Atvēršanas / slēgšanas princips (OCP): Dažreiz dažādu standarta klases funkcionalitātes paplašināšana prasa paša klases modifikāciju, nevis tās apakšklases izveidi vai protokola izmantošanu. Piemēram, ja ir nepieciešams pievienot jaunu funkcionalitāti esošajam UITableViewDataSource bez iespējas viegli aizstāt tā uzvedības daļu.
• Barbaras Liskov likums (LSP): Dažās klases hierarhijās, piemēram, žestu apstrādē (UIGestureRecognizer un tā apakšklasēs), ne vienmēr ir iespējams aizstāt bāzes klasi ar tās apakšklasi bez uzvedības izmaiņām programmā.
• Saskarnes sadalīšanas princips (ISP): Dažas standarta bibliotēku protokoli var saturēt pārāk daudz metožu, no kurām ne visas ir nepieciešamas visām to realizējošajām klasēm. Piemēram, UITableViewDelegate protokols satur daudz opciju metožu.
• Atkarību inversijas princips (DIP): Lai gan dependency injection aktīvi tiek izmantots mūsdienu iOS izstrādē, dažās vecākās bibliotēkās atkarības var būt stingri saistītas, kas apgrūtina testēšanu un komponentu nomaiņu.

Svarīgi atzīmēt, ka šie "pārkāpumi" bieži ir kompromisi, kas ir izraisīti ar izstrādes vēsturi, veiktspēju vai API vienkāršošanu lietošanas scenārijos. Lielākajā daļā gadījumu, gudrs lietotnes projektēšana virs standarta bibliotēkām ļauj ievērot SOLID principus.