SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 82
  1. #26
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    norway
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    ...Then what youre saying applies to how you would develop with Java...
    It sure does.
    First, for regular websites, I most likely wouldn't be using java. Second, I still wouldn't abstract the sql out of the "application" - that's still killing a fly with a BFG9000..

    I'm not planning for year 3k when VR finally kicks inn and I can swiftly change my view with some OpenVR matrix-generator - rather I design things as modular as possible while still keeping it "sane" - I've used the same modules for several years now on different projects, and they are still working (By the way, a lot of them aren't classes *gaze*).

    Think "Good enough software", as discussed in the pragmatic programmer.

  2. #27
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    norway
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Maintenance is a huge issue. I'm constantly thinking about this when I'm coding.
    It certainly is, but that doesn't mean making everything in php a replica of java will automatically keep this to a minimum, which was the original topic of this thread.

  3. #28
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    Watford, UK
    Posts
    62
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi

    Interesting thread! Glad that no-one's complained it's not advanced enough.

    I'm moving away from accessors towards direct variable access at the moment. Because I'm fundamentally lazy. I'm justifying it to myself as - 'refactor if/when necessary', with the crutch of 'do the simplest thing that could possibly work'. The simplest thing, in a lot of cases, seems to be to use direct variable access rather than accessors.

    Accessors are our hedge against an uncertain future. Their value depends on your app's future - 'well one day name may mean something else/be calculated, I better use getName() instead'. More and more on the (fairly) short lifespan apps that I tend to be working on at the moment I'm moving towards the easier option. Of course this could come back and bite me in a couple of months, but I'm inclined to think not

    It just seems like extra typing. Surely they must be dead now with PHP5 and reflection? I haven't looked into it at all (lazy, like i said), but I can't believe that they can't be avoided entirely these days. There's more important things to worry about, surely ? Like templating and MVC?

    Cheers,

    Jon

  4. #29
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Your example is brilliant. It clearly shows that you CAN write the Java example in PHP, but you CANNOT write the PHP example in Java.

    And writing the Java example in PHP would only achieve slower code. In a more complex example there could be a reason, but not for the simple stuff that most PHP scripts need to do. When it comes to clarity or maintainablity are the 50 lines better than the 5 lines?
    Writing the Java example in PHP would result in database independant code and more depending on how far you want to take it, along with being slower.

    When it comes to maintainability and clarity, I much prefer to use a JDBC Style wrapper that is 50 lines (or whatever) in php because it results in me writing less code than just using php's functions in the long run. This post sums up my thoughts on that. The thread that post is in parrels this thread somewhat. Also of note is this post which I now agree with in many cases.

    Writing tightly refactored OO code simply results in writing less code that is more maintainable. This however doesnt mean that the original poster should use a Customer class, it depends on the application not the language.

    Quote Originally Posted by Aphenitry
    It sure does.
    First, for regular websites, I most likely wouldn't be using java. Second, I still wouldn't abstract the sql out of the "application" - that's still killing a fly with a BFG9000..
    Im not sure what youre refering to? "wouldn't abstract the sql out of the "application""?

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

    Quote Originally Posted by JonR
    I'm moving away from accessors towards direct variable access at the moment. Because I'm fundamentally lazy. I'm justifying it to myself as - 'refactor if/when necessary', with the crutch of 'do the simplest thing that could possibly work'. The simplest thing, in a lot of cases, seems to be to use direct variable access rather than accessors.
    Been there, done that, got constantly flea bitten really badly. Using __get() you can now write extra code around the worst attrocities regarding future hedging, but it ignores lot's of other issues...

    1) A large number of accessors is a sign that you should have a higher grain of parameter passing, such as a hash/object or grouping setters into single setters.
    2) A large number of accessors is a sign that the information is not where it's needed. Tell don't ask.
    3) A member interface is crippled. How would you apply a decorator around such an object without creating copies of all the data or resorting to overloading?
    4) Most objects are value objects, that is you want the getter only. You lose access control with exposed variables.
    5) When you are using such a class, you have to remember how the member is set. Using the getter convention is a more useful coding standard than where you place your braces.
    6) Accessing members inside members will expose a whole chain of implementations.

    One thing that annoys me about this thread is the accusation that the OO converts are building overblown castles in the air or self satisfying grandiose designs. Well I've done my share of procedural coding thanks very much, seven bloody years of it . When you end up conjouring OO concepts from C pointers you know you are on the wrong track . OO is not a theoretical construct like pure functional programming. It works in real life.

    The big advantage of OO is that you can express the business problem in the language of the code. Using procedures you have an extra mental translation step, similar to using relational databases. This means you will do the right thing more often. It means that fissures in the application will more accurately map to fissures in real life. This makes things easier to change. Because you develop a business language as you are solving the core problem, your project picks up speed as it progresses. This alone gives the order of magnitude productivity boost that gets you into the next level programming wise.

    OO code is smaller. Not for a twenty line script, but for real world projects. As you add code to a project you get reuse as commonality is factored out. With procedural techniques you will get a slight flattening of the growth curve as you break stuff into smaller functions. It follows a square root law in theory. With OO you will factor stuff in the same way for a while, but because of the expressiveness of the language you will come to realisations about your understanding of the problem. This is a dramatic effect, suddenly simplifying fast swathes of code. This is a virtuous circle, less code leading to greater understanding. In fact OO projects tend to flatten the code growth curve sharply, as the same code is just made more elegant to get extra features. They typically hit maximum LOC about half way through the project.

    The only reason to not use OO in a project (I mean almost no pure standalone functions) is because the skills don't exist in the team and the team won't be around for very long. It does take 1-2 years to "get" OO and it does require mentoring. You also have to have the will to refactor to get the full project benefit.

    I wouldn't dream of going backwards.

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

  6. #31
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think you miss the point Marcus and point out exactly the problem with OOP for OOPs sake developers like yourself. No one ever said code completely procdurally. You have build a straw man and cut it to pieces, who cares. The point that is being made is that coding 100% OOP like you and Brenden promote is simply not necessarily the best way to go in PHP. The position you oppose, by people like JonR, is the practical use of OOP and Structured programming together.

    You make a lot of points that are dubious at best:
    In OO you can express the business problem in the language of the code.
    I would really need to know what the heck you mean by "business problem" and "the language of the code" but it sounds like a fancy way of saying, "I like the way the OO code looks better."
    With procedural techniques you will get a slight flattening of the growth curve as you break stuff into smaller functions."
    SImply not true. Appropriate use associative arrays with functions gives you the same code reduction if not more that OOP.
    With OO you will factor stuff in the same way for a while, but because of the expressiveness of the language you will come to realisations about your understanding of the problem.
    If it works for you fine, but don't tell others that they can't find the same expressiveness and get the same realisations using using procedural code. I think the examples in #1 and #21 bear this out.
    This is a dramatic effect, suddenly simplifying fast swathes of code. This is a virtuous circle, less code leading to greater understanding. In fact OO projects tend to flatten the code growth curve sharply, as the same code is just made more elegant to get extra features. They typically hit maximum LOC about half way through the project.
    I find the opposite is true. I am more often refactoring out vast swaths of OO excess into simpler objects and code procedural code.

    I am a proponet of OOP, but I honestly think the All OOP route in PHP produces much more hidden class code and that code can be as brittle as any other code.

  7. #32
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Appropriate use associative arrays with functions gives you the same code reduction if not more that OOP.
    Here's an example from something I was working on yesterday. An array was being passed around different objects - it seemed like the simplest way to do what I wanted to do on the first draft. Writing the test (ahem, after writing the class..) amongst other things, nudged me into replacing the array with an iterator decorator subclass; also, a function which did something with the array was repeated in two different classes (on the principle of "resolve to a single source" that's a signal that something is wrong ).

    With the new class, and a couple of changes which followed on from that, a whole bunch of code dropped out of the script. The ArrayIterator and the IteratorDecorator base class were already being used elsewhere so the new class, derived from IteratorDecorator, only needed a handful of methods which were more than offset by the code which was lost. A net parsing gain and a better design to boot.

    If you have had a different experience it could be that the OOP code wasn't very good to begin with. There's plenty bad stuff about (I know: I've written some myself).

    I can understand why some people are sceptical about OOP. It wasn't so long ago that I was in the same position. But you can learn a lot on this board if you open your mind. Particularly from people like Lastcraft: if it's a strange religious cult he's promoting I'll sign away all my life savings and shave my head tomorrow.

  8. #33
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I started working on a commercial project while I was in school about a year ago. We started out hand coding DAO's for everything from inserts to updates to selects. About six months ago there was approx. 5000 lines (Alot of split lines of sql but..) of code in the DAO's only. This was impossible to maintain.. everytime we added a column to a database for a new feature or did any minor change was hand to change all kinds of lines of code.

    So, we moved to a partial OR mapper. It automatically does inserts, update, findById, findAll and deletes. Now using that system we have aprox. 2000 lines of code which includes code added for all the new features in that 6 months. Adding columns or changing the database is much easier since it is mapped and maintianing 2000 lines of code is much easier than the 7000 or so lines it would be had we stayed with hand coded DAOs.

    Soon we will be using a full ORMapper that will reduce the lines of code to do database access to approximatly 700.

    I would hate to think where we would be today had we just plopped mysql code any place we needed it and left it because it worked. Id love to know where Id be today had I just used a full OR Mapper from the start.

    This kind of story can be told about any area in programming (not just data access) when you start to refactor.

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

    Quote Originally Posted by arborint
    I think you miss the point Marcus and point out exactly the problem with OOP for OOPs sake developers like yourself. No one ever said code completely procedurally.
    On the contrary, that is exactly what I am trying to knife (in a friendly debating sort of way, of course). Using a Hybrid is like trying to mix concrete with bricks in. You can do it, but it's a lot more work and you won't be able to mold it into the shapes you want without a sledgehammer.

    It is useful in the early learning stages though. Trying to do a project completely OO will lead to brain overload if you haven't done it before. There is definitely a penance to be served.

    Quote Originally Posted by arborint
    I would really need to know what the heck you mean by "business problem" and "the language of the code" but it sounds like a fancy way of saying, "I like the way the OO code looks better."
    I not sure why you are asking this. I get to use this language every day and you must do to...
    PHP Code:
    $payment $payroll->calculateWages($contractor->getTmesheet());
    $contractor->notifyByEmail($payment->getReceipt());
    $payment->commit(); 
    Quote Originally Posted by arborint
    SImply not true. Appropriate use associative arrays with functions gives you the same code reduction if not more that OOP.
    Absolutely true in every project that I have ever worked on. Our current project is about 45KLOC of (OO Conway style) Perl, PHP and Ruby. It has been that size for two years.

    Quote Originally Posted by arborint
    If it works for you fine, but don't tell others that they can't find the same expressiveness and get the same realisations using using procedural code. I think the examples in #1 and #21 bear this out.
    They are not large enough to illustrate the difference. Some recent examples from my own experience...

    In our current project we have a group of classes that make up steps in a workflow. Using them is quite simply the job of transcribing a flow chart into a factory method. That code is so flexible it has been used in over a dozen places in the project and has now formed the backbone of a completely different project. It is an important piece of code to us and yet the four core classes are less than a hundred lines each. It used to be six classes and was just an iterator stream.

    It achieves this flexibility because every component you write for this system has to be a class matching the core interface. It's this that gives it plug compatibility and a hybrid solution would destroy all of the benefits. In fact I cannot think of a procedural system that would work as well. A Blackboard pattern with registered function names wouldn't be able to handle component setup without creating a bug farm.

    In case you are wondering, there is a lot more to these classes than I can describe in one post. If it sounds simple then I haven't explained it well. The main point is that the solution has shrunk, but gradually become more powerful.

    Another example is the web browser in SimpleTest. This code still hasn't gone through as much churn as I would like, but it's nearly reached it's maximum size. Adding frames support consisted of adding one (composite pattern) class and modifying about three existing methods. In the process I stripped out a whole load of code that had found itself duplicated in the HTTP request and underlaying UserAgent.

    Pretty much no extra code overall and yet frames support is a serious change of metaphor. Suddenly you have multiple requests and funny things happen when you click links, or get redirected, or have to authenticate, or...

    The struggle with adding this feature caused a new insight in where parts really belonged. What actually is UserAgent, or a BrowserHistory or a Page? Because it was OO, refactoring was then trivial. I just moved the methods and members to the right place. The semantics of procedural programming don't even allow the moving of data and code as a single lump. You'd have to fake it.

    OO code really does hit a ceiling and then even shrinks a little bit. I have seen it on every OO project I have been on and I have never seen this effect on a non-OO project.

    Quote Originally Posted by arborint
    I am a proponet of OOP, but I honestly think the All OOP route in PHP produces much more hidden class code and that code can be as brittle as any other code.
    PHP is not really the arena to see the best that OO has to offer.

    PHP is a language that has attracted a lot of beginners. I think that this is one of the wonderful things about PHP, that it is so accessable. Many projects would not currently exist if wasn't for this language. This does mean that many developers are learning their craft on this language. With the best will in the world, that will mean hybrid code that is barely more than compartmentalised procedural modules. That's a small upward step. It's not obvious what fine grain classes have to offer until you have tried them and lived with them on an application.

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

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

    Quote Originally Posted by McGruff
    ...if it's a strange religious cult he's promoting I'll sign away all my life savings and shave my head tomorrow.
    "Ah, my son...the wayeth of the future is helping out on requirements gathering tools that haveth on Sourceforge...."

    yours, Marcus

    "P.S. ...and thou caneth keep a full set of hair..."
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  11. #36
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You have no argument about the benefits of OOP. I am a believer.

    PHP is a language that has attracted a lot of beginners. I think that this is one of the wonderful things about PHP, that it is so accessable. Many projects would not currently exist if wasn't for this language. This does mean that many developers are learning their craft on this language. With the best will in the world, that will mean hybrid code that is barely more than compartmentalised procedural modules. That's a small upward step. It's not obvious what fine grain classes have to offer until you have tried them and lived with them on an application.
    You make my point and don't seem to know it. It's not the coding style or the craft that is important -- its the finished programs. The reason PHP excels at producing usable programs is that it allows procdural, mixed procedural/OO, and OO development.

    The important point I make above is that you could code the Java example in PHP, but you could not code the PHP example in Java. The fact that you can whip out a purely procedural, very maintainable email form in 5 minutes in PHP is unparalleled. The fact that you can create a full OOP architecture for an enterprise app in the same language is the strength of PHP.

  12. #37
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    The problem may be if you start off with an array and then decide you really need to change it to an object later. If you've used the array extensively in a production application, that's relatively hard to refactor.
    This is less so in PHP5: you can make a class act like an array. With the code: $something['key'], $something could be an array or a class.

    Douglas
    Hello World

  13. #38
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    (Sorry OT)

    Quote Originally Posted by lastcraft
    "Ah, my son...the wayeth of the future is helping out on requirements gathering tools that haveth on Sourceforge...."
    I feel I owe you & the SimpleTest team one. No make that 100. I really wish I could contribute but I'm under a lot of pressure with work. When I get a couple of days off at the weekend I try to keep some momentum going with my programming learning curve or catch up with anything needing done on a couple of not-for-profit sites I help out with. Once in a while I get a spare hour to grab some sleep...

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

    Quote Originally Posted by arborint
    You have no argument about the benefits of OOP. I am a believer.
    I've no doubt I have ended up at cross purposes. Hey, it's 4AM here .

    Quote Originally Posted by arborint
    You make my point and don't seem to know it. It's not the coding style or the craft that is important -- its the finished programs. The reason PHP excels at producing usable programs is that it allows procdural, mixed procedural/OO, and OO development.
    Just to clarify my own position...

    I think the difference is that you present them as a set of options, whereas I see them as steps in a learning process. Now for a very small project of N lines I could see a hybrid or procedural approach working just about OK. In that instance it's definitely optional, but then anything will work in this case. The thing is I see N as about 100, or in some cases 50. That definitely puts me in the object bigot camp of course.

    The problem is always that the program will get bigger. Programs are never "finished" even when they get blasted into orbit.

    One lesser and minor point. Java is a poor comparison to PHP because it's strongly typed and serves multiple requests from the same JVM. This has a major negative impact on it's usefulness for a single script, but that's nothing to do with it's OOness. I think that VB.NET, Python or Ruby would be a better comparison.

    Anyway, enough of the OO sales pitch . There is room for relational, functional and logic programming too. It's just that in our field they are currently niches, except perhaps for XSLT.

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

  15. #40
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    US
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    So, we moved to a partial OR mapper. It automatically does inserts, update, findById, findAll and deletes. Now using that system we have aprox. 2000 lines of code which includes code added for all the new features in that 6 months. Adding columns or changing the database is much easier since it is mapped and maintianing 2000 lines of code is much easier than the 7000 or so lines it would be had we stayed with hand coded DAOs.

    Soon we will be using a full ORMapper that will reduce the lines of code to do database access to approximatly 700.

    Can you explain more or give sample code about the partial or mapper, ORMapper?
    Thanks alot

  16. #41
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    But PHP and Java have such totally different libraries and environments that how you program is very different. Dynamic vs strongly typed is really only a small part of it.
    Libraries make little differences in building an application

    Quote Originally Posted by arborint
    Getters and setters are a prime example of OO brainwashing. Give me a reason to use getters and setters in the example above other than a love of function call overhead.
    Haha ... just because you don't understand the usefulness of getters and setters doesnt mean that it is brainwashing.

    Quote Originally Posted by Aphenitry
    although the general design could well be identical, you should still know the differences and how to exploit them (like the obvious fact that php is dynamically typed). Some languages have features others don't - take advantage of it.

    Though these things are mostly implementation details, when they add up, it could affect some decisions.
    Of course. And I said that static vs dynamic typing is something too look at. But they aren't so huge as to say it's nothihg like designing an app in Java.

    Quote Originally Posted by Aphenitry
    To me, smalltalk, obj-c, c++, php4 and perl aren't "pretty much the same"; just because a language supports the "class" keyword doesn't automagically make it equal to the rest.
    It's not just the class keyword. It's encapsulation, its information hiding, its public/private/protected items, its patterns of design. There are so many aspects of OOP that run across most all OOP languages that even though there are minor differences, they are basically the same when it comes down to it.

    Quote Originally Posted by Aphenitry
    Anyway, I'm not even sure if you were replying to my posts lazy_yogi, and I think we agree.
    No, it wasn't aimed at anyone specific. Just when everyone says you shouldn't look at Java design and implementaion becuase php is nothing like java - it's such a load.

    Quote Originally Posted by R. U. Serious
    If you take a look across the OO-Literature, you'll see that there isn't even a clear definition on what OO is. Are classes a necessity? Then what about prototype-based OO languages? Is Inheritance a necessity for OO or is it merely a way of achieving polymorphism? In the recent years a lot of researchers and practitioners frown upon implementation inheritance and put subtyping up there as the "one rightway", which doesn't really jive with a the experience of people from dynamically typed languages (see e.g.the Smalltalk Class hierarchies w.r.t. Dictionary inheriting from Set).
    I've seen books where garbage collection was declared as one of the key elements of an OO-Langauge.
    It took ~8 years for Java to finally get genericity, which is necessry for certain types of flexible OO designs (e.g. with Collections). And the Problem that genericity solves don't even exist in dynamically typed languages like Smalltalk, Python, PHP.
    And I could go on and on...
    Thank you for not. You start by defining what OOP is? Maybe you'd like to write a book on what defines OO? Lets get past the definition aspect you go into just so you can disagree with me. And what does garbage collection have to do with this discussion at all? If you have a point make it. Dont just add a whole load of stuffing so your response is too long for me to discuss point by point

    Quote Originally Posted by R. U. Serious
    What do you mean by "The patterns"? There are quiet a few patterns around that are needed to get around the deficiencies of certain languages (not OO in general); if you happen to be programming in a language that doesn't have that deficiency, you won't need the pattern. That's why it's important to really understand the patterns, instead of applying voodoo-programming where you're just throwing patterns at your code because you saw some other person do it.
    Heard of patterns such as singleton, command, iterator, visitor, etc... They were created to solve a group of problems, not a deficiency in the language. What deficiency in what language did iterator take care of? I'm not even going through the rest of your points unless you cut ths cr*p. I'm not here to waste my time arguing for the sake of arguing which you seem to like to do.

  17. #42
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Libraries make little differences in building an application
    Do you really think that the difference between the Java libraries and the PHP libraries doesn't makes a difference when implementing in each system? That is the difference.

    And yes, I understand and use getters and setters, and I also know when they are just overhead.
    What deficiency in what language did iterator take care of?
    The lack of a foreach statement obviously. Java is finally getting one in the next version because of the simple fact is that Iterators are, as you say, cr*p in many cases.

  18. #43
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    norway
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    Im not sure what youre refering to? "wouldn't abstract the sql out of the "application""?
    I'm sorry - ridiculus wording on my part. I'm saying I'd still probably directly access the tables from my code.
    If it was something bigger (or more ambitious), I might turn to code-generators etc.

    Quote Originally Posted by lazy_yogi
    But they aren't so huge as to say it's nothihg like designing an app in Java.
    Are you all living in an if/else world? I don't think anyone here is saying this.
    Quote Originally Posted by lazy_yogi
    It's not just the class keyword. It's encapsulation, its information hiding, its public/private/protected items, its patterns of design. There are so many aspects of OOP that run across most all OOP languages that even though there are minor differences, they are basically the same when it comes down to it.
    Does this include the encapsulation, information hiding and public/private/protected members of php4 (which is still the topic of this thread! (and just a few of the things php4 lacks))? Ofcourse you are free to program to an interface and use your "getters" in php4 - but you are in no way required. This isn't full encapsulation, it's just how you choose to access it.

    I'm not a procedual evangelist and like stated before I attack problems with an oo-mindset all the time. About the "overblown castles and grandiose designs", many php'ers came from nothing but "programming" html - ofcourse it affects their design, oo isn't something you learn by memorizing syntax, as you also comment. Can pure oo solutions be sexy? H%ll yes.

    While my main systemdesign is mostly objects interacting, I have things like utility-libraries which are just functions and works nicely - and they have for years. Just like I can still use printf and scanf in C++ without fainting.

    This thread is interesting, though a bit offtopic, but I feel a oo vs procedual holywar comming up - lets try to avoid it..

  19. #44
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Using a Hybrid is like trying to mix concrete with bricks in. You can do it, but it's a lot more work and you won't be able to mold it into the shapes you want without a sledgehammer.
    Yup, that's what a hybrid is like when you do it wrong. Here's how to make a good hybrid: you use concrete for the foundations, you use wood and tiles for the roof, and you use glass for the windows.

    I know you can do a lot with concrete, but have you ever tried looking through a concrete window?

    As for the learning process: it sounds to me like you've thrown away your spoon. That's the tool we all use when we learn to eat by ourselves. And when we grow older, we learn to eat with knife and fork. Now what the OO crowd tends to say, is that you shouldn't use a spoon, because you can do more with the fork and knife. They then proceed to eat everything that comes their way with knife and fork, and when they encounter soup, they start shouting "we need a better knife and fork!" (ie AOP ). But maybe it would be better if they looked back to their younger years, and realize that, even though a spoon isn't useful to carve meat, it's a great tool for eating soup.

    The point I'm trying to make?

    I think one of the main reasons why people tend to become zealous about OOP, is because they start out programming procedurally, and as they get better, they move on to OOD. And while programming OO, they progress even further, and are able to do solve more complex problems. Sure, part of this is because OO has a number of advantages over procedural coding, but the main reason is that they themselves have improved their skills.

    And if you've spent several years thinking OO, it's hard to switch back to procedural programming. But today, you could probably build a procedural application that's a lot more complex and efficient than theprocedural applications you wrote ten years ago....

    - - -

    I write hybrid code. I use static classes, functions, objects, even some (very limited) AOP. Why? Because whatever solution I choose for a problem, I try to pick whatever works best. I don't give a damn about what is commonly accepted or used, all I care about is solving the problems I'm facing with a solution that's as clean as possible.

    Rule #1 of programming:

    There are no rules, only guidelines and suggestions

  20. #45
    Rabble Rouser bronze trophy
    Join Date
    Jan 2003
    Location
    Mountain View, CA
    Posts
    427
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Hartmann
    With PHP should I be that narrow with my methods or should I broaden out the functionality to maybe something like getCustName()?
    It depends on how you want to interface with your customer. It can help if you write out the use first, that will dictate the interface; then you can get around to writing your class.

    If you change your mind later then it's probably not going to be too hard to change your class to suit.

    Off Topic:


    The semi-offtopic discussion was going fine, but it degenerated into a trolling holy-war long ago.

    Get over yourselves already and drop it.

  21. #46
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    OO is not a theoretical construct like pure functional programming. It works in real life.

    The big advantage of OO is that you can express the business problem in the language of the code.
    This is really a funny juxtaposition. Given that in LISP (being a functional language) it has for a veeery long time been possible do "morph" the language into a domain-specific language. That's the beauty of the lanugage: it is not necessary to have a committee define a new standard and then wait for some one to write a compiler etc.. You can simply extend the language to contain what you need with the language itself, including OO (Object Orientation has been added as a library). If you interested to find out http://www.google.com/search?q=lisp+...ic+language%22

    Otherwise I agree with a lot of Marcus (lastcraft) has said.

    But it seems that the OO-community has "framed" the concepts of re-usability or of encapsulation, abstraction and modularity. (Just as conservatices have framed patriotism as being something that is republican, which obviously is not the case). Encapsulation and abstraction have been concepts that were around and being used well before OO was invented. (As in Abstract Data Types and structural programming). It is possible to write re-usable software without OO. And it possible (and actually easy pretty - been there, done that) to write OO which is bad in terms of reusability and maintenance.

    @Brenden Vickery: Yes O/R-Mapping is great with larger projects. But it has its drawbacks, too, as you certainly know. While it makes life a lot easier on the programmers (because they can avoind the Object-Relational Mismatch), it can (although it not necessarily must) have detrimental effects on performance. It will depend on the complexity of the data that has to be stored, and how you need to access them.

    @lazy_yogi: What's up with the offensive tone? The things you wrote were obviously over-generalized (and thus wrong). If you don't even care to try understanding why I wrote any of the things I did, and just describe it as " crap", I truly don't see a basis for discussion. My time is too short for that kind of (non-)discussion either.


    Quote Originally Posted by Aphenitry
    This thread is interesting, though a bit offtopic, but I feel a oo vs procedual holywar comming up - lets try to avoid it..
    I wholeheartedly agree. And it's interesting how the original questions has been interpreted in several different ways. I took it to mean: is it necessary that the OO-Design that I will write in PHP hast to look exactly like the OO-Design that I will write in Java.

  22. #47
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    norway
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by R. U. Serious
    But it seems that the OO-community has "framed" the concepts of re-usability or of encapsulation, abstraction and modularity. (Just as conservatices have framed patriotism as being something that is republican, which obviously is not the case). Encapsulation and abstraction have been concepts that were around and being used well before OO was invented. (As in Abstract Data Types and structural programming). It is possible to write re-usable software without OO. And it possible (and actually easy pretty - been there, done that) to write OO which is bad in terms of reusability and maintenance.
    Exacly.

    Quote Originally Posted by R. U. Serious
    And it's interesting how the original questions has been interpreted in several different ways. I took it to mean: is it necessary that the OO-Design that I will write in PHP hast to look exactly like the OO-Design that I will write in Java.
    Right. I figured he wanted to know if it was possible to mirror his java-developmentstyle in php and if so if it was a smart move.

    And I don't know what's up with lazy_yogi's attitude-problem, either.

  23. #48
    chown linux:users\ /world Hartmann's Avatar
    Join Date
    Aug 2000
    Location
    Houston, TX, USA
    Posts
    6,455
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Alright, let me see if I can jumpstart this thread back into being on topic.

    The reason that I am wanting to use OOP is to make the shopping cart as modular and reusable as possible. The process that we have defined for a person using the site is pretty good and we feel that other companies could use something like what we are making (or something pretty close) and we want to make it as easy as possible for us to port it from one client to the next and be able to change the little things they need to make it work for them.

    I am all for procedural programming when the situation warrants it but I would think that what I am trying to do here would be a prime candidate for OOP.

  24. #49
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    we want to make it as easy as possible for us to port it from one client to the next and be able to change the little things they need to make it work for them.
    Your requirements have little to do with coding style. Clean data/code separation is what you need.

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

    Quote Originally Posted by arborint
    Clean data/code separation is what you need.


    You didn't mean that literally right? I cannot think of anything more disastrous. The whole reason for inventing OO in the first place is to hide the data so we work only with behaviour. You could "separate code from data" by making all of the data global, surely not what you mean.

    To be honest I think the statement is bogus in any case, but for the sake of not sending people off in completely the wrong direction, I think you should clarify.

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


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
  •