Lehet a PEAR-ben több ugyanolyan funkcionalitással bíró csomag?

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!

Szükséges példákat és/vagy tesztfájlokat adnom a csomagomhoz, és hol tároljam őket? (Previous) Kérdésem van a PEAR-rel kapcsolatban. Hol kérdezhetek? (Next)
Last updated: Thu, 18 Dec 2014 — Download Documentation
Do you think that something on this page is wrong? Please file a bug report or add a note.
View this page in:

User Notes:

There are no user contributed notes for this page.