SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 47 of 47
  1. #26
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,713
    Mentioned
    102 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by Czaries View Post
    I have been working on a project recently that I actually really do wish was just php4-style spaghetti php, because the supposed "object oriented" design really is that bad. That's painful and tough for me to say, because I myself am a huge proponent of using object oriented methodologies
    To help steer others away from bad ways of doing things, can you use your experience about how not to do things to highlight for is about the ways that OOP was used badly, and how they can be improved upon?
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  2. #27
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pmw57 View Post
    To help steer others away from bad ways of doing things, can you use your experience about how not to do things to highlight for is about the ways that OOP was used badly, and how they can be improved upon?
    Absolutely. Most of the problems stemmed simply from a lack of knowledge of basic programming principles and object oriented design methods.
    • Classes are used to stuff functions in for organizational purposes and called statically throughout the application.
      This creates a hard dependency on the class name itself, and eliminates any possibility of extension without modifying the code of class file itself, which is a huge no-no because it can have adverse consequences on the rest of your codebase that relies on it.
      Never use static method calls. The only valid use for static method calls is for singletons and (maybe) a registry. The reason is because they are extremely inflexible and create hard dependencies on the class name itself.

    • New objects are instantiated within functions of other objects instead of being passed into the function or object constructor upon instantiation.
      This creates hidden dependencies where objects you try to use out of the context of the larger application are dependent on several other objects and static classes you have to take along with you. Then those objects have hidden dependencies on others, etc. and the cycle continues until you end up just copying or referencing the entire code library to your new project.

    • There are no interfaces to enforce what controller or model methods are required for the section to function properly.
      People new to the project get extremely confused and irritated when something isn't working right and there is no code enforcement to help them figure it out - just weird and obscure errors that appear when you don't do things right.

    • Class hierarchies more than 5 levels deep in many cases.
      This is a huge point of contention between me and some of the other developers that setup the codebase. Essentially, every time a new section is created, they make an "Abstract" controller or model for that section that everything in that section will extend from (and I put it in quotes because the class is never actually defined as abstract in php). That new abstract class of course extends the subsection abstract class, which in turn extends the type abstract class, which extends the base abstract class for that type, which extends the base class. And no, I'm not kidding. Code re-use doesn't equal moving it down to a lower layer and creating more layers of abstraction.
      This makes it extremely frustrating to troubleshoot bugs and other issues when you have to trace the problem back 5 classes deep, and then can't change it because everything else extends from it, so you have to copy and paste(!) the whole function (sometimes without calling the parent) and make your modification in your concrete class for it to work. It's our built-in bug generation suite.


    There is so much more, but I don't really have time to continue. It's almost as if the original authors of the codebase read How to Write 3v1L, Untestable Code, thought it was serious instead of tongue-in-cheek, and followed every "suggestion" perfectly. A recipe for disaster.

  3. #28
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by PalaDolphin View Post
    Yes, but isn't OOP code w/o comments academic masturbation? Joomla code is my introduction to OOP PHP and it has nothing in the way of comments. It's open source, so check for yourself: Joomla version 1.5.15. It's like constructing a building with no blueprints.
    Public interfaces to methods etc should be commented when they are for use by the external public. The issue people have with comments internally is there is no enforcement on them keeping up to date, they drift and also remove the need for concise thought when naming and desiging classes, methods and variables etc. They effectively give a safety mechanism for not doing this. It takes a lot of though namingt and designating responsibilites well, sometimes a multiple of thought than the actual coding logic that uses them or is encased by them. The comment effectiveley becomes a brain splurge to get to the meat quicker. Hungarian notation has some similarities to this as it also becomes a crutch for bad naming, good naming removes it's need.

    On closed projects TDD removes the need for comments as assertion messages are used instead, unlike comments when the functionality changes they shout that it has changed and either the code needs to be fixed or the assertion ammended to reflect the change. It is semi forgivable to not update comments as they lack conciseness, vary on quality and appearance due to the writers belief on what is an important comment so end up being ignored. The more internal comments written the less value the real needed comments have( usually ones due to code that has to circumvent behavioural anomolies so looks wrong but should not be carelessley refactored). Quantity of internal comments due to a general need can be a sign that the code is obscure and needs reworking.

    TDD can also become a crutch for bad naming and implementation by the writer if they prioritise writing the test over those who will come back and read the test and code. Too much thought is directed in the wrong area, usually to get the test over and done with to get to the code. The test works but it is big and ugly, sometimes magnifying the over complicatedness of the code and sometimes just because of too much copy and paste. I don't know why sensibilities can change when it comes to tests or views but it seems to in some, readability goes out the window.

    Bad code( code that has distinctive code smells ) I do not trust without reading closely so I definitely do not trust it's comments, both rely on the ability of organising thoughts. Weakness in one implies weakness in the other. Writing comments for other people is no different than writing code for other people. The code is just the harder way.

    Comments on public interfaces are okay as when calling them IDE's display them( parameters, catachable exceptions and return types are very handy). It removes the need to enter the code and forcing someone to enter code and understand impleementation they do not need to is wasting their time and distracting them from their current task. In open projects this is more important as the users probably have very little instinctive ability with the code base until they become heavy users and have got to grips with it's coding conventions.

    Writing bad code with comments is far easier than writing good code without. What is good code and how to refactor towards it is a far bigger set of arguments with many opposing camps. Though there is a large concensus that code should read like english as much as possible, IDE's allow this as the speed benefit of terseness is greatly reduced.

    Not sure how the quality of Joomla is as a coding reference point. If you feel the need for a comment the question should be what is wrong with the code for it to be needed. It might seem academic in some ways but after a while the ugly in the code starts to show very quickly( before anything else is read ) and as comments can be seen as the collaborators of uglinesses stopping comments helps stop the ugliness. It causes headaches for the writers of the ugliness who use comments for crutches and a bit of discomfort can be very good for learning/rectifying behaviour. Personally I'd prefer a more direct dog whisperer approach as well but that is not embraced by common working culture.

    The developers of Joomla may of gained a pack instinct that has caused a shared instinctive understanding of what they communially write with little understanding of those who do not have that instinct, pack thought makes them believe comprehension of their code is easy. This is actually quite a common thing with any group of people, there would be a lot more arguments without it as it is a binding force.

    Black and white rules usually appear in teams as blanket reactions to commonly occuring problems that do not require thought while doing, it stops many creative resolves being formed without good backing argument. Like any blanket rule some may follow blindly incurring other problems while others will argue for refinement of the rule so those new problems will not occur or stop occuring. That refinement can become more of a political point within a team as it relies on everyone to think and agree. Not everyone really likes to think or being forced to think and will argue that is just the way we do things, sometimes possibly the reason was never really understood or maybe has now even been forgetten. Monkey see monkey do.

    Comments definitely are not architectural plans whatever their level of occurance. For an OOP coding style this may be quite interesting.
    http://blog.objectmentor.com/article...-till-you-drop

    Efficiency over readability is not something to be done lightly and should be a specific reaction to a specific problem that has been thoroughly explored. There is a higher level of comprehension at the moment of writing than a later moment of reading so that also has to be taken into account. If large amounts of effort are needed while writing in the now to sustain comprehension due to current eyeball level complexity, an impossible level may be required of someone reading in the future. This applies to procedural or OOP.

    Though as experience grows what was hard can now be easy and what was easy can now be hard in comparison so is definitely not a personal rule to set in stone as it requires constant personal revisement.

    I take too long to type stuff and a lot of it comes from reading material like Clean Code which has been mentioned earlier

  4. #29
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    Bangalore / Patna, India
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ah!
    Code reuse when there are lots of hierarchies. Those kind of code which goes down deeper and deeper into cannot even reuse for the project they have developed. Because no one dare to see and understand those project.
    but i know many people who like those kind of code in the name of modularity / code reuse etc

  5. #30
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've been doing some reading on this HipHop and it's not just a PHP to C++ compiler. It's a Web server replacing Apache. I'm not sure how many Web hosting companies would allow it to run.

  6. #31
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    To be honest, I think if you have the type of application where the idea of using hiphop becomes a reality, you are likely to be running a dedicated server anyway.

    C++ isn't web code on it's own - and without writing an apache extension, it wouldn't be able to interface with a web server, and there are several speed enhancements that can be gained from running the site as a separate application that listens on port 80 for traffic and responds accordingly. It can be optimised for the site in question rather than having to support many different possibilities and applications.

  7. #32
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's what it sounds like, currently.

    However, I've been involved in their group discussion and it sounds like they would appreciate some help incorporating this into the open source community.

    I have volunteered to re-write some PHP extensions in C to be thread-safe, since I've written UNIX and Windows device drivers. Converting some libraries to pure-functions, examining dependant function calls source code for their same pure-function support, using a mutex for share resourses, etc. Testing for dead-lock conditions, race conditions, and using stack instead of heap resourses, re-entrant functions calls, etc.

    Since it's contributing to the global open source community, it will be that much more rewarding.


    -=- Craig

  8. #33
    SitePoint Wizard gold trophysilver trophybronze trophy dc dalton's Avatar
    Join Date
    Nov 2004
    Location
    Right behind you, watching, always watching.
    Posts
    5,431
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As has been mentioned before blaming objects for the speed of an application is like blaming a car's rear view mirror for an engine missfire.

    The real problem is poor code built by programmers that don't really understand objects or for that fact databases.

    I've just hacked my way through a Joomla site and the code I found was nothing short of hideous and as pointed out by the OP their commenting is nothing short of a joke. Some people build 'objects' (for lack of a better description) just to build objects. I think they attempt this just because they heard objects are cool but when you look at these so-called objects you really have to wonder.

    I've done OOP in both Java and PHP for many a year now and have yet to see an object itself cause 'speed' issues (that's objects I have built). What I have seen in many of these OS projects is code that doesn't allow each part of the application to do it's own job. One example I can come up with off the top of my head is an object that retrieves and sorts data from a database when in fact the database itself can do this work 100 (if not 1000) times faster. Another that comes to mind is something another 'developer' asked me to look at. He needed to determine the age of someone using their birth date and the date they died (which came from the database). He had over 900 lines of code parsing the data six ways to Sunday when in fact it could have been done using the database in 4 lines of code.

    People that feel they have to 'reinvent the wheel' in their own objects when there is already a tried and true method of doing something cause a LOT of this slowness you see in some of these things.

  9. #34
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    Bangalore / Patna, India
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Facebook problem is something different.
    For normal site using source code is enough.
    PHP need not be parsed for every request, but for Facebook, they need to take care of lots of info and that changes to frequently.


    Quote Originally Posted by Stormrider View Post
    To be honest, I think if you have the type of application where the idea of using hiphop becomes a reality, you are likely to be running a dedicated server anyway.

    C++ isn't web code on it's own - and without writing an apache extension, it wouldn't be able to interface with a web server, and there are several speed enhancements that can be gained from running the site as a separate application that listens on port 80 for traffic and responds accordingly. It can be optimised for the site in question rather than having to support many different possibilities and applications.

  10. #35
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As has been mentioned before blaming objects for the speed of an application is like blaming a car's rear view mirror for an engine missfire.
    PHP's OOP approach is more like as the racing light turns green, let's start assembling an Indy car for a drag race, then disassemble it at the end of the race. Op code caching seems to address this problem though.

    I've just hacked my way through a Joomla site and the code I found was nothing short of hideous and as pointed out by the OP their commenting is nothing short of a joke. Some people build 'objects' (for lack of a better description) just to build objects. I think they attempt this just because they heard objects are cool but when you look at these so-called objects you really have to wonder.
    I agree. I've also, like you, come across questions at this site that demonstrated processing on data in PHP that should be done on the database server, as simple as counting rows.

  11. #36
    SitePoint Member omega2k's Avatar
    Join Date
    Feb 2010
    Location
    Ulm - Germany
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The real problem is poor code built by programmers that don't really understand objects or for that fact databases.
    thats the problem...

    i'm coding oop since php supports it and never had speed problems! if you are planning right and THEN implementing object oriented, nothing can go wrong and the project will be extendable and easy to handle...

    oop never is the problem, it's the "BUG" 25cm in front of the screen!

  12. #37
    SitePoint Enthusiast
    Join Date
    Jul 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OO was always slower than structural programming. However OO has other strong points. The same principles applies to PHP imho.

  13. #38
    SitePoint Enthusiast
    Join Date
    Jul 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is the use of classes and oo concepts in PHP. The same happens in c++. If you write the same program in simple c it runs faster than in c++ even if you use the same language. Object oriented programming introduce an extra layer that slows the program.

  14. #39
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by adiian View Post
    If you write the same program in simple c it runs faster than in c++ even if you use the same language.
    That is not true.

    Quote Originally Posted by adiian View Post
    Object oriented programming introduce an extra layer that slows the program.
    That is a gross oversimplification, bordering on being flat out wrong.

  15. #40
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sachinsiva View Post
    hi, I Have a small doubt....what is PHP OOP...?
    OOP is short for Object Oriented Programming. It generally refers to the use of classes and objects.

  16. #41
    SitePoint Enthusiast
    Join Date
    Nov 2008
    Posts
    29
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pmw57 View Post
    Working with big-ball-of-mud procedural code can easily end up costing more in development and testing time than when using OOP techniques.
    Possibly. But not all procedural code is bad and not all object orientated code is good.

    Stating OOP > procedural programming is a gross oversimplification of the whole issue.

    Quote Originally Posted by Stormrider View Post
    C++ isn't web code on it's own - and without writing an apache extension, it wouldn't be able to interface with a web server
    Of course it would. Have you never heard of CGI? Heck you could write a web application in assembly if you were crazy enough.

  17. #42
    SitePoint Addict Ramiro S's Avatar
    Join Date
    May 2003
    Posts
    321
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It is easy to theorize about these things but in the end it depends on this: is it practical or not.

    to continue with analogies it is like saying that since a Ferrari is fast it can save you much more time in a highway than a regular car. In theory, yes. Or saying "yeah! I can modify my car and compete in a F1 circuit" yeah.. maybe... but what's the point? is it worth the effort? Comparing raw speed against nothing is always a win.

    When people claims that C++ should be used in sites like Facebook... really? don't you think someone would have already tried it? speed is is important but is not the only thing to consider in a project... same for OOP.

    Small medium systems may not need full OOP capabilities... bigger systems yes, maybe.. it depends. Frameworks in the other hand provide a base platform but you are always conditioned by the framework's structure. There is no universal solution.
    Quasar - Web Development - Free Avatars

  18. #43
    SitePoint Enthusiast
    Join Date
    Nov 2008
    Posts
    29
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ramiro S View Post
    Small medium systems may not need full OOP capabilities... bigger systems yes, maybe.. it depends. Frameworks in the other hand provide a base platform but you are always conditioned by the framework's structure. There is no universal solution.
    That is a very good point.

    Just look at Linux (an an operating system, not just the kernel), the vast majority of that is written entirely in procedural C code. It works well because the design is good.

    Another important aspect is that it is perfectly possible to write object orientated code in procedural languages. It is quite common to see object orientated C programs (note: not C++). Just take a look at GLib.

  19. #44
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Much of this discussion has been mis-focused on OOP as the villain. I didn't say OOP is the problem. I said the combination of three techniques combined at launch time is not efficient. Haiping Zhao of Facebook found this same inefficiency and compiled PHP it into C++. That's a solution!

    But, the fact that #2 Web site that depends on PHP developers decided to go with the economic model found a need to decrease PHP's inherent inefficiency closed this thread, I think.

  20. #45
    Non-Member
    Join Date
    Jan 2010
    Posts
    13
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by PalaDolphin View Post
    Haiping Zhao of Facebook found this same inefficiency and compiled PHP it into C++. That's a solution!
    PHP is not for big sites like Facebook.

  21. #46
    SitePoint Enthusiast
    Join Date
    Jan 2010
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP is not for big sites like Facebook.
    Time will tell.

  22. #47
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,713
    Mentioned
    102 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by PalaDolphin View Post
    Time will tell.
    Time has told. FaceBook are using HipHop to compile their PHP code into C++ code instead.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript


Tags for this Thread

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
  •