How much OO is too much?

[DougBTX]

Sorry to contradict you but that's definitely not correct. What are your references for this?

I was referring to "Domain objects" as they exist in a Domain Model, which is a "web of interconnected objects, where each object represents some meaningful individual". Note that this doesn't include anything to talk to the database.

As you point out, talking about "Model objects" is a bit ambigious (though I thought the mention of AR vs Domains made it clear enough what I was talking about). I was referring to a objects which exist in the Model layer in MVC, which includes objects which talk to the database. Calling them "ActiveRecord based Model objects" is closer to the mark, but it's a bit unwieldly for more than a paragraph.

The distinction I was trying to make, is that an "ActiveRecord based Model object" is responsible for talking to the database, but a "Domain object" never is. (The "ActiveRecord based Model object" could delegate database calls behind the scenes, but that's an implementation detail. The existance of "behind the scenes" is important in OOP )

Regards,
Douglas

[McGruff]

Actually active records are domain objects. They create a type of domain model where there's a close match between the db table structure and the domain objects.

I'm not sure what I think about validation. There are checks for valid request syntax which don't involve the domain, and other checks which do. Perhaps it should be a two stage process although at present I just do it all in a Request object. I like a single front door - this possibly helps security. Nothing gets through which hasn't validated and all validation is carried out in one place rather than scattered around the app.

[DougBTX]

I like a single front door - this possibly helps security. Nothing gets through which hasn't validated and all validation is carried out in one place rather than scattered around the app.

Then you rely on consitency between the front door and the objects behind that door, rather than consistency between the objects and themselves.

If you put all validation on that door, you have similar maintenance problems as between documentation and code. Another place to make changes when you want to update an object behind the curtain. Though nothing that can't be overcome through extra work

Douglas

[McGruff]

If you put all validation on that door, you have similar maintenance problems as between documentation and code. Another place to make changes when you want to update an object behind the curtain.

Yes - although I suppose you could define a specification (a set of validation rules) in the domain object and make a call to the object to get them. The validation code would just apply whatever it finds there.

However, it might not be possible to define all the validation requirements in a domain object without giving it knowledge of the presentation. For example, with a forum post, you might want to check for XSS. This kind of rule would be required only in the http context.

Not that you'd be likely to try to make a CLI forum of course...

[DougBTX]

Off Topic:

For example, with a forum post, you might want to check for XSS.

I've not really been keeping up on the latest developments on this, isn't it just a case of proper escaping?

[McGruff]

Another example might be escaping parameters which will be used in SQL queries. Filtering makes the query safe but to actually detect an attempt at sql injection you'd have to do more - and ideally you'd have some way to identify the attacker. Unfortunately there isn't any guaranteed way to do that. You might get lucky. At the least it could tell you how often you're being attacked.

[Etnu]

I feel that even though long time PHP gurus advocate against using OOP to group functions, it still helps out in your code. It is kind of like each object represents an idea or concept.

Although it doesn't match up with the purpose of OOP, it does make programming much easier. I've done it myself in the next version of a CMS that I'm writting now.

It's pretty much the only thing you can do until PHP has proper namespace support, actually.

Also, it's not anything unique. It's called a singleton. It's a useful design pattern. The only people I've ever heard complaining about singletons are those who've never designed a real-world application.

[Etnu]

OOP is the reason why C++ was created, it was created with the idea of developing large programs above 50 000 lines of code.

Arbitrary limits aside, C++ (and all OO languages, like Java, smalltalk, etc.) were created for the same reason: to boost productivity. There's a reason why all "new" programming languages (programming languages built that way from the beginning, not scripting languages-turned-programming languages like PHP, Python, and Perl) are object oriented -- development. Spend a little time trying to maintain a large-scale project in C and you'll suddenly realize why OO languages were created.

Can anyone imagine 50 000 lines in procedural programming, and how would they be kept up to date

You mean like PHP itself, Quake 3, and the majority of compiled code out there? It's messy, and you usually wind up implementing stuff that languages with native OO support out of the box.

PHP has become the C++ of the web; it took procedural roots, and, as it became extremely popular and began to see corporate usage, began evolving into an OO language. Yes, that means it has plenty of constructs and flaws. It also has many strengths, namely in that you don't *have* to do everything with objects. It's not always appropriate, especially not for a stateless, interpreted language that has potentially infinite entry points.

PHPs biggest advantage is that it's not going away. It's truly cross-platform, completely open source (a claim that neither Java nor C#* can make). PHP is not an all-purpose language. Things like php-gtk usually just make me shake my head. It's a web programming language, suited for the special needs of web development. It isn't Java, it isn't C#, and it isn't C++. So stop comparing them.

If you're going to compare PHP to another language, compare it to Perl, Python, and Ruby, as those are languages specifically designed for the same sorts of tasks that PHP was.

* Mono is open source, but the most critical aspects of C# are not. Windows.Forms, anyone?

[been]

And hopefully that demonstrates the ideas

Yes, and quite thoroughly too, thank you for the in-depth reply

As you can see, the contract code is still there, it is just in a different place. The magic, is that it lets us think of things in a rather different way. Note that the assert line now uses $this->color instead of testing the input $color directly, this means we can test compliance with the contract whenever it is most useful for us.

I think this is one key point where our opinions differ: By calling the validate() method when needed we're allowing an object of class Shape to be in an invalid state:

s =& new Shape('bobo'); 

will allow Shape s to exist until validate() gets called, this has consequences:
We must make sure validate() gets called whenever we want to do something with a Shape object (like the save() example you gave). For methods in Shape or its parent, that's probably ok if we're the writers.
But, it's impossible to predict what clients will do with it, so we have to make sure that validate() gets called in the client code before that. How should we do this? By warning writers of client code in our doc comments?

It is just a contract. That's all we have to write. We now have the option of constructing the new Shape implicitly:

$shape = new Shape($_REQUEST);
   if ( !$shape->save() )
   {
       #   send the form back with error messages...
 } 

So what does validate() look like in this case? I'm asking because, if I consider the rest of the code you posted;
save() calls validate()
validate() calls assert()
assert() throws an exception if contract is breached.

So, you cannot do if (! $shape->save()) for checking user input, you're back to exception checking...
Or you return false in validate() for example, in which case you don't have the 'crash early' approach for when a contract is breached.

Which brings up, I think, another key point where our opinions differ;
I still strongly believe that there's a distinct difference between client code not living up to a contract and invalid user input:
Not living up to a contract is a bug, it is an exceptional situation and thus an exception should be raised (or something similar drastic), imo, we should crash early.
Which is something different than validating user input, where we totally expect errors to be made and we should fall back gracefully.
They're different monkeys, we should stroke 'm differently

[been]

It's pretty much the only thing you can do until PHP has proper namespace support, actually.

Also, it's not anything unique. It's called a singleton. It's a useful design pattern. The only people I've ever heard complaining about singletons are those who've never designed a real-world application.

Grouping functions in a class to simulate namespaces has nothing to do with singletons.
Furthermore, let me be one of those never-designed-a-real-world-application-people and state that the singleton pattern is overrated, I prefer the "Highlander principle": you pull out an ancient sword, very convincingly shouting "There can be only one!" and behead anyone daring to make more than one instance of such a class

[bonefry]

PHPs biggest advantage is that it's not going away.

Although.NET developers should be worried about this, how is that a concern for Java again ? Apart from the fact that it is a 10 year old technology prior to Java 5 nobody could release an open source implementation due to licensing reasons. But Java 5 has opened the way to a full blown open-source implementation that has IBM support: Apache Harmony. And it will be finalized because Sun isn't the only one driving Java you know.

It's truly cross-platform, completely open source (a claim that neither Java nor C#* can make).

I think we all know that. And so are Perl, Python, Ruby.

It isn't Java, it isn't C#, and it isn't C++. So stop comparing them.

As long as .NET, Java, and PHP (as platforms) share the same web development arena comparisson is innevitable

PHP has become the C++ of the web;

No, Perl is the C++ of the web (if you look at C++ as a foundation for stuff).

If you're going to compare PHP to another language, compare it to Perl, Python, and Ruby, as those are languages specifically designed for the same sorts of tasks that PHP was.

And what are those tasks ? Web development ?

* Mono is open source, but the most critical aspects of C# are not. Windows.Forms, anyone?

I think people are more interested in ASP.NET than in WinForms. But yes, apart from the C# specifications and the CLI, they are all proprietary, including asp.net.

[DougBTX]

I still strongly believe that there's a distinct difference between client code not living up to a contract and invalid user input

What if you consider the user to be a client?

So what does validate() look like in this case?

The assert which calls an exception was meant to follow "halt as soon as possible" model, an assert which would fit "tell the client what the problems are" would be more like this:

class ActiveRecordBase
{
    var $_errors = array();

    #  remember that array() == false
    function is_valid ( )
    {
        $this->_errors = array();
        $this->_validate();
        return !$this->_errors;
    }
    ###
   
    function assert ( $field, $valid, $message = 'Invalid' )
    {
        #  isset lets us return only the first error for each field,
        #  so that "missing" can be shown instead of "invlid".
        if (!isset($this->_errors[$field]) && !$valid)
        {
            $this->_errors[$field] = $message;
        }
    }
    ###
   
    function save()
    {
        if ($this->is_valid())
        {
            #   more code...
        }
    }
    ###
   
    #   more code...
   
}

class Shape extends ActiveRecordBase
{  
    function _validate ( )
    {
        $this->assert('color', in_array($this->color, array("green", "orange", "purple")), "What is this colour?");
    }
   
} 

(You could tuck away the validation code up in the inheritance tree, by having ActiveRecordBase inherit from ValidatingObject for example.)

Off Topic:

If you wanted to make the above more flexable, you could add an assert_rule method too, which would act a bit like the addRule method in the ApplicaitonController thread. I do think though that using an object where a boolean works is overkill and leads to bloated code, so should be treated as the exception rather than the rule.

But without affecting other code, it could look like this:

class ActiveRecordBase
{
    function assert_rule ( $field, $rule, $message = 'Invalid' )
    {
        if (!isset($this->_errors[$field]) && !$rule->passes())
        {
            $this->_errors[$field] = $message;
        }
    }
} 

A case where you might like to have the extra flexibility would be if you wanted to test to see if a username was unique, but you consider the database call to be expensive, so you only want to actually test it if the username is otherwise valid. Using objects is our best tool IMO when we don't have easy access to use anonymous functions.

But, it's impossible to predict what clients will do with it, so we have to make sure that validate() gets called in the client code before that. How should we do this? By warning writers of client code in our doc comments?

Here's the sort of flow I'm after:

- You set some things on an object
- You try and do something with the object
- If it fails, you look at the errors

(I disagree that it is impossible to predict what a client will do with our object, because unless they are simply treating it as a hash table, they will have to call our mthods. If they call our methods, we know what they are trying to do, and because they are our methods, we know if we need to call validate or not.)

From ouside, validate doesn't have to exist, it is just a way for the object to keep track of itself. I suppose it is a bit like an inversion of contracts, or at least an inversion of how they work in the getter/setter part of the code. Rather that having to meet a contract before you can set something on an object, you have to meet the contract before you can do anything with the object. It might just be that claim that a setter "does" something that doesn't sit well. When you are just taking in input (from a user or a client), are you "doing" anything?

From a physical perspective, yes, you are putting something in memory. In a language with strong static typing, yes, you are implicitly comparing the input with a strict type definition which you use to protect your memory, regardless of what you do, if you get the types wrong you'll have exceptions to deal with. What about a language with strong dynamic typing? Or even in PHP, with loose dynamic typing? You're not really storing the input, you're just keeping a reference to it. I'd argue that at a high level, you're not doing anything with it, because "doing" something is a cause, which implies an affect. But assigning to a variable which is loose and dynamic, nothing will ever happen beyond the assignment, there will be no external affects. With no affects, was there a cause? If there was no cause, did you really "do" anything? The only way to see if anything has even happened is to read the variable back, but by then processing has moved on to the next statement.

Regards,
Douglas

[DougBTX]

PHPs biggest advantage is that it's not going away.

Check the PHP5.5/PHP6 thread: this is also one of the problems for PHP as we move on, moving away from legacy PHP4 code. If we can't get hosts to move on from PHP4, (and I argue that the main userbase for PHP is in shared hosting), it will be a problem of PHP4 not going away, rather than worrying that PHP itself going away.

Douglas

[Dr Livingston]

But in saying that, shared hosting is the stable diet for PHP. So it appears that we are stuck with PHP4.x for the forseeable future at least. I'd suggest that it's going to take about 2 years for a good bit of PHP4.x development to migrate to PHP5.

PHP is popular not only because it's easy to pick up and use, but the hosting is there for everyone... It's extremely affordable, hell I not more than £30 per year for my hosting, and that's PHP5 on Linux.

I don't see the lack of PHP5 hosting being a hinderance currently as it stands today, as there is hosting available. You just have to look for it, that's all... Just don't expect it to jump out and bite your a**e, that's all

[arborint]

I know this is an OO thread and I know (oh how painfully clearly) all of your opinions about PHP and OO (and every other language for that matter), but the one thing not mentioned here is that the reason for PHP's popularity is that it happily allows Procedural programming which is much simpler for amateur programmers to learn and be productive. Face it, the web's two most popular languages are simplfied C (PHP) and BASIC (ASP). I know you will all whinge about the tons of crap code in PHP, but the bottom line is that PHP allows a broader group of people to build web applications than any other language. All that crap code is the result of languages like PHP that have enabled a revolution where many more people can program. Like it or not, code that revulses you drives a big piece of the web.

Sure the code does not meet your high standards, but fortunately only people like you care. It's the Purity vs. Utility argument and Utility repeatedly win much to your Purist chagrin. The reason there are no huge Python or Ruby support forums is that amateurs are just not going to learn languages like that. Probably the only hope for pure OO languages in the mainstream is code generation so that amateurs don't have to program.

Just because I think the fact that PHP allows amatuer programmers to fairly easily produce useful code (which you consider nightmarish crap) as a virtue, does not mean that I don't think it is a parallel virtue to encourage professional programmers (and those amateurs wanting to improve) to produce quality OO code.

One of the reasons I got involved in the "skeleton" threads is because I saw an amateur (cadmiumgreen whereever you are?) who was "wanting to improve" but there is very little OO code in PHP to lead the way. Sure there are a million frameworks, but you can't realisticly learn OO from them. I still believe that easy to implement, patterns based, OO code that can piece by piece be used as building blocks to learn OO would be a valuable contribution to PHP. I note that many of the opinionists in this thread were noticably absent in that development, perhaps because they did not understand the goal or ...

[bonefry]

PHP is popular not only because it's easy to pick up and use, but the hosting is there for everyone... It's extremely affordable, hell I not more than £30 per year for my hosting, and that's PHP5 on Linux.

Man, how right you are. I searched for Python hosting although they all say they support Python they actually refer to CGI. If you want ModPython or FastCgi with a backend WSGI server that's really hard to find.
Also Tomcat hosting prices start at aprox $15 but that mean usually Tomcat 4 but if you want Tomcat 5 you have to pay aprox $20 more. And those are just starter packages.

The $5 hosting plans are only available for PHP. That's hard to beat.

The most affordable sollutions for other platforms (other than PHP) are those virtual private servers (VPS) offers. Really, you can install on them what you want without asking some Grinch to install it for you. And pricing starts at $20.

that pricing is per month

[DougBTX]

Good post Chris, it is something that needs to be acknowledged. It reminds me somewhat of the "solve simple problems instead of hard ones" post at Loud Thinking

I note that many of the opinionists in this thread were noticably absent in that development, perhaps because they did not understand the goal

That's probably true. It felt like OO for the sake of OO, rather than trying to make a hypothetical PHP programmer's life easier, using tools which happened to include objects.

I still believe that easy to implement, patterns based, OO code that can piece by piece be used as building blocks to learn OO would be a valuable contribution to PHP.

Patterns, sure, use them in the code, but there isn't any need to structure the the building blocks along pattern lines. In associated tutorials which show how to use the classes and objects, say "XYZ bit of code uses ABC pattern like this: <example>" or even tutorials which focus on the patterns and use the code base as a source of examples would be cool. Saying "let's build a controller that can do anything and worry about using it in an applicaiton later" really turns me off, which is a reason I avoided the thread. I must have posted in it a couple of times though because I notice I'm subscribed to it

Procedural programming which is much simpler for amateur programmers to learn and be productive.

So why build an application controller to get in the way of that?

We don't need a Request or a Responce or Context or a Logger (which doesn't even write to a log? I don't get it) let alone a hundred IHandler's floating around. PHP wouldn't be where it is today if it didn't support all that out of the box. PHP also benifits from massive amounts of documentation focused on using it for the web. You can't say the same about Ruby (its been in Japanese for the last 8 years) or Python (the lead developer isn't interested in web programming) or practically any language. It seems like the choise was C or Perl, so someone wrote something in Perl to make their life easier. Now we've got people writing similar things for Ruby (Rails) and Python (Django) with the goal of making development of web apps easier.

Procedural programming which is much simpler for amateur programmers to learn and be productive. ... Probably the only hope for pure OO languages in the mainstream is code generation ...

I disagree. I think it takes time to make things simple, because simple is harder to do. I think procedural programming was made simple years ago, and object orientated programming is only starting to be made simple.

You can see the march towards simplicity in PHP. In PHP 4, you had to know about the differences between assigning by reference vs copying. In PHP 5, you can ignore that, and just use = whenever you like. It is becoming simpler to use.

I don't believe that using objects is inherantly more complicated than using ie MySQL result handles. But handles are simple enough so that we don't need to listen to people shouting "it uses the ResourceHandlePattern!" before we can use or understand them. It is just accepted, and to an extent hidden under the surface, just like assignment by reference is now hidden in PHP 5.

And hay, I can always use the grass is greener defence

Douglas

[bonefry]

It's the Purity vs. Utility argument and Utility repeatedly win much to your Purist chagrin. The reason there are no huge Python or Ruby support forums is that amateurs are just not going to learn languages like that. Probably the only hope for pure OO languages in the mainstream is code generation so that amateurs don't have to program.

I will give only 1 example here: http://www.phpbb.com/ VS http://www.vbulletin.com/

In my view phpBB represents utility. And yet there are webmasters that simply banned phpBB from their server for it's design flaws that lead to hacker attacks I think no other comments are needed.

Don't get upset about this, I don't want to offend you, but the Purity vs. Utility argument it is only available for programmers who don't give a <censored> about performance/security/scalability (I for one am like when it is all about receiving the money as fast as possible) or for designers that just started programming.

[Ezku]

Off Topic:

We don't need a Request or a Responce or Context or a Logger (which doesn't even write to a log? I don't get it) let alone a hundred IHandler's floating around.

Somehow I feel like taking this personally.

It felt like OO for the sake of OO, rather than trying to make a hypothetical PHP programmer's life easier, using tools which happened to include objects.

Personally, having once been an abysmally horrible application designer with only the faintest idea of code organisation, I felt it made my life much easier: I now have some good general guidelines as to how to approach problems, and I'd dare to guess at least some people here feel the same as me.

I hope I didn't really come off as a pedantic pattern aficionado. If I did, well... ouch.

[arborint]

Good post Chris, it is something that needs to be acknowledged. It reminds me somewhat of the "solve simple problems instead of hard ones" post at Loud Thinking

Thanks. I realize in rereading it that I am ranting a little more than I intended to;

Patterns, sure, use them in the code, but there isn't any need to structure the the building blocks along pattern lines. In associated tutorials which show how to use the classes and objects, say "XYZ bit of code uses ABC pattern like this: <example>" or even tutorials which focus on the patterns and use the code base as a source of examples would be cool. Saying "let's build a controller that can do anything and worry about using it in an applicaiton later" really turns me off, which is a reason I avoided the thread. I must have posted in it a couple of times though because I notice I'm subscribed to it

I agree with you on patterns and in a separate thread complaining about naming classes after some types of patterns (Structural patterns in that case). As for your comment about "let's build a controller that can do anything and worry about using it in an applicaiton later" in hindsight I agree and I think we have tempered that a little. Your input would be valuable in striking a balance between reasonable set of features and flex points, and when it is overkill.

So why build an application controller to get in the way of that?

My idea was that if procedural PHP programmers interested in OO could plug together a Front Controller and Application Controller with Model and View classes it would be a starting place. Even if they still wrote the same procedural scripts that the would have previously written, they would at least have some sound structure and clear depencencies. My goal was not to try to change the way they code, but to wrapper their code in some goodness so that the goodness slowly seeped into their code.

We don't need a Request or a Responce or Context or a Logger (which doesn't even write to a log? I don't get it) let alone a hundred IHandler's floating around.

Again, you input is appreciated. Perhaps a rewind and code review of the "skeleton" code is needed. I have been using my fork of the code on a project to actually see if it works and realize that it needs more work.

I disagree. I think it takes time to make things simple, because simple is harder to do. I think procedural programming was made simple years ago, and object orientated programming is only starting to be made simple.

You can see the march towards simplicity in PHP. In PHP 4, you had to know about the differences between assigning by reference vs copying. In PHP 5, you can ignore that, and just use = whenever you like. It is becoming simpler to use.

I don't believe that using objects is inherantly more complicated than using ie MySQL result handles. But handles are simple enough so that we don't need to listen to people shouting "it uses the ResourceHandlePattern!" before we can use or understand them. It is just accepted, and to an extent hidden under the surface, just like assignment by reference is now hidden in PHP 5.

I agree that PHP is getting better and easier to use with each release (having to pass references around to objects is an glaring annoyance in PHP4). Though I still think procedural is the way of amateurs because it allows programming with very little design. Whereas OO is really more a design methodology and less some language constructs.

[arborint]

I will give only 1 example here: http://www.phpbb.com/ VS http://www.vbulletin.com/

In my view phpBB represents utility. And yet there are webmasters that simply banned phpBB from their server for it's design flaws that lead to hacker attacks I think no other comments are needed.

Don't get upset about this, I don't want to offend you, but the Purity vs. Utility argument it is only available for programmers who don't give a <censored> about performance/security/scalability (I for one am like when it is all about receiving the money as fast as possible) or for designers that just started programming.

I agree with you from the narrow perspective of code quality. But the point you miss from the broad perspective is that
phpBB allowed probably millions of people to create billions of posts and communicate with each other. It was one of the many enabling programs that has helped move the web forward.

Honestly "performance/security/scalability" are not the only things that are important. For enterprise programs they may be critical, but again those are not the only kind of programs. What scripting languages show is that crap code is better than no code in creating progress in software. If only programs that met you approvial were allowed the web would have never happened.

[dreamscape]

In my view phpBB represents utility. And yet there are webmasters that simply banned phpBB from their server for it's design flaws that lead to hacker attacks I think no other comments are needed.

Are you trying to insinuate that phpBB is a security risk because it is largely procedural? That is what it sounds like.

[Dr Livingston]

but to wrapper their code in some goodness so that the goodness slowly seeped into their code.

You don't have seepage... You get leakage, and that is what it is. In my view, prodecural development has little scope for application design, and therefore, little skill is required.

That is why when I started out learning PHP I quickly realised that if I wanted more, if I was to be bigger, better, and bolder, I had to move to object oriented programming. You talk about me having views about procedural programming <> object oriented programming.

And, referring back to the earlier posting about Highlander,... There can only be one, and that my friend is object oriented programming. There is just way too many advantages of it, that it just can't be ignored.

As for those people who script spagetti code, sure there is a lot of that, and that is one of the short falls of PHP and it's ease of use. Like I said, anyone can use PHP, but alas, and this is a valid point, not everyone can develop.

Not so long ago I made the statement that some people see OO as a way of life, and others as a religion yes? Well I fall into the later category

[Dr Livingston]

Are you trying to insinuate that phpBB is a security risk because it is largely procedural? That is what it sounds like.

Yep, pretty much what I make of it as well, and guess what? There is proberly 99.999% truth in that statement.

Care to argue huh?

[McGruff]

Thread tools ---> unsubscribe from this thread. Phew.