Nincs probléma a hasonló funkcionalitást megvalósító csomagokkal, de nem szeretnénk 10 sablon osztályt, 7 különböző levelezéssel kapcsolatos osztályt és 3 különböző adatbázisréteget, amelyek ugyanazt végzik, csak más függvénynevekkel.

Először végezzünk egy valóságtesztet: Miért szeretnénk a csomagot viszontlátni a PEAR-ben? Az igazán rossz válaszok: "Hogy viszontlássam a nevem a PEAR-ben" vagy "Nem értettem meg az API-ját egy létező osztálynak".

Egy új osztályra jó indok ha hiányzik egy függvény, viselkedés, vagy nem megfelelő a sebesség egy létező implementációban. Ebben az esetben meg kell vizsgálni az adott osztályt, hogy lehetséges-e kibővíteni igényeinknek megfelelően. Ha nem, akkor van igazán jó indokunk rá, hogy egy új osztályt javasoljunk. A "ha nem" azt jelenti, hogy nem lehetséges hozzáadni a meglévő osztályhoz a szükséges funkcionalitást az osztály alapjainak megváltoztatása nélkül.

Ha új osztályt írunk, próbáljuk meg az API kompatibilitást annyira megőrizni a létező osztályokéval, amennyire csak lehet! Ha nem lehetséges az osztály kompatibilitásának a megőrzése, készítsünk egy wrapper osztályt a kompatibilitás megőrzése érdekében. Nem gond, ha ez az osztály sok processzoridőt vagy memóriát igényel, a wrapper osztályok célja a kompatibilitás megőrzése és az új verzióra történő átállás megkönnyítése.

Egymással versenyképes osztályokat előzetesen be kell harangozni a PEAR fejlesztői levelezőlistán!