Asked  7 Months ago    Answers:  5   Viewed   35 times

I have been using the procedural approach with mysql* until recently. Now I want to shift to mysqli and object oriented approach. Many online resources and books state that OOP is better than procedural even in case of PHP. After going through some online tutorials, I have written a small program that connects to the database and selects a value. I want to know why the object oriented approach is better? Plus is this the right way to code an OO php web page?

The object oriented approach

$host = "localhost";
$username = "root";
$password = "";
$dbname = "compdb";

@ $db = new mysqli($host, $username, $password, $dbname);

if(mysqli_connect_errno())
{
    die("Connection could not be established");
}

$query = "SELECT company_id FROM company_basic_details WHERE company_name = 'ABC'";
$result = $db->query($query);

$total_num_rows = $result->num_rows;

echo "The Results Are : <br>";

while($row = $result->fetch_array())
{
    echo $row['company_id'];
}
?>

The procedural approach

<?php

$host = "localhost";
$username = "root";
$password = "";
$dbname = "compdb";

@ $db = mysqli_connect($host, $username, $password, $dbname);

if(mysqli_connect_errno())
{
    die("Connection could not be established");
}

$query = "SELECT company_id FROM company_basic_details WHERE company_name = 'ABC'";
$result = mysqli_query($db, $query);

$total_num_rows = mysqli_num_rows($result);

echo "The Results Are : <br>";

while($row = mysqli_fetch_array($result))
{
    echo $row['company_id'];
}
?>

 Answers

25

The main reason is that PHP is moving steadily in the direction of OO programming.

There's nothing wrong with using mysqli_xxx() functions rather than the OOP equivalents; it is exactly the same as far as the code is concerned.

The only issue is that you'll be getting yourself further and further behind the curve in terms of what people think of as well-written PHP code.

It's worth noting that the PDO library, which is considered the ideal for most DB code in PHP is OOP-only. It doesn't have a procedural interface. And nor do most of the other new features added to PHP in the last few versions. If you want to use PHP to its fullest, you need to know OOP anyway.

There's also the point about the ability to create an extension class for your DB -- something like this:

class myDB extends mysqli {
     .... your own stuff here to extend and improve the base mysqli class
}

Of course you can achieve the same thing with procedural code, but it's not as neat as the OOP way. And of course that's only relevant if you actually want to extend the class.

However, as a first step, just moving from mysql_xxx() to mysqli_xxx() is a great start. Moving the whole way to using the OOP interface would be even better, but just switching to the mysqli functions is a good start.

Using the procedural interface to begin with will certainly make the transition away from the old mysql_xx() functions easier, so if switching to the OOP interface is too much of a leap at the beginning, don't feel you have to do it all in one go. Start with a conversion to the procedural mysqli functions, then switch to the OOP methods later on; neither jump will be that big on its own.

Wednesday, March 31, 2021
 
ritch
answered 7 Months ago
95

You can test procedural code with PHPUnit. Unit tests are not tied to object-oriented programming. They test units of code. In OO, a unit of code is a method. In procedural PHP, I guess it's a whole script (file).

While OO code is easier to maintain and to test, that doesn't mean procedural PHP cannot be tested.

Per example, you have this script:

simple_add.php

$arg1 = $_GET['arg1'];
$arg2 = $_GET['arg2'];
$return = (int)$arg1 + (int)$arg2;
echo $return;

You could test it like this:

class testSimple_add extends PHPUnit_Framework_TestCase {

    private function _execute(array $params = array()) {
        $_GET = $params;
        ob_start();
        include 'simple_add.php';
        return ob_get_clean();
    }

    public function testSomething() {
        $args = array('arg1'=>30, 'arg2'=>12);
        $this->assertEquals(42, $this->_execute($args)); // passes

        $args = array('arg1'=>-30, 'arg2'=>40);
        $this->assertEquals(10, $this->_execute($args)); // passes

        $args = array('arg1'=>-30);
        $this->assertEquals(10, $this->_execute($args)); // fails
    }

}

For this example, I've declared an _execute method that accepts an array of GET parameters, capture the output and return it, instead of including and capturing over and over. I then compare the output using the regular assertions methods from PHPUnit.

Of course, the third assertion will fail (depends on error_reporting though), because the tested script will give an Undefined index error.

Of course, when testing, you should put error_reporting to E_ALL | E_STRICT.

Saturday, May 29, 2021
 
Aamir
answered 5 Months ago
48

Basically copying and pasting from Bjarne Stroustrup's "The C++ Programming Language 4th Edition":

List initialization does not allow narrowing (┬žiso.8.5.4). That is:

  • An integer cannot be converted to another integer that cannot hold its value. For example, char to int is allowed, but not int to char.
  • A floating-point value cannot be converted to another floating-point type that cannot hold its value. For example, float to double is allowed, but not double to float.
  • A floating-point value cannot be converted to an integer type.
  • An integer value cannot be converted to a floating-point type.

Example:

void fun(double val, int val2) {

    int x2 = val;    // if val == 7.9, x2 becomes 7 (bad)

    char c2 = val2;  // if val2 == 1025, c2 becomes 1 (bad)

    int x3 {val};    // error: possible truncation (good)

    char c3 {val2};  // error: possible narrowing (good)

    char c4 {24};    // OK: 24 can be represented exactly as a char (good)

    char c5 {264};   // error (assuming 8-bit chars): 264 cannot be 
                     // represented as a char (good)

    int x4 {2.0};    // error: no double to int value conversion (good)

}

The only situation where = is preferred over {} is when using auto keyword to get the type determined by the initializer.

Example:

auto z1 {99};   // z1 is an int
auto z2 = {99}; // z2 is std::initializer_list<int>
auto z3 = 99;   // z3 is an int

Conclusion

Prefer {} initialization over alternatives unless you have a strong reason not to.

Tuesday, June 1, 2021
 
dotoree
answered 5 Months ago
54

$stmt->bind_param() requires all params to be passed by reference, so you can't pass function's return value directly (without assigning it to a variable first, that is). But, as was already mentioned in the comments, you don't need to escape the parameters at all, that's one of the advantages of using prepared statements.

Saturday, August 7, 2021
 
tuckerjt07
answered 3 Months ago
39

I assume that you're running this on a Retina device. In UIGraphicsBeginImageContextWithOptions, you asked for the default scale, which is the scale of the main screen, which is 2. This means that it's generating a bitmap 4x as large. In the second function, you're drawing at 1x scale.

Try passing a scale of 1 to UIGraphicsBeginImageContextWithOptions and see if your performance is similar.

Thursday, September 16, 2021
 
CBroe
answered 1 Month ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :