Method Chaining = Poor OOP practice?
Page 1 of 2 12 LastLast
Results 1 to 15 of 24

Thread: Method Chaining = Poor OOP practice?

  1. #1
    Senior Member
    Join Date
    Sep 2011
    Posts
    258

    Method Chaining = Poor OOP practice?

    Well I recently read an article from stackexchange, and it appears that Method Chaining is something to be prevented from establishing good OOP habits:
    http://programmers.stackexchange.com...-encapsulation

    Methods chaining breaks encapsulation, and violates the law of Demeter, thus should be avoided except on rare occasions. Seems like a good lesson to learn for many programmers, including me for sure, never thought Method Chaining was this detrimental to maintainable and adaptable code. Guess its about time to get rid of some bad habits, just like when one has to move away from procedural programming to OO programming. Not gonna be easy, but its necessary.

  2. #2
    PHP Witch laserlight's Avatar
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    13,568
    No, method chaining in itself does not violate the law of Demeter.

    In the example given, method chaining is used as syntactic sugar to obtain an object of class A, and then from that object obtain an object of class B, then of class C. This leads to tight coupling with classes that are not direct dependencies, hence the correct assertion that it violates the law of Demeter. I do not regard it as "breaking" encapsulation as long as only the interfaces provided by the various classes are involved. The thing is, even if you "unchain", so long as you are still calling those methods in the same scope, then you still have the same coupling. Thus, it is not method chaining in itself that violates the law of Demeter.

    Consider: I might have a class with methods that change its state, e.g., maybe it represents some kind of configuration for which methods are called to set the details of the configuration. I could then have these methods return the object reference, and thereby allow for method chaining as syntactic sugar. There is no added coupling here since only the class itself is involved. However, there is a reduction in encapsulation since there are more methods (i.e., more functions that may have to change if the implementation details of the class changes), but this is not the "fault" of allowing for method chaining.
    Last edited by laserlight; 08-21-2013 at 08:33 AM.
    Use Bazaar for your version control system
    Read the PHP Spellbook
    Learn How To Ask Questions The Smart Way

  3. #3
    Senior Member
    Join Date
    Mar 2009
    Posts
    812
    Quote Originally Posted by Lord Yggdrasill View Post
    ...just like when one has to move away from procedural programming to OO programming.
    Both procedural and object-oriented programming have their place; one is not better than the other and they are just tools in a very large toolbox.
    Declare variables, not war.

  4. #4
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    7,722
    Quote Originally Posted by Bonesnap View Post
    Both procedural and object-oriented programming have their place; one is not better than the other and they are just tools in a very large toolbox.
    Word.
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  5. #5
    Senior Member
    Join Date
    Sep 2011
    Posts
    258
    Quote Originally Posted by Bonesnap View Post
    Both procedural and object-oriented programming have their place; one is not better than the other and they are just tools in a very large toolbox.
    Well I do agree that both have their places, but it does not contradict with the fact that OOP was the better, more professional and more widely-used paradigm for applications with a certain degree of complexity. Even a prisoner has value in the world we live in, at some occasions he can make positive contribution to the society. Still apparently hes not as valuable to the world we live in as people like Steve Jobs, dont you think so? As far as I know, all professional/advanced programmers use OOP(or at least mostly OOP), only amateurs and hobbyists use procedural style to develop their sites.

  6. #6
    Senior Member
    Join Date
    Mar 2009
    Posts
    812
    Quote Originally Posted by Lord Yggdrasill View Post
    Well I do agree that both have their places, but it does not contradict with the fact that OOP was the better, more professional and more widely-used paradigm for applications with a certain degree of complexity. Even a prisoner has value in the world we live in, at some occasions he can make positive contribution to the society. Still apparently hes not as valuable to the world we live in as people like Steve Jobs, dont you think so?
    That's totally subjective, though. How do you define "better"? How do you define "certain degree of complexity"? Sorry, I don't see how your comparison of a prisoner to Steve Jobs applies here. You're immediately attributing procedural programming to a prisoner, applying a negative bias to it and implying that it's limited in its value, whereas object-oriented programming has by default tremendous value. I think you're putting too much stock into the methodology here rather than other aspects of programming itself. You can be a terrible programmer but still write object-oriented code. Likewise, you can be a terrific programmer but write procedural code.

    Quote Originally Posted by Lord Yggdrasill View Post
    As far as I know, all professional/advanced programmers use OOP(or at least mostly OOP), only amateurs and hobbyists use procedural style to develop their sites."
    Then I guess I am not a professional/advanced programmer. I prefer to think though that a professional/advanced programmer would recognize a scenario where one approach is better than another. AKA, when a procedural approach is better than an object-oriented one, or vice versa. I use object-oriented programming when I believe the situation warrants it. I find too often people go out of their way to write object-oriented code for no reason other than "it's professional". Don't forget HTTP is a stateless protocol - object-oriented PHP is already at a disadvantage there.
    Declare variables, not war.

  7. #7
    Pedantic Curmudgeon Weedpacket's Avatar
    Join Date
    Aug 2002
    Location
    General Systems Vehicle "Thrilled To Be Here"
    Posts
    21,904
    http://people.csail.mit.edu/gregs/ll.../msg03277.html

    The venerable master Qc Na was walking with his student, Anton. Hoping to
    prompt the master into a discussion, Anton said "Master, I have heard that
    objects are a very good thing - is this true?" Qc Na looked pityingly at
    his student and replied, "Foolish pupil - objects are merely a poor man's
    closures."

    Chastised, Anton took his leave from his master and returned to his cell,
    intent on studying closures. He carefully read the entire "Lambda: The
    Ultimate..." series of papers and its cousins, and implemented a small
    Scheme interpreter with a closure-based object system. He learned much, and
    looked forward to informing his master of his progress.

    On his next walk with Qc Na, Anton attempted to impress his master by
    saying "Master, I have diligently studied the matter, and now understand
    that objects are truly a poor man's closures." Qc Na responded by hitting
    Anton with his stick, saying "When will you learn? Closures are a poor man's
    object." At that moment, Anton became enlightened.
    THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER
    FAQs! FAQs! FAQs! Most forums have them!
    Search - Debugging 101 - Collected Solutions - General Guidelines - Getting help at all

  8. #8
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    13,973
    And don't forget about aspect-oriented programming.
    Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be." ~ from Nation, by Terry Pratchett

    "But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because hes a better programmer now!" ~ http://www.oreillynet.com/ruby/blog/...ck_to_p_1.html


    eBookworm.us

  9. #9
    Senior Member
    Join Date
    Sep 2011
    Posts
    258
    Well according to the book Pro PHP Refactoring, there are five general code smells one can identify:

    1. Difficulty understanding or following the logic of code.
    2. Many inline comments within the code.
    3. Inability to add new features for fear of introducing bugs.
    4. Lots of files with thousands of lines of code.
    5. Procedural code.

    As you see, procedural programming is indeed considered a bad coding practice, its classified as one of the five bad smells in a program. Cant it be more obvious that OOP is the way better approach to go compared to procedural programming?

  10. #10
    PHP Witch laserlight's Avatar
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    13,568
    Quote Originally Posted by Lord Yggdrasill
    Well according to the book Pro PHP Refactoring, there are five general code smells one can identify:

    1. Difficulty understanding or following the logic of code.
    2. Many inline comments within the code.
    3. Inability to add new features for fear of introducing bugs.
    4. Lots of files with thousands of lines of code.
    5. Procedural code.

    As you see, procedural programming is indeed considered a bad coding practice, its classified as one of the five bad smells in a program. Cant it be more obvious that OOP is the way better approach to go compared to procedural programming?
    Just because you wrote a book does not mean that you are right. Furthermore, even if you are right, that does not mean that your readers cannot take what you wrote out of context

    In the given list, #1 and #3 are obviously "code smells". #2 and #4 are too, but I would expect some explanation from the authors as to why (and in fact they are related to #1 and #3).

    Is #5 a "code smell"? I'd say that it depends on factors like the problem domain and the size of the program. Certain problem domains may lend themselves better to one paradigm than another. As the size of the program increases, I would say that it becomes more likely that the code's complexity can be better managed with the aid of object oriented design, in which case extensive procedural programming could then be a "code smell".

    Does this mean that procedural programming is a bad coding practice? No, it does not. What it means is that under certain circumstances, the presence of a significant portion of code written in procedural style would be an indicator of design that could be improved, i.e., a "code smell".
    Use Bazaar for your version control system
    Read the PHP Spellbook
    Learn How To Ask Questions The Smart Way

  11. #11
    Pedantic Curmudgeon Weedpacket's Avatar
    Join Date
    Aug 2002
    Location
    General Systems Vehicle "Thrilled To Be Here"
    Posts
    21,904
    Quote Originally Posted by Lord Yggdrasill
    4. Lots of files with thousands of lines of code.
    As opposed to what? Thousands of files with lots of lines of code?

    Quote Originally Posted by Lord Yggdrasill
    its classified as one of the five bad smells in a program.
    By that particular author. There are many other ways for code to smell.

    From the same site as above: Can Law Of Demeter Be Refactored Automatically? The answer is that it depends on whether you think it MUST be respected: if the answer is "yes", then it can be and is therefore not something programmers should need to think about.
    Last edited by Weedpacket; 09-03-2013 at 06:08 AM.
    THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER
    FAQs! FAQs! FAQs! Most forums have them!
    Search - Debugging 101 - Collected Solutions - General Guidelines - Getting help at all

  12. #12
    Senior Member
    Join Date
    Mar 2009
    Posts
    812
    Quote Originally Posted by Lord Yggdrasill View Post
    Well according to the book Pro PHP Refactoring, there are five general code smells one can identify:

    1. Difficulty understanding or following the logic of code.
    2. Many inline comments within the code.
    3. Inability to add new features for fear of introducing bugs.
    4. Lots of files with thousands of lines of code.
    5. Procedural code.

    As you see, procedural programming is indeed considered a bad coding practice, its classified as one of the five bad smells in a program. Cant it be more obvious that OOP is the way better approach to go compared to procedural programming?
    That's just one book with one opinion, though, and I feel that these items need a little more elaboration. For instance, numbers 2 and 4 need some more explanation. I like inline comments. Indeed, too many can be annoying, but again I think this goes back to the professional/advanced programmer knowing when and where to add them. In the end, I never write code for the computer; I write it for myself and to a lesser extent, my coworkers. I think comments (especially inline comments) can go a long way in making that easier. Or maybe I'm just misinterpreting what the author means by inline comments.

    Also I think number 4 doesn't make much sense. Either you have lots of code in few files, or few files with lots of code. It really depends on the project, and I think it's too general a statement.

    In the end, different scenarios call for different approaches.
    Declare variables, not war.

  13. #13
    Senior Member traq's Avatar
    Join Date
    Jun 2011
    Location
    so.Cal
    Posts
    949
    Quote Originally Posted by Bonesnap View Post
    maybe I'm just misinterpreting what the author means by inline comments.
    I think the implication is that the program flow is difficult to follow, and so requires a running commentary in order to make any sense of it. I agree in that case; though I certainly don't agree that code comments are a bad thing in and of themselves.

  14. #14
    Pedantic Curmudgeon Weedpacket's Avatar
    Join Date
    Aug 2002
    Location
    General Systems Vehicle "Thrilled To Be Here"
    Posts
    21,904
    Quote Originally Posted by traq
    I think the implication is that the program flow is difficult to follow, and so requires a running commentary in order to make any sense of it. I agree in that case; though I certainly don't agree that code comments are a bad thing in and of themselves.
    I agree here, too; the code should be clear enough for a reader to be able to follow what it's (supposed to be!) doing. The comments provide existential justification.

    There is another category or two of inline comment that I find annoying - I've started calling it "coder scat" after embarking on a project that involves clearing out five years' worth of the stuff.
    Code:
    // Updated 6/3/2008 JRCoder
    which might have been useful in early 2008 (or maybe it was mid-2008) to JRCoder - whoever JRCoder was; and
    Code:
    // ++
    ....
    // --
    THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER
    FAQs! FAQs! FAQs! Most forums have them!
    Search - Debugging 101 - Collected Solutions - General Guidelines - Getting help at all

  15. #15
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    7,722
    Quote Originally Posted by c2.com Wiki
    ...And therefore a CodeSmell is a hint of possible bad practice to a pragmatist, but a sure sign of bad practice to a purist.
    I think the whole issue here is that someone is young enough, or thinks he's young enough, to still be a "purist".
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

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