A számítógépes programozásban az abstract inversion egy anti-pattern melyet akkor valósítanak meg, ha az építő userek olyan funkcionalitast valósítanak meg benne melyet nem mutattak be az interface-nek. Ennek az eredménye az, hogy az userek ujra implementálják a szükséges funkcionalitást az interface „nevében” amely így egy belső megvalósításává válik ugyanannak a már meglévő funkciónak.
A „abstarct inversion” kifejezést gyakran félreértelmezik azzal, hogy komplex (vagy konkrét) szerkezettel hivatkoznak egyszerű (vagy absztrakt) interface-ekkel, melyek normálisak és elvártak.

Lehetséges tünetek

•    Egy újra implementált funkciónak a felhasználója komolyan alulbecsüli annak a futási költségeit.
•     Az építő userek kényszerítve vannak, hogy elfedjék az implementációjuk komplex mechanikai részletekkel.
•    Több user próbálja megoldani ugyanazt a problémát ezzel növelve a hiba valószínűségét

Abstraction inversion a gyakorlatban

Lehetőségek, ahogy elker��lhetjük ezt az anti-pattern-t:
Alacsony szintű software tervezőknek:
•    Ha a rendszer felajánl formálisan azonos funkciókat, akkor óvatosan kell megválasztani, hogy melyiket valósítsuk meg a másikkal kapcsolatban
•    Ne erőltessünk rá szükségtelenül gyenge szerkezeteket a felhasználóra
Magas szintű software fejlesztőknek:
•    Az infrastruktúrát kellé gonddal kell kiválasztani.

Példák

Néhány állítólagos példák professzionális programozói körökből:
•    Olyan objektum létrehozása mely reprezentál egy funkciót mely ormótlan az OO nyelvekben, mint Java vagy C++, olyan funkciókban melyek nem első osztályú objektumok. C++ban lehetséges egy objektumot meghívhatónak definiálni azzal, hogy túlterheljük a () operatort, de meg így is gyakran szükséges egy új osztályt implementálni, mint a Functor az STL-ben.
•    Tom Lord mondta azt, hogy a subversion verzió követő rendszer megfizeti, az árát az abstraction inversion-nak mivel egy read-only adatbázist implementál egy read/write adatbázison,  gyenge hatásfokkal.