Структура PHP - интерфейсы и переменные stdClass

Я создаю класс для обработки Paypal IPN как часть проекта, и, поскольку я уже знаю, что мне нужно будет снова использовать его, по крайней мере, еще в двух предстоящих вакансиях, я хочу убедиться, что структурирую его таким образом, чтобы я мог использовать его повторно. без необходимости перекодировать класс - я просто хочу обрабатывать изменения в бизнес-логике.

Первая часть вопроса - re. интерфейсы. Я не совсем понял их полезность и когда / где их развертывать. Если у меня есть файл класса ("class.paypal-ipn.php"), могу ли я реализовать интерфейс в этом файле?

Вот над чем я пока работаю (список функций неполный, но приведен только для иллюстрации):

CLASS.PAYPAL-IPN-BASE.PHP

interface ipn_interface {

    //Database Functions
    // Actual queries should come from a project-specific business logic class
    // so that this class is reusable.

    public function getDatabaseConnection();
    public function setDatabaseVars($host="localhost",$user="root",$password="",$db="mydb");
    public function dbQuery($SQL);

    //Logging Functions

    public function writeLog($logMessage);
    public function dumpLogToDatabase();
    public function dumpLogToEmail();
    public function dumpLogToFile();

    //Business Logic Functions

    private function getTransaction($transactionID);

    //Misc Functions

    public function terminate();
}

class paypal_ipn_base {

    //nothing to do with business logic here.

    public function getDatabaseConnection() {
    }

    public function setDatabaseVars($host="localhost",$user="root",$password="",$db="mydb") {
    }

    public function dbQuery($SQL) {
    }

}

CLASS.PAYPAL-IPN.PHP

final class paypal_ipn extends paypal_ipn_base implements ipn_interface {

    //business logic specific to each project here

    private function getTransaction($transactionID) {

       $SQL = "SELECT stuff FROM table";
       $QRY = this->dbQuery($SQL);

       //turn the specific project related stuff into something generic

       return $generic_stuff; //to be handled by the base class again.

    }

}

Использование

В этом проекте:

• Требовать файлы классов как для базового, так и для класса бизнес-логики.
• Установить * paypal_ipn *
• Написать код

В других проектах:

• Копировать базовый класс IPN
• Изменить / переписать класс бизнес-логики * paypal_ipn * в рамках ограничений интерфейса.
• Создать экземпляр * paypal_ipn *
• Написать код

Итак, как вы можете видеть, я буквально просто использую это для определения групп связанных функций и добавления комментариев. Это облегчает чтение, но какая (если есть) еще польза для меня -это для того, чтобы я мог объединить расширитель и базовый класс и вызвать ошибки, если чего-то не хватает?

stdClass Question

Вторая часть вопроса строится на аспекте удобочитаемости. Внутри самого класса постоянно увеличивается количество хранимых переменных, некоторые из них устанавливаются в конструкторе, некоторые - другими функциями - они связаны с такими вещами, как хранение переменных подключения к базе данных (и самого ресурса подключения), должен ли код запускаться в тестовом режиме настройки для ведения журнала и самого журнала и так далее ...

Я начал просто строить их как обычно (опять же, ниже неполные и для иллюстрации):

$this->dbConnection = false;
$this->dbHost = "";
$this->dbUser = "";
$this->enableLogging = true;
$this->sendLogByEmail = true;
$this->sendLogTo = "user@domain.com";

Но потом я решил, что постоянно растущий список может иметь некоторую структуру, поэтому я адаптировал его к:

$this->database->connection = false;
$this->database->host = "";
$this->database->user = "";
$this->logging->enable = true;
$this->logging->sendByEmail = true;
$this->logging->emailTo = "user@domain.com";

Это дает мне гораздо более легкий для чтения список переменных, когда я выгружаю весь класс во время кодирования и тестирования.

После завершения я планирую написать расширение для общего класса для конкретного проекта, где я сохраню фактический SQL для запросов - как от одного проекта к другому, процедура и логика Paypal IPN не изменятся - но каждый структура базы данных проекта изменится, поэтому расширение класса вернет все в единый формат, так что базовому классу не придется беспокоиться об этом, и его никогда не нужно будет изменять после написания.

Так что в целом просто проверка работоспособности - прежде чем я пойду слишком далеко по этому пути, кажется ли это правильным?