PHP for ASP.NET Developers (part 5 – Object lifetime)

Following from my last post on the basics of object orientation in PHP, what about object lifetimes. How long does an object hang around for?

Class Diagram

In PHP you have a __destruct method on a class. This is like the finaliser in C#. For example, here is a HomoSapien class (a natural extension from the object model above).

class HomoSapien extends Mammal {

    public function __construct()
    {
        echo("Hello World!");
    }

    public function __destruct()
    {
        echo("Goodbye, cruel world!");
    }

    public function Vocalise()
    {
        echo "To be, or not to be...";
    }
}

When an object is create the __construct function is run (as we saw in the last post). The __destruct function is run when the object is unset, like this:

$human = new HomoSapien();
echo("n");
unset($human);
echo("n");

The output shows that the __constuct and __destruct methods were run.

Like the __construct function, the __destruct function does not automatically call the parent (as it would in C#). You have to do that explicitly with code like this:

public function __destruct()
{
    parent::__destruct();
}

Similarly, when the object goes out of scope the __destruct method is run:

function doStuff()
{
    $human = new HomoSapien();
    echo("n");
    $human->Vocalise();
    echo("n");
}

doStuff();

outputs:

Hello World!
To be, or not to be...
Goodbye, cruel world!

The destructor will also be run at the end of a script, so if the objects have not yet gone out of scope by that point they will be run. Any statements that output to the page will be run after the page has rendered. For example, the following script:

<html>
 <head><title>My little test PHP script</title></head>
 <body>
  <pre>
<?php

include_once('HomoSapien.php');

$theMother = new HomoSapien("Caitlin", null, null);
$theFather = new HomoSapien("Iain", null, null);

$theChild = new HomoSapien("Douglas", $theMother, $theFather);

?>
</pre></body></html>

Outputs the following:

<html>
    <head><title>My little test PHP script</title></head>
    <body>
  <pre>
Hello, I'm Caitlin!
Hello, I'm Iain!
Hello, I'm Douglas!
</pre></body></html>Douglas is no longer in the building!
Iain is no longer in the building!
Caitlin is no longer in the building!

And for completeness, here is the HomoSapien.php mentioned in the last example:

<?php
include_once("Mammal.php");

class HomoSapien extends Mammal {
    private $name;

    public function __construct($name, $mother, $father)
    {
        parent::__construct($mother, $father);
        $this->name = $name;
        echo("Hello, I'm {$this->name}!n");
    }

    public function __destruct()
    {
        echo("{$this->name} is no longer in the building!n");
    }

    public function Vocalise()
    {
        echo "I think, therefore I am.n";
    }
}
?>

Mammal.php:

<?php

include_once('Animal.php');

abstract class Mammal extends Animal {
    protected $mother;
    protected $father;

    public function __construct($mother, $father)
    {
        $this->mother = $mother;
        $this->father = $father;
    }

    public function displayParents()
    {
        echo ("Mother=".$this->mother."; Father=".$this->father);
    }
}
?>

Animal.php:

<?php

abstract class Animal {
    public abstract function Vocalise();
}

?>

PHP for ASP.NET developers (part 4 – Object Orientation)

Continuing on my series of getting to know PHP for ASP.NET developers, I’m going to concentrate on the object oriented parts of the language.

Class Diagram

In order to creating a class is very similar to C#, for example:

class Animal {
    //put your code here
}

To create a derived class you “extend” the base class.

class Mammal extends Animal {
    //put your code here
}

There is a bit of a clash of nomenclature here, but in PHP “properties” are what C# calls “fields”. Don’t confuse PHP properties with C# properties, they are not the same thing.

To create a PHP property, all you need to do is indicate the accessibility of the property and name the property. In PHP you don’t need to declare a type as you would in C#. The accessors are public, protected and private which are similar to C#.

class Dog extends Mammal{
    protected $name;
}

You can also set default values for properties. They must be compile time constants or literal values. For example:

class Dog extends Mammal{
    private $name = "Rover";
}

To create methods (or rather “functions”) on a class you can declare them in a similar way to C#, you indicated the accessibility (although in PHP they are public by default). For example:

public function speak() {
    echo ("Woof!");
}

You can create an instance of the class in a similar way to C#, to use the methods you replace the dot in C# with a -> in PHP. For example:

$dog = new Dog();
$dog->speak();

Each class has a default constructor, to create your own constructor create a function called __construct with the desired parameters. For example:

class Mammal extends Animal {
    protected $mother;
    protected $father;

    public function __construct($mother, $father)
    {
        $this->mother = $mother;
        $this->father = $father;
    }

    public function displayParents()
    {
        echo ("Mother=".$this->mother."; Father=".$this->father);
    }
}

In derived classes you have to call the base constructor explicitly. It won’t be called otherwise. You can do this like so:

class Cat extends Mammal {
    public function __construct($mother, $father)
    {
        parent::__construct($mother, $father);
    }

PHP also supports abstract classes and methods (functions). For example, in the examples I’m using here, you probably would not want to instantiate the Animal class. Let’s also say that we want to create an abstract function (one that we fill in the details of in a derived class). Simply add the keyword “abstract” to the method signature just like in C#. For example:

abstract class Animal {
    public abstract function Vocalise();
}

abstract class Mammal extends Animal {
}

class Dog extends Mammal{

    public function Vocalise() {
        echo ("Woof!");
    }
}

Method hiding or overriding – or the difference between new and virtual

When developing applications it is very important to understand the difference between method hiding and method overriding.

By default C# methods are non-virtual. If you are a Java developer this may come as a surprise. This means that in C# if you want a method to be extensible you must explicitly declare it as virtual if you want to override it.

So, what is overriding? Wikipedia has a succinct definition. Method overriding is a language feature that allows a subclass [aka derived class] to provide a specific implementation of a method that is already provided by … its [superclass] [aka base class]. The implementation in the subclass overrides (replaces) the implementation in the superclass.

The important thing to remember about overriding is that the method that is doing the overriding is related to the method in the base class.

Method hiding, by contrast, does not have a relationship between the methods in the base class and derived class. The method in the derived class hides the method in the base class.

I wouldn’t personally recommend method hiding as a strategy for developing code. In my opinion, if you feel the need to hide the method on the base class then you are most likely doing something wrong. I haven’t come across any scenarios where method hiding couldn’t be better implemented by other means, even as simple as just naming the method on the derived class to something else.

Let’s look at some code to show you what I mean. First off we are going to use this class structure (it’s my favourite when showing off inheritance, and you may have seen variations of it already on my blog).

Partial Class Diagram

Let’s say that the Dog class has a method call Bark()

public class Dog: Mammal
{
    public void Bark()
    {
        Console.WriteLine("Woof!");
    }
}

So far, so good. We can call it like this:

static void Main(string[] args)
{
    Dog d = new Dog();
    d.Bark();
    Console.ReadLine();
}

And the output of the program is as you’d expect. “Woof!” is written to the console.

Now, Chihuahuas are nippy wee things and they tend to “yip” rather than “woof” so what we’ll do is create a Bark() method in Chihuahua class that writes out “Yip!” instead.

public class Chihuahua : Dog
{
    public void Bark()
    {
        Console.WriteLine("Yip!");
    }
}

What happens here is that the C# compiler will display a warning to indicate that it has found a situation that it can guess at the intended functionality, but it really wants to to be explicit.

warning-message

‘Animals.Chihuahua.Bark()’ hides inherited member ‘Animals.Dog.Bark()’. Use the new keyword if hiding was intended.

By inserting the new keyword between the public and the void in the method declaration we can get rid of this warning. We are being explict and telling the compiler that we know what we are doing. So, what are the implications of method hiding? Consider the following bit of code:

static void Main(string[] args)
{
    Dog d = new Chihuahua();
    d.Bark();
    Console.ReadLine();
}

Well, if you have a Dog reference that actually refers to an instance of the Chihuahua class then when you call bark it will still say “Woof!” That goes against many people’s expectations. This is because you’ve actually drawn that line in the sand and are saying that the Bark method on Chihuahua is unrelated. If you hold a reference to a Dog then you may not be expected to know about the existence of a Chihuahua so if your calling code suddenly got the functionality of the Bark method in the Chihuahua class then it might break. The CLR cannot make that decision for you. If you do know about your Dog reference actually being a Chihuahua then you must cast it before using it. However, that means you are likely to have to litter your code with conditional statements based on the actual type of the object and that defeats the power of having an object oriented language.

What you should have done is make the Bark method virtual then overriden the derived version like this:

public class Dog : Mammal
{
    public virtual void Bark()
    {
        Console.WriteLine("Woof!");
    }
}
public class Chihuahua : Dog
{
    public override void Bark()
    {
        Console.WriteLine("Yip!");
    }
}

This way when you have a Chihuahua object then the correct Bark method is called regardless of the type of the reference so long as the reference type can see a Bark method on that hierarchy

The way I see it is that there is no reason to have to draw that line in the sand and use the new keyword in the context of method hiding. If you feel the need to do that then your two realistic options are either to consider whether what you really want to do is make the base virtual and then override in the derived class, or whether you need to think of a better name for the method in the derived class. If the methods are related (like the Bark example above) then method overriding is what you need. If they are not related then make that explicit by giving the method in the derived class a different name.

Mixins in C# 3.0

This is something I’ve been mulling around in my head for a few days now. “Out of the box” C# 3.0 does not support mixins, but I think you can get some of the abilities of a mixin with what is there already.

Firstly I should probably explain what a mixin is. A mixin is a class that provides some specific functionality that is to be inherited by a derived class, but it does not have a specialisation (kind-of) relationship with the derived class.

The example that I have is of a class hierarchy representing different types of animal.The base class is Animal, derived from that is Avian and Mammal. Derived from Avian is Parrot, Penguin and Chicken. Derived from Mammal is Dog, Cat, Whale and Bat.

Class-Diagram-1

These animals all have various methods of locomotion. Some can swim, some can run and others can fly. However, as you can see there is no obvious relationship through the base class. It might seem at first glance while designing the class hierarchy that an avian should be able to fly. It is, after all, the first thing that springs to mind when thinking about how birds get from one place to another. But what about flightless birds such as the Dodo? Similarly, don’t all mammals run? No, there are many that live in the sea.

As you can see, adding methods for flight on the Avian base class or running on the Mammal base class don’t work in all cases. This is where mixins come into play.

Mixins can, in this example, provide the functionality for flight, running or swimming, or any other form of locomotion by having the appropriate class inherit the functionality. However, C# does not permit multiple inheritance. You can inherit from one base class only in C#.

But, you can implement multiple interfaces. At this point you are probably thinking “Ah-hah! But interfaces don’t have any functionality”. True, you won’t get too far if you just use some interfaces on the classes. But it is the first step.

Class-Diagram-2

With C# 3.0 came the introduction of Extension Methods and they can be applied, not only to classes but, also, to interfaces. Extension Methods provide additional functionality on an existing class without modifying the class. (You can read more about Extension Methods here). It then becomes possible to create a static helper class for specific functionality that defines the extension methods. Because the classes implement the interface (even if the actual interface doesn’t contain any methods or properties to implement) it will pick up all the extension methods also.

public  static  class SwimMixin
{
    public static void Swim(this ISwim target)
    {
        // Perform Swim functionality on the target
    }
}

This provides very limited mixin functionality. The imitation mixin cannot hold any data of its own which means that so long as the imitation mixin can get away without adding attribute information of its own then it is still useful.

If you need to have the mixin hold its own data then I can, at present, see a number of potential solutions to this problem. Unfortunately no solution is terribly elegant, nor are they problem free.

The first is to use a lookup keyed on weak references to the actual instantiated class with the result of the lookup returning the data needed for the Mixin. The reason for the weak reference is to ensure that the instances of the class get cleared out and are not retained by the imitation mixin. Remember the imitation mixin is built out of a static class so it won’t go out of scope and get cleared up by the garbage collector and everything it holds will stay around as long as the application is running. The main problem with this approach is that as the number of actual instantiated classes increases the lookups get larger and will naturally slow down. Also, some mechanism for clearing out the keys and data that are no longer required has to be implemented as the actual objects are garbage collected.

The second is to use the interface that the extension method is using to provide a method that can be used by the imitation mixin to access its data. This would mean that the actual  instance of the class would have to hold onto some additional data on behalf of the imitation mixin, which negates part of its usefulness.

The third is to create a base class for that all classes that may wish to use a mixin inherit from. This base class can contain “instance” data, in a hashtable keyed on the mixin type (for instance) on behalf of the mixin itself. This would, unfortunately, mean that the data is exposed and render encapsulation useless. It also causes a small hit each time a mixin method needs access to its “instance” data. Naturally, if you are inheriting from an existing framework class you won’t have the option of putting in a base class to hold the mixin data.

Class-Diagram-3

It isn’t too hard to see that it may be possible in the future to have mixin behaviour built directly into the language as we are already part of the way there. In the meantime some limited functionality is available which can be extended to include instance data for the mixin itself with some extra work, but it isn’t without its problems.

Why make fields in a class private, why not just make them public?

A recent question came up on forum about encapsulation. I guess it is something that I don’t really think about any more as it comes naturally but it reminded me of how some of these concepts took a while to take hold when I was first taught them in university.

Encapsulation is sometimes also known as information hiding. The idea is that an object hides the details of how it works from the outside world. However, some definitions of encapsulation suggest that it is just putting the data and the methods that operate on that data together in one class (the capsule).

The question asked was why make fields in a class private, why not just make them public?

I now find very idea of making a field public incredulous. However, if I stretch my mind back about 10+ years or so I can vaguely remember asking similar questions and thinking how crazy it was making member variables private and having to access them through special functions. It isn’t crazy at all.

So, what do you get from hiding fields behind the private or protected accessor?

The primary advantage is that it hides the internals of the class and shifts the dependency onto a well defined interface. By interface I mean a public method or property on the class rather than having the class inherit from an interface. Code that accesses the class will call on the public methods and properties and need know nothing about what is happening inside the class. This leaves great scope for future implementations of the class to vary what happens internally while maintaining the same external interface. Code that uses the class will then continue to operate without being modified. Put simply – It is a form of protection from future unknowns.

For example, say that a class represents an alarm clock which allows two separate alarms to be set. Internally, those alarms are represented as two separate fields. When the client code accesses the alarm clock class it uses a set of public methods and properties. This allows at at some point in the future the internal storage of the alarm times to be changed to use an array rather than two separate field instances. If the fields were public a lot of code outside the class may have to be updated also to accommodate the new structure of the class.

Even if there is not going to be any internal change to the class, the use of methods and properties to access the fields can provide other advantages.

For example, you might decide later that it would be better to leave the field uninitialised and then have your property initialise it when it is first used. This is called a lazy-lookup. If the field value can be constructed from the information the class already holds, but it is an expensive operation to do so, and the usage patterns show that the value is not often needed then why create it needlessly? So, the property checks the field, if the field is null it creates the value and stores it in the field and returns the new value. If the field already contains a value then it is the cached value that is returned.

Alternatively, you discover some time in the future that when you set the property that you need to carry out some other action (an analogy would be like a trigger in the database). So, since you have a property already, you can now put the extra functionality in without having to completely break your application.

Another example being that validation could be taken before the field is updated with the new value. This keeps the object in a consistent state. If you just exposed the field you would never know if some other object set the field to an invalid value and this is a potential source of bugs, especially the nasty sort that rear their head further on past the point that the bug was actually introduced. These are a real pain to track down and anyone having to maintain your code will not thank you for allowing that into the system.

An interesting advantage to using public properties backing private fields is that the developer can set breakpoints on the properties but not on the fields. That is very useful for debugging the application. Debugging trace statements can also be placed there

Finally, if a property is a simple field backer it can also be used to provide a read- or write- only access to the fields. This is particularly useful if the object is to be immutable, that is, it doesn’t change once created.

NOTE: This post was rescued from the Google Cache. The original date was Monday, 28th November 2005.

Tags:


Some of the original comments:

I had this very debate at my place of work several times myself – obviously, as a hopefully good developer, I always argued *for* encapsulation of fields (I’ve taken to making that a key point on any code reviews I do now) – in particular things like access to ViewState and Session objects in ASP.NET.

OK, so I’ve done it myself occasionally too, but nobody is perfect :-D

The nice thing about using C# is you can make use of properties to retro-fit in such an interface later on if you really have to without *too* much pain.

(Yeah, I’ll just go into the cowboy developer corner now….)

11/29/2005 12:45 AM | Ian D

Another important reason is DataBinding. DataBinding relies on events name xxxChanged, where xxx is the property name. If you access the field directly, you won’t be able to take advantage of events firing on value changes, and this in turn means DataBinding will break.

11/29/2005 1:22 PM | Marc

To clarify Marc’s point, data binding will not actually break without xxxChanged events, it will just be one way (control–>object).

I have a lot of OO experience, and I can say without doubt that encapsulation is a good thing, but I can still argue against using simple wrapping properties, in theory at least….

The fact that public fields are not absolutely identical to public properties from the interface perspective is a flaw in the implementation of the programming language. I should be able to change a public field to a property (or vice-versa) whenever I feel like it, without it affecting the interface of my class. That is what encapsulation means.

As far as I can tell, the fact that I cannot is because of the implementation of the compiler/clr/language.

11/29/2005 7:40 PM | Steve Campbell

>>As far as I can tell, the fact that I cannot is because of the implementation of the compiler/clr/languag

yes , properties is just syntactic sugar, they are implemented as methods : get_Property set_Property in the ilcode

and methods and fields are not interchangable for obvious reasons.

12/2/2005 9:04 AM | Roger Johansson

The public fields debate again

Back in November last year I wrote about why you should make fields in a class private and not make them public. A recent post in Code Project shows that some people still make fields public. I did concede on one argument though – If you have a struct with nothing but public fields then there was no need to make them private and create public properties to back them. But, I added….

As soon as you put any form of functionality in there (or even if you think that at some point in the future there will be some form of functionality in there) then make them private and create properties.

While accessing public fields and properties may look the same to a C# developer, a property is just syntactic sugar over the get_ and set_ methods. So if you make the transition to properties later on (for to add additional functionality – e.g. implementing a lazy look up on a getter, or setting a dirty flag on a setter) any assemblies that relied on public fields will fail because, to them, the public interface of the class is now different.

Therefore if you get in to the habit of creating properties backing your private fields always you’ll never have to worry about how you are going to add in additional functionality later on when you realise the public interface changes.

NOTE: This was rescued from the Google Cache. The original date was Saturday 17th June 2006.

Tags:


Original Comments:

There is nothing wrong with using public fields in an non-public accessable class.

6/17/2006 5:52 PM | leppie

I dont think its wrong to have public fields in a lib as long as you dont plan on beeing binary compatible, since binary compatabillity breaks the day you change one of those fields to a property..

6/18/2006 6:36 AM | Roger Johansson

leppie – I’ll accept that is also another place where it might be okay to use public fields.

6/23/2006 9:53 PM | Colin Angus Mackay
Follow

Get every new post delivered to your Inbox.

Join 26 other followers