Note that there are some explanatory texts on larger screens.

plurals
  1. POPHP Structure - Interfaces and stdClass vars
    text
    copied!<p>I'm building a class to handle Paypal IPNs as part of a project, and since I already know i'm going to need to use it again in at least two more upcoming jobs - I want to make sure I structure it in a way that will allow me to re-use it without having to recode the class - I just want to have to handle changes in the business logic.</p> <p>The first part of the question is re. interfaces. I haven't quite grasped their usefulness and when/where to deploy them. If I have my class file ("class.paypal-ipn.php"), do I implement the interface in that file? </p> <p>Here's what i'm working with so far (the function list is incomplete but its just for illustration):</p> <p><strong>CLASS.PAYPAL-IPN-BASE.PHP</strong></p> <pre><code>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) { } } </code></pre> <p><strong>CLASS.PAYPAL-IPN.PHP</strong></p> <pre><code>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-&gt;dbQuery($SQL); //turn the specific project related stuff into something generic return $generic_stuff; //to be handled by the base class again. } } </code></pre> <p><strong>Usage</strong></p> <p>In this project: </p> <ul> <li>Require the class files for both the base, and the business logic class.</li> <li>Instatiate *paypal_ipn*</li> <li>Write code</li> </ul> <p>In other projects:</p> <ul> <li>Copy over the base IPN class</li> <li>Edit/rewrite the business logic class *paypal_ipn* within the constraints of the interface.</li> <li>Instantiate *paypal_ipn*</li> <li>Write code</li> </ul> <p>So as you can see i'm literally just using it to define groups of related functions and add comments. It makes it easier to read, but of what (if any) other benefit is it to me - is it so that I can pull the extender and the base class together and force errors if something is missing?</p> <p><strong>stdClass Question</strong></p> <p>The second part of the question is building on the readability aspect. Within the class itself there is an ever increasing number of stored variables, some are set in the constructor, some by other functions - they relate to things such as holding the database connection vars (and the connection resource itself), whether the code should run in test mode, the settings for logging and the log itself, and so on...</p> <p>I had started to just build them as per usual (again, below incomplete &amp; for illustration):</p> <pre><code>$this-&gt;dbConnection = false; $this-&gt;dbHost = ""; $this-&gt;dbUser = ""; $this-&gt;enableLogging = true; $this-&gt;sendLogByEmail = true; $this-&gt;sendLogTo = "user@domain.com"; </code></pre> <p>But then I figured that the ever growing list could do with some structure, so I adapted it to:</p> <pre><code>$this-&gt;database-&gt;connection = false; $this-&gt;database-&gt;host = ""; $this-&gt;database-&gt;user = ""; $this-&gt;logging-&gt;enable = true; $this-&gt;logging-&gt;sendByEmail = true; $this-&gt;logging-&gt;emailTo = "user@domain.com"; </code></pre> <p>Which gives me a much easier to read list of variables when I dump the entire class out as I code &amp; test. </p> <p>Once complete, I then plan to write a project specific extension to the generic class where i'll keep the actual SQL for the queries - as from one project to another, Paypal's IPN procedure and logic won't change - but each project's database structure will, so an extention to the class will sanitize everything back into a single format, so the base class doesn't have to worry about it and will never need to change once written.</p> <p>So all in all just a sanity check - before I go too far down this road, does it seem like the right approach?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload