You are viewing our Forum Archives. To view or take place in current topics click here.
OOP & POP - What are the differences? Self Q&A.
Posted:

OOP & POP - What are the differences? Self Q&A.Posted:

Lucozayde
  • New Member
Status: Offline
Joined: Aug 16, 20168Year Member
Posts: 2
Reputation Power: 0
Status: Offline
Joined: Aug 16, 20168Year Member
Posts: 2
Reputation Power: 0
Although this may seem, at first, a question to the general public of TTG - I am using this post as a Q&A.

The purpose of this post is to show not only the possibilities of code but how to take different approaches to problems to create code more readable and manageable.

Let's actually start with the bare-bones of POP, or better known to most 'beginners' as Procedural oriented programming. POP is line by line code that is being executed in chronological order (more like, do this and then do that). It limits the flow of data streams and can be very hard to manage in large proportions.

Take an example - for this I'll stick with a more softly written language like PHP.


$db = new PDO('mysql:host=X;dbname=X', 'user', 'password');
$smtp = $db->Prepare('SELECT * FROM tbl WHERE col = ?');
$smtp->execute(['value']);
foreach($stmp->fetchAll() as $row) {
    echo $row['col'];
}


The above code will work fine! However, this sort of scenario can be looked at a different perspective and approached using OOP - or better known as Object oriented programming.

Using the same example we have seen, we can create code that is:
A) More readable
B) More manageable
& C) Resourceful code - not repeating code


class MyConnection extends PDO {
    public function __construct(
        $dsn, $user, $pass
    ) {
         try {
             parent::__construct($dsn,$user,$pass); // does what our first line does in POP
         } catch(PDOException $ex) {
              die($ex->getMessage());
         }
    }

    // add our query method
    public function query(
        $statement, $values = array()
    ) {
        $stmp = parent::Prepare($statement);
        $stmp->execute($values);
        return $stmp;
   }
}

$db = new MyConnection('mysql:host=X;dbname=X', 'user', 'pass');
foreach($db->query('SELECT * FROM tbl WHERE col = ?', ['value'])->fetchAll() as $row) {
    echo $row['col'];
}


What may seem a lot more code in the short run to you is actually a lot of less code in the long run. By creating objects and keeping it Object driven, you allow modules to be created in your software which are separated like sections making it easier to manage parts of your software.

If you want to start learning OOP principles like interfaces, extensions, finals and child/parents you can start here (in PHP).

If you have any questions or would like to get involved I have plenty of projects open source - my newest is reverse engineering too re-engineer software like OAuth connections to Microsoft to reveal Xbox Live content - but that you'll need experience for.

Good luck, hope this helped.
#2. Posted:
ObscureCoder
  • Resident Elite
Status: Offline
Joined: Jun 29, 201311Year Member
Posts: 211
Reputation Power: 13
Status: Offline
Joined: Jun 29, 201311Year Member
Posts: 211
Reputation Power: 13
Your example is kinda flawed and doesn't demonstrate many features of OOP at all.

The DB class you created is horrible. In the real world, you'd expect either some form of a singleton trait or even something more SOLID and inline with a dependency injection implementation. Your example would be better if it were a wrapper for something more esoteric rather than a generic prepared statements wrapper. Your foreach would also be considered bad for readability (a point you used to demonstrate the benefits of OOP). Your encapsulation model is terrible because you extended PDO (which would be fine if you had demonstrated a nicer, more encapsulated, example).

If you wanna rant on about OOP, I suggest you learn it.
[ Register or Signin to view external links. ] )
[ Register or Signin to view external links. ] )
[ Register or Signin to view external links. ]

Wrapping code in classes doesn't suddenly make your code OOP. Remember that.
#3. Posted:
ApexJnr
  • 2 Million
Status: Offline
Joined: May 09, 20159Year Member
Posts: 233
Reputation Power: 9
Status: Offline
Joined: May 09, 20159Year Member
Posts: 233
Reputation Power: 9
The top ones easier to read cus im used to it, familiarity is a big thing.
#4. Posted:
CriticaI
  • Summer 2018
Status: Offline
Joined: Nov 05, 201311Year Member
Posts: 2,753
Reputation Power: 452
Status: Offline
Joined: Nov 05, 201311Year Member
Posts: 2,753
Reputation Power: 452
I got by for years with out using OOP.
I only started using it recently because I'm working on bigger projects and working with other developers.
It's pretty much a way to clean up your code and to prevent name collisions.
If you are making small projects where OOP is optional though then I wouldn't recommend learning it.
#5. Posted:
var
  • TTG Senior
Status: Offline
Joined: Dec 24, 201211Year Member
Posts: 1,498
Reputation Power: 79
Status: Offline
Joined: Dec 24, 201211Year Member
Posts: 1,498
Reputation Power: 79
CriticaI wrote I got by for years with out using OOP.
I only started using it recently because I'm working on bigger projects and working with other developers.
It's pretty much a way to clean up your code and to prevent name collisions.
If you are making small projects where OOP is optional though then I wouldn't recommend learning it.


A firm understanding of OOP is required for anyone who plans on having an even remotely successful career in software engineering. I assume you've occasionally been writing small front-end scripts for websites over the past few years? Anything beyond that I can only assume your code has been cluttered, limited in regards to reusability, and certainly not "DRY". Just about every programmer should learn OOP. They should also learn to not fall into the habit of trying to make everything into an object.
Jump to:
You are viewing our Forum Archives. To view or take place in current topics click here.