Shopping Cart Handler Class
There are a few things:


Comments like this one:

    parent::__construct(); // to run the constructor of parent


provide no real value; they just repeat what the code does.  Prefer reserving comments
for tricky bits of code that aren't self-explanatory.
You never use $dbLink; get rid of it. If subclasses need a database, let them
create one.
__destruct is largely unnecessary here.  You gain nothing from detaching references at
this point; PHP will already release them once your destructor returns.  And if you
followed the previous point, the only thing you're releasing no longer exists anyway.
All your variables are protected, which implies that you are planning for subclasses to
exist.  I'm not sure specializing a cart even makes much sense, though.

Unless you already have subclasses, and those subclasses need basically
unrestricted access to those properties, you should make them private.
(And even if you do, you might want to reexamine whether inheritance is the proper
relationship.)
You have a public constructor and a "create_cart" function?  That's going to confuse
people.  (You already created a Cart when you said new Cart.)  It looks like what you
need here is a name that more clearly describes what the function does.
I'm not a big fan of instance method names that include the containing class's name.
It feels like a symptom (or maybe a cause) of drifting away from OO concepts and back
to proceduralism.

This is just personal preference; take it as you will.  But IMO, if you have a Cart,
then from now until it dies, it will always be a Cart.  You don't have to keep
reminding it of that.  :)
I see that $cartProducts is a reference to an array in $_SESSION.  At that
point, both names refer to the exact same value.  Any change you make to
$this-&gt;cartProducts also happens to $_SESSION[$this-&gt;cartName], and vice versa.

Which makes me wonder: Why do so many methods mess with
$_SESSION[$this-&gt;cartName] rather than with $this-&gt;cartProducts?
Variable names like $data aren't very descriptive.  You know a product is being
added; most carts would include a quantity as well.  But i don't know for sure what
$data looks like, for two big reasons.  One is the name.  The other...?
You let the caller stuff whatever garbage it wants to in your cart.

A cart keeps track of items (or products), and typically quantities as well,
and usually has a way to get a total price.  This cart is basically a list of blobs,
and can't currently do any of that stuff easily, because it doesn't exert any type of
ownership.

The list of items is your domain, not the caller's.  Unless this is intended to be a
generic list of "whatever", you decide the structure of what goes into it -- and in
return, you get the ability to do stuff over and above what a stock list can do.
Otherwise, the caller is actually worse off using your cart than mucking around with
the $_SESSION['cart'] array directly.  (At least when they're using $_SESSION,
they know they're farting around with global state.  Your class hides that fact behind
what looks like a per-instance interface.)

You don't necessarily need to say "everything you insert must be an instance of this
particular class".  You could conceivably let the caller decide that much.  But you can
-- and probably should -- require that they exhibit certain behaviors (like having a
get_price() method).  These requirements should be documented.  And if you're
tracking quantities, then do so explicitly -- consider making $quantity a discrete
parameter to the add_product method.

Once you have decided how an item must behave, then you can do stuff that a typical
cart does out of the box.  If you decide items must have a price, for example, then
now you can add a way to get the total price of all items.   That in itself is part
of the bare minimum functionality i expect of any shopping cart class.  If it doesn't
have that, it's just another list.  :P


But the really big thing i'm seeing here is the relationship between carts and sessions.  A Cart might have a session, or use a session.  But it is really a different thing.  Inheriting from Sessions seems to me incorrect, unless the parent class is badly named.

It feels to me, though, like you have the relationship the wrong way around.  A Cart is obviously part of a session, as evidenced by your bunch of functions to manage subsets of session data.

And PHP lets you put objects in a session.

The cart itself could be session data, at which point $session-&gt;gimme('some cart name')
can return a whole Cart object, and all this session-management stuff becomes obsolete.

In order to make it work:


The class needs to be loaded, or autoloadable, before session_start().
The class must be serializable...which requires that anything you need to
persist must also be serializable, and/or that anything that's not serializable
not be included in the list of properties to store.
That's usually not a big deal; the only things PHP can't serialize are resources and
quasi-resources like your $dbLink.
(One of a number of reasons $dbLink probably isn't worth keeping.  But even if you
do, you can add a __wakeup() function to reinitialize it.)


The main thing to keep in mind is that if you only want the item info serialized, or you have unserializable fields (like $dbLink), you should provide a __sleep method that tells PHP which properties to serialize.  You'll probably also want a __wakeup() method to reinitialize those items that you didn't serialize.

With all that taken care of...what's left?

class Cart {
    private $items = [];

    public function add_product($product, $quantity) {
        $this-&gt;items[] = ['product' =&gt; $item, 'quantity' =&gt; $quantity];
    }

    public function delete_product_at($index) {
        unset($this-&gt;items[$index]);
    }

    public function update_product_at($index, $product, $quantity) {
        if (isset($this-&gt;items[$index])) {
            $this-&gt;items[$index] = ['product' =&gt; $product, 'quantity' =&gt; $quantity];
        }
    }

    public function get_total() {
        return array_reduce($this-&gt;items, function($sum, $item) {
            return $sum + $item['product']-&gt;get_price() * $item['quantity'];
        }, 0);
    }



    # don't really need __sleep or __wakeup, since $dbLink is gone.  But it might be
    # helpful to illustrate their use.
    private $some_value;

    public function __sleep() {
        # in `__sleep`, you return a list of properties you want saved
        return ['items'];
    }

    public function __wakeup() {
        # since $some_value wasn't serialized, it doesn't have a value.
        # before you use it again, set it to something sensible.

        $this-&gt;some_value = 42;
    }
}


The main missing piece left at this point is your display_cart function.  Not sure what it does...but frankly, if its name is accurate, it shouldn't be here.  :P

This is a model class, or a business object if you don't care about MVC and such.  It's responsible for managing the data, and for representing it in a way that the UI can do something with it. But most schools of thought on software architecture would say this class shouldn't be involved in the actual presentation/rendering.  That's the job of the code that manages the UI.

If you want to be able to list the cart's contents, two simple ways would be to have a function that returns $this-&gt;items, or implement the IteratorAggregate interface and have a getIterator() function return an iterator over $this-&gt;items.