Olio-ohjelmointi
Ongelmia

Tämä artikkeli tai sen osa on käännetty tai siihen on haettu tietoja muunkielisen Wikipedian artikkelista. 
Alkuperäinen artikkeli: en:Object-oriented programming
Olio-ohjelmointi ei eduistaan huolimatta ole täysin ongelmatonta. Siinä missä proseduraalisessa ohjelmassa yhdessä kohtaa esiintynyt virhe saattoi vaikuttaa vain paikallisesti, olio-ohjelmoinnissa virheet monistuvat välittömästi kaikkiin oliota käyttäviin tahoihin. Olio-ohjelmoinnissa hyvän suunnittelun ja automatisoidun yksikkötestauksen merkitys korostuu. Väärin käytettynä olioilla voi myös olla suorituskykyvaikutuksia. Koska jokainen olio rakennetaan aina kokonaisuudessaan tietokoneohjelman muistiin, suurten oliomäärien käsittely voi viedä huomattavasti muistia.
Olio-ohjelmoinnin perusfilosofian (eli ohjelmointiparadigman) opettelu vie myös usein aikaa. Perinteisestä proseduraalisesta ohjelmoinnista olio-ohjelmointiin siirtyminen on joskus vaikeaa jopa kokeneille ohjelmistosuunnittelijoille. Nykyisin olio-ohjelmointia opetetaan useilla eri koulutustasoilla ja sen peruskäsitteet hallitaan yleisesti ottaen paremmin kuin ennen. Tästä huolimatta moni ohjelma suunnitellaan näennäisesti olioilla, mutta käytännössä ne noudattavat aikaisempaa ohjelmointityyliä, johon tekijä on tottunut. Olio-ohjelmointi ei siis tee kenestäkään parempaa ohjelmoijaa eikä automaattisesti anna mitään etuja suhteessa perinteiseen ohjelmointiin, ellei olio-ohjelmoinnin etuja osata oikealla tavalla hyödyntää.
Luokkien periyttämisen heikkoutena on eri luokkien käytännön toteutuksen sitominen toisiinsa, mikä saattaa aiheuttaa ongelmia siinä vaiheessa kun ohjelmistosta tehdään uusia versioita. Näiden ongelmien ennalta ehkäisemiseksi on tehty suunnittelumalleja, jotka perustuvat hyväksi havaittuihin ratkaisuihin.
Luca Cardelli on väittänyt, että olio-ohjelmoitu koodi on "luonnostaan vähemmän tehokas" kuin proseduraalinen koodi, että olio-ohjelmoidun koodin kääntäminen voi kestää kauemmin ja että olio-ohjelmointikielillä on "erittäin huonot modulaarisuusominaisuudet luokan laajennuksen ja muokkauksen suhteen" ja että ne ovat yleensä erittäin monimutkaisia. Jälkimmäisen seikan toistaa Joe Armstrong, Erlangin pääkeksijä, jota lainataan sanomalla:
Olioperustaisten kielten ongelma on, että heillä on kaikki tämä implisiittinen ympäristö, jota he kuljettavat mukanaan. Halusit banaanin, mutta sait gorillan, joka piti banaania ja koko viidakkoa.
Potok et al.:n tutkimus ei ole osoittanut merkittävää eroa tuottavuudessa olio-ohjelmoinnin ja proseduraalisten menettelytapojen välillä.
Eräässä artikkelissa Lawrence Krubner väitti, että verrattuna muihin kieliin (LISP-murteet, funktionaaliset kielet jne.) olio-ohjelmointikielillä ei ole erityisiä vahvuuksia, ja niiden tarpeettomasta monimutkaisuudesta aiheutuu raskas taakka.
Paul Graham on ehdottanut, että olio-ohjelmoinnin suosio suurissa yrityksissä johtuu "suurista (ja usein muuttuvista) keskinkertaisten ohjelmoijien ryhmistä". Grahamin mukaan olio-ohjelmoinnin asettama kurinalaisuus estää yhtä ohjelmoijaa "tekemästä liikaa vahinkoa".
Clojure-ohjelmointikielen luoja Rich Hickey on kuvaillut oliojärjestelmiä liian yksinkertaisiksi todellisen maailman malleiksi. Hän korostaa olio-ohjelmoinnin kyvyttömyyttä mallintaa aikaa kunnolla, mikä on yhä ongelmallisempaa ohjelmistojärjestelmien samanaikaistuessa.
Unix-ohjelmoija ja avoimen lähdekoodin ohjelmistojen puolestapuhuja Eric S. Raymond on kritisoinut väitteitä, joiden mukaan olio-ohjelmointi esitetään "ainoana oikeana ratkaisuna", ja on kirjoittanut, että olio-ohjelmointikielet kannustavat yleensä paksukerroksisiin ohjelmiin, jotka tuhoavat läpinäkyvyyden. Raymondin mukaan tämä korostuu, kun olio-ohjelmointia verrataan Unixin ja C-ohjelmointikielen lähestymistapaan.
UTF-8 ja Go ohjelmisto projekteissa mukana ollut ohjelmoija Rob Pike, on kutsunut olio-ohjelmointia “tietojenkäsittelyn Roomalaisiksi numeroiksi” ja on sanonut, että olio-ohjelmoinnin kielet usein huomion datarakenteista ja algoritmeista tyyppeihin. Lisäksi hän mainitsee esimerkin Java professorista, jonka “käsittämätön” ratkaisu ongelmaan oli luoda kuusi uutta luokkaa sen sijaan että hän olisi yksinkertaisesti käyttänyt vain hakutaulua.
Perinnöllisyyden suhteen, Rob Martin toteaa, että koska kyseessä on tietokoneohjelmisto, sukulaisluokat eivät välttämättä jaa edustamiensa asioiden suhteita.