Bonyolítsuk el azt, ami egyébként egyszerű. Ha kellően bonyolult, akkor tesztek nélkül úgyis lehetetlen lesz karbantartani. Ez indokolja a további bonyolítást a tesztelhetőség érdekében. Így legalább még 1 millió fejlesztőnek lesz munkája. Mekkora zsírság, hogy csurgatja az adatokat végig négy osztályon keresztül. Ha neadjisten nem működik, akkor debuggold ki, vazze, hogy melyik osztály (szinte megfigyelhetetlen) belső állapota csúszott szét! Nem is beszélve arról, hogy kell-e finalban zárni az UnicodeFile osztályt? Ha nem kell, akkor mégiscsak be van töltve a tartalma, oda az O(1) tárigény. Ha meg nincs betöltve a tartalma, akkor a végén be kéne zárni, de ez a példából pont kimaradt. Pozitívnak szánt példában ilyen hibát véteni durva. Vagy ez a cikk paródia?
Vagy ott van benne, hogy implementáld a trimmelést a Collection interfész szerint. 15 metódus van a Collection interfészen, amiből jelen esetben legalább a felét nem is használnánk. Tehát csinálunk egy rakat tesztelendő és karbantartandó kódot a "szépség" kedvéért. Vagy félig implementáljuk az interfészt, mondván, hogy a másik felét "tudjuk", hogy nem használjuk. Igen, ez a szép megoldás valóban.
És akkor a végén a futásidő. A max metódust a JIT inline-osíthatja, 8 bájtot olvas, és 4-et ír (várhatóan regiszterből regiszterbe, 3-4 ASM utasítással) és zéró szemetet hagy maga után. Mire a Max ojjektum kiszámolja, hogy öt, addig legalább három pointeren keresztüli metódushívás történik és a végén ki kell még ganézni a heapet (egy kb 24-32 bájt körüli ojjektuot tesz a heapre) is. Gratulálok.