SitePoint Sponsor

User Tag List

Results 1 to 14 of 14
  1. #1
    SitePoint Zealot
    Join Date
    Feb 2009
    Location
    Bristol
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    OOP Pattern Consequences

    We often talk about the merits of OOP - but we rarely discuss the consequences of employing design pattern (x). One of the things I liked in "Php Objects, Patterns and Practice was the fact that it clearly listed some of the negative consequences of deploying a pattern.

    So (while not wanting this to be an opportunity for procedural diehards to have a rant), let's hear some of the negative consequences of using OOP patterns/principles.

    i.e:
    Decoupling:

    Pros - classes are more testable, encapsulated
    Cons - decoupling can lead to a proliferation of classes, and send you on a merry journey through a class library...

  2. #2
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    IMNHO, decoupling is just good.

    Decoupling is an interesting one though, because it often clashes head on with duplication:
    PHP Code:
    // personel.php
    function raise_pay($staff$percent) {
        foreach (
    $staff as $person) {
            
    $person->pay *= (100 $percent)/100;
        }
    }

    // products.php
    function special_offer($price$reduction) {
        return 
    $price * (100 $reduction)/100;

    Aha! Nasty smelling code. Yuk. I'll hold my nose long enough to refactor...
    PHP Code:
    // personel.php
    function raise_pay($staff$percent) {
        foreach (
    $staff as $person) {
            
    $person->pay increase_by_percent($percent$person->pay);
        }
    }

    // products.php
    function special_offer($price$reduction) {
        return 
    increase_by_percent(-$reduction$price);
    }

    // percentages.php
    function increase_by_percent($percent$value) {
        return 
    $value * (100 $percent)/100;

    So before we had two independent modules that could be shipped separately. Now we have three modules and we have to ship or reuse them as two groups.

    Are pay rates and product offers really related?

    A couple of weeks later, once we've written a whole bunch of deployment scripts, someone points out that special offers are going to be a fixed amount off .

    If in doubt, decouple. Duplicated code is irritating and boring, but at least it's only irritating and boring. We are bored because we understand the code. We understand that we must repeat the changes and that's annoying. After a couple of times it's a no brainer to refactor. A good days work.

    Compare that with code that's coupled all over the place. Even getting to the point of understanding it is a serious problem. Often you cannot make any change for fear of the consequencies. Oh, if only I was only bored.

    Decoupling trumps duplication. Praise be to decoupling!

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  3. #3
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft View Post
    Decoupling trumps duplication.
    This is interesting to me. I'm thinking about how we as developers have the tendency to try and eradicate all duplication in our database tables, which results in needlessly complex schema.

    One test I remember some database guru mentioning is when there's duplication, imagine what should happen if one instance of the duplication needs to be changed. Lets say we have 10 people named "George" in the database. If one changes their name to Jerry, does that mean all the other names should change? Of course not. (Maybe not a realistic example, but you get the idea).

    This same test could be applied to code. In your example, if you had to change the way special offers were calculated, should you have to change the way pay raises are calculated? Of course not. Thus, there is no need to remove that duplication (because it's not really duplication).

    In a way, decoupling and removing duplication are two means to the same end: isolating change in your application.

  4. #4
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    This same test could be applied to code. In your example, if you had to change the way special offers were calculated, should you have to change the way pay raises are calculated? Of course not. Thus, there is no need to remove that duplication (because it's not really duplication).
    I think that Marcus actually meant to say that when he said:

    Quote Originally Posted by lastcraft View Post
    Are pay rates and product offers really related?

    A couple of weeks later, once we've written a whole bunch of deployment scripts, someone points out that special offers are going to be a fixed amount off .
    They're probably not related enough to remove the duplication, but if there is duplication, it's a small effort to factor it out and remove the duplication. If there's going to be a change (such as fixed amounts for efforts), you just change that part, and let the rest untouched.

    I'm not rigorous when it comes to duplication in the database, by the way: sometimes it's actually the best solution.
    Yes, I blog, too.

  5. #5
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Still tackling the low hanging fruit - Singleton is pretty much dead these days. Way too many disadvantages just to guarantee something is set up right. Even the original C++ world that originated this pattern came to ditch it, because you couldn't destroy the thing. If it's global you have no idea who else has a reference to it.

    I feel Registry will go the same way. Getting a big lump of objects arrive in your constructor is a it out of control. It's like trying to solve an Agatha Christie murder at the summer house when three busloads of tourists turned up just before the murder.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  6. #6
    SitePoint Zealot
    Join Date
    Feb 2009
    Location
    Bristol
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK, let's try another principle: Favour Composition over Inheritance. Are there any negative consequences?
    Personally, I'm going through a fair amount of strife working with a system that relies heavily on inheritance - the amound of black magic going on further up the inheritance tree makes it very hard to see what the specific class I'm working with is actually capable of. As a result, I'm finding it hard to think of cons...

  7. #7
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Well, Inheritance vs Composition is entirely situational and inheritance can be misused.

    If you really have real world concepts where objects are specialisations of a general type inheritance really is the better solution. It avoids code duplication (or wrapping methods).

    Then there's polymorphism...

  8. #8
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,399
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    In Java/.NET world we have a framework called "Spring". It's basically an implementation of OOP design patterns. It's the #1 most used framework in Java and that's saying a lot when there's 1000000 Java frameworks. Too bad for php programmers..hahahaha!

  9. #9
    SitePoint Guru
    Join Date
    Jun 2006
    Posts
    638
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I used Spring, something that can be done in 10 min under php takes 2h in Spring.
    Once you have a big site, to change anything means you need to update 8 files or more...
    (then again, pretty sure we were not using it right... i mean, that can't be right)

  10. #10
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sg707 View Post
    In Java/.NET world we have a framework called "Spring". It's basically an implementation of OOP design patterns. It's the #1 most used framework in Java and that's saying a lot when there's 1000000 Java frameworks. Too bad for php programmers..hahahaha!
    How is this supposed to be helpful?

    Maybe you could talk about why you think Spring is so successful. What does it have that other frameworks don't? What can we as PHP developers learn from the way it was built?

  11. #11
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,399
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    How is this supposed to be helpful?

    Maybe you could talk about why you think Spring is so successful. What does it have that other frameworks don't? What can we as PHP developers learn from the way it was built?
    First, there is no other framework that is similar and it's quite unique. People talk about patterns this and patterns that. At the end, that is just that.. a pattern w/o implementations. Also, within 1 pattern there could be 100000's of variations. I'm pretty sure you ask two developers to code in certain pattern and they'll be different. I'm pretty sure one implementation is more flexible or crappier. So, Spring Framework comes to a rescue in this manner. Just about any variation of certain patterns are already part of the framework. I don't think I can name all patterns use by spring... Singleton/Dependency Injection/Observable/Factory/AOP/Data Access Object/Service...probably more. This is just 1 benefits of Spring and there are many many many more. Like providing enterprise services. Example... database pooling, 2 phased trasaction, web framework, data transformation/integration, LDAP integration, cache management, web/rest services... I don't think I covered even 10% yet. Think why would VMWare buy this framework? It's because of it's "integration" value of this framework. This framework allows you to change third party library w/o changing single line of code. Anyways, it should be noted that this framework was sold to VMWare for hefty $500 mil and as I said #1 most used framework in Java. What's so magical about this framework is that the more you incorporate this framework the better your code gets.

  12. #12
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,399
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    If you're really curious then this book is recommended

    http://www.amazon.com/Spring-Recipes...5106957&sr=8-1

  13. #13
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,399
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Vali View Post
    I used Spring, something that can be done in 10 min under php takes 2h in Spring.
    Once you have a big site, to change anything means you need to update 8 files or more...
    (then again, pretty sure we were not using it right... i mean, that can't be right)
    in this case I advise RTFM..lol

  14. #14
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sg707 View Post
    Just about any variation of certain patterns are already part of the framework. I don't think I can name all patterns use by spring... Singleton/Dependency Injection/Observable/Factory/AOP/Data Access Object/Service...probably more.
    That doesn't sound like a benefit... sounds like an overuse of design patterns.

    I was hoping for more relevance to PHP... considering this is, you know, a PHP forum.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •