SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 60

Hybrid View

  1. #1
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    The OO perspective

    It is really quite amazing how different code looks when viewed from a procedural compared to an OO perspective. I saw this posted on a site:



    Which compares to the code I used in a recent project to do much the same thing:

    PHP Code:
    $items ItemsPeer::doSelect(new Criteria());
    foreach(
    $items as $item) {
        
    $item->write($writer);

    I'm sure the proedural is more efficient (I have Propel and Creole running in the back, my own XSL presentation layer in the front) but sheesh... the code is so different...

    Douglas

    PS: This probably shouldn't be in the advanced forum...
    Last edited by DougBTX; Nov 25, 2004 at 09:45.
    Hello World

  2. #2
    SitePoint Enthusiast feti's Avatar
    Join Date
    Jun 2004
    Location
    Northeastern Ohio
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I for one am willing to sacrifice speed for clean code. I'll take your OOP approach over the procedural approach anytime. I'm not saying OOP is the answer to everything, because it's not (e.g. shell scripting), but in most cases the code is easier to pickup and learn for me, not everybody though.

    However, less, cleaner code comes at a price. With the procedural code we know everything that's happening, because it's right in front of us. With your OOP example a lot of the tasks are abstracted within your main static call, and probably even more inside of that.
    feti
    Mojavi Project - Mojavi 3.0.0-dev available now!

  3. #3
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by feti
    e.g. shell scripting
    Take a look at Ruby for an OO option in this arena
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  4. #4
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Take a look at Ruby for an OO option in this arena
    Or Python =)

  5. #5
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by feti
    I for one am willing to sacrifice speed for clean code. I'll take your OOP approach over the procedural approach anytime. I'm not saying OOP is the answer to everything, because it's not (e.g. shell scripting), but in most cases the code is easier to pickup and learn for me, not everybody though.

    However, less, cleaner code comes at a price. With the procedural code we know everything that's happening, because it's right in front of us. With your OOP example a lot of the tasks are abstracted within your main static call, and probably even more inside of that.
    I agree here. Web languages like PHP were designed with maintainance / ease of use in mind due to the evolving nature of web applications, and the need for rapid development. If someone wanted speed, use C++ or ASM where one has to manage their own garbage collection (fun!).

  6. #6
    ********* 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 feti
    I for one am willing to sacrifice speed for clean code.
    This is also confusingly known as sacrificing efficiency for effectiveness. For a system that exists in a fairly fixed environment it is naturally tuned to just that task. Such code can be brittle though. When the requirements change you have to rewrite the lot. By sacrificing just a little upfront time for code that is easy for humans to edit, we end up with a more effective system for the real world.

    Quote Originally Posted by feti
    However, less, cleaner code comes at a price. With the procedural code we know everything that's happening, because it's right in front of us. With your OOP example a lot of the tasks are abstracted within your main static call, and probably even more inside of that.
    Someone on this forum came up with the inspired phrase "following the bouncing ball" to describe this. I would love to attribute them if I ever use it, but I can't rememeber who said it.

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

  7. #7
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    norway
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    It is really quite amazing how different code looks when viewed from a procedural compared to an OO perspective. I saw this posted on a site:

    ...

    Which compares to the code I used in a recent project to do much the same thing:
    Eh, this doesn't compare at all.
    Quote Originally Posted by DougBTX
    PS: This probably shouldn't be in the advanced forum...
    You are right about that.

  8. #8
    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 Aphenitry
    Eh, this doesn't compare at all.
    Sure it does, the functionality is identical. (From the point of view of the code that cares.)

    The type of flexibility is totally different though. One makes changes to this function's SQL very easy, the second makes changing the entire application's front and back ends very easy.

    That's an interesting comparison IMO, though one which has been done before

    Douglas
    Hello World

  9. #9
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    norway
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    Sure it does, the functionality is identical. (From the point of view of the code that cares.)
    No it's not, simply because you are using a procedual approach doesn't mean abstraction (or common sense) is out the window with it.

    In procland, the comparison to what you did would be something like:

    PHP Code:
    // criteria is a function
    $items itemsPeer_doSelectcriteria );
    foreach( 
    $items as $item ) {
      
    itemsPeer_write$item$writer );

    And by the way the code you posted is total garbage unless there's something I'm missing. Why not do something like while( $row = mysql_fetch... ) instead of that wierd for loop.. You are obviously comparing a framework that you've worked on and designed with atleast some care, unlike this example, which looks like the product of a common scriptkid that "knows his **** ("programming")".

    And if you don't know about function-pointers (you can do this in languages like C as well), check out http://www.function-pointer.org (though, you won't find much use for them using objects all the time - I'm just showing you it's there).

    And there is such a thing called unit (or module) testing in procland as well, McGruff. It's not exculselively for the oo-guys. In fact, it's been around since before object oriented languages took off. I wouldn't worry about any speed-differences, though.. Unless your framework requires 60 classes to be instanciated every page impression no matter what happened, but that would be your fault, not a required byproduct of using oop..
    I use oop in most of my projects, but there is a common misconception around here that procedual code automagically means ****code. I beg to differ.

    Anyway, let's not start a flamewar here, I just felt it was a really unresonable comparison.

  10. #10
    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 Aphenitry
    And there is such a thing called unit (or module) testing in procland as well, McGruff.
    Yes I know: but it is hard to unit test without well-defined units to test. I can't quite see how you can achieve this without OOP - or at least as well as you can with OOP.

    I've heard other people say that you can do object-oriented design without OOP and I'd be interested to learn more.

  11. #11
    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 Aphenitry
    Sure it does, the functionality is identical.
    No it's not, simply because you are using a procedual approach doesn't mean abstraction (or common sense) is out the window with it.
    If you thought that what I was saying equated to "procedural is cr**, use OO", then you are mistaken. I didn't mean anything of the sort.

    I was just a little surprised at the breadth of ways that something can be written in PHP. At one extreem you have code like in the screenshot, at the other end code like the example I posted. Then you can do things the way you posted - so many options, all achieving the same functionality: take data from database, echo data as HTML.

    Quote Originally Posted by josheli
    it's my biggest problem with OO. i'm too stupid to follow the ball more than 1 level and so i get lost in object land. in the original post for instance, i can look at the crappy procedural code and know instantly what it's doing. with the OO version, i have no idea what a Peer, criteria or writer is or does. i guess it's just a learning curve.
    I find the whole interaction quite interesting, I like the whole OO paradigm. A peer "peers" at the data (in this case items), only looking at data that fits a "criteria", which is then "written" to the HTML document... how each component works internally, that's a different story (the Peer and Criteria classes were written by thepeople at Propel, the Peer generated magically to look after my data. That means that it is all quite well documented and easy to use and manipulate. The writer class was written mostly by me, which means that the documentation is limited to say the least Suffice to say that it works using a simplified Visitor pattern.)

    Douglas
    Hello World

  12. #12
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not sure if there would be a speed issue here: could you even measure any difference there might be?

    There is a potential security issue if you are coding in the global scope (ie if reg globals is on and there are undefined vars).

    One huge benefit of encapsulation is unit testing - say goodbye to all the debugging problems that will turn up in global coding.

  13. #13
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    norway
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    By the way, you can see that the screenshot is taken from a Mac - that alone should tip you off that this isn't a worthy comparison.

    *duck*


  14. #14
    SitePoint Zealot
    Join Date
    Dec 2003
    Location
    with my kids
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Someone on this forum came up with the inspired phrase "following the bouncing ball" to describe this. I would love to attribute them if I ever use it, but I can't rememeber who said it.
    that would have been me:
    http://www.sitepoint.com/forums/show...37&postcount=7

    it's my biggest problem with OO. i'm too stupid to follow the ball more than 1 level and so i get lost in object land. in the original post for instance, i can look at the crappy procedural code and know instantly what it's doing. with the OO version, i have no idea what a Peer, criteria or writer is or does. i guess it's just a learning curve.

  15. #15
    Tranceoholic lilleman's Avatar
    Join Date
    Feb 2004
    Location
    Írebro, Sweden
    Posts
    2,716
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by josheli
    it's my biggest problem with OO. i'm too stupid to follow the ball more than 1 level and so i get lost in object land. in the original post for instance, i can look at the crappy procedural code and know instantly what it's doing. with the OO version, i have no idea what a Peer, criteria or writer is or does. i guess it's just a learning curve.
    You are not alone.

    Yours, Erik.

  16. #16
    SitePoint Member AlexBrina's Avatar
    Join Date
    Jul 2004
    Location
    office.bh.mg.br
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by josheli
    it's my biggest problem with OO. i'm too stupid to follow the ball more than 1 level and so i get lost in object land. in the original post for instance, i can look at the crappy procedural code and know instantly what it's doing. with the OO version, i have no idea what a Peer, criteria or writer is or does. i guess it's just a learning curve
    but if things are well NAMED and tested we minimize this problem to a reasonable level, we know what it does just reading the names, faster than procedural code.
    Alex Brina
    "...sempre q eu tirar a cabeša fora d'agua eu dou um al˘..." JC

  17. #17
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    norway
    Posts
    92
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes McGruff, unittests fits oo pretty well.. In php you don't have structs to group variables/pointers so you have to either use classes without methods, or use arrays. Modules are easy to define in procedual languages, but I wouldn't change from your habbits, not in php anyway
    Quote Originally Posted by feti
    I for one am willing to sacrifice speed for clean code.
    This is what I tried to comment earlier - thinking about speed in an environment such as this is just silly. If you use "lazy-includes" and code with care, this will really be negligible. It's a bit comparable to new people in C who is afraid to use functions because of the "overhead" it creates. In 99% of the cases this is total bull****.
    A good system (if the requirements allow it) wouldn't regenerate everything every page impression either, so in this case, it's even more pointless to think about it.
    Quote Originally Posted by josheli
    it's my biggest problem with OO. i'm too stupid to follow the ball more than 1 level and so i get lost in object land. in the original post for instance, i can look at the crappy procedural code and know instantly what it's doing. with the OO version, i have no idea what a Peer, criteria or writer is or does. i guess it's just a learning curve.
    How is that a learning-curve? Unless you've worked with the specific application, how could you know? It's no different than my procedual take on the problem (see earlier post) - do you instantly know what that does just because of the lack of "->"? Ofcourse as you get more proficient in a certain language/paradigm, you take new things more easily, but this isn't just restricted to object-oriented programming. "Peer" isn't universally defined, so you have to find out what it is/does one way or the other.
    I remember a few years ago I was making an opengl modelloader in C. Looking for resources, I found a J3d application which did it. Looking though it was a real strain, so I looked a bit further, and found a gtk-c version. It wasn't even complete, but was still very helpfull. It's not a completely fair comparison, because the J3d version did a lot more. But for small things, I don't mind a straight-forward procedual layout at all, atleast if the oop-version is a just "get/set" hell of "abstraction".

    You know what the first version does because everything is there in front of you, and the only functions that are used are well known to you. This is why documentation in heavily abstracted applications is a real requirement (i.e not something you do when you have some time left over) - both for you when you come back to it a year later and wonder "wtf a writer is", and for those that follow you.

  18. #18
    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 josheli
    i guess it's just a learning curve.
    Maby, maby not. Not everyone is good at maths, perhaps not everyone is good at OOP? Even if you are good at maths, you do still have to learn things which have been thought up before you so that you can take advantage of other people's ideas. I doubt that many people reinvent adding and subtracting when they are 6 years old - though some might, and you should watch ouut for them IMO Most people have to work at something to learn it, somepeoplelearn some things more easily than others... I hope we never reach a day when everyone is identical... though getting a bit off topic in my own topic. (Even the procedural vs OO comments are OT as far as I'm concerned though...)

    Douglas
    Hello World

  19. #19
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by josheli
    that would have been me:
    http://www.sitepoint.com/forums/show...37&postcount=7

    it's my biggest problem with OO. i'm too stupid to follow the ball more than 1 level and so i get lost in object land. in the original post for instance, i can look at the crappy procedural code and know instantly what it's doing. with the OO version, i have no idea what a Peer, criteria or writer is or does. i guess it's just a learning curve.
    As what's it's face said, naming things well is important. Ideally, you should translate things directly from what should be happening in human lanuages to PHP, or what ever....

    e.g.

    The Cat Sat on the mat.

    Nonus : Cat, Sat
    Verbs : Sat

    We can translate nouns into classes, and verbs/actions into class methods. Classes are normally names of things that represent real world objects. Real world objects interact with each other (i.e. Verbs).

    The use of the indefinate/definate article in front of nouns is an idication of should we use the class resolution operator or maybe create a new object (for 'a', indefinate article), the would normally use the indirection/dereferencing operator (->). This is a very loose way to translate things here though as this varies with circumstance.

    Words like on hint the communication between the nouns.

    We could say in PHP

    $cat->Sit($mat);

    Another example

    "I drove a car to work"

    ideally could look like something like this in code.

    $car = new Car();
    $car->drive($this, $work); // This translates to I in my decription and therefore would be a person object

    Of course this shows things at a very abstract point of view. Within methods like drive() you would repeat the process trying to break things down in a way so that describing how to drive is done in a way that easy translates back in a natural language.

    The other thing I find that helps is UML diagrams. A class diagram and a squence diagram will go a long way as you know roughly what is communicating with way in a quick visual fashion, so when you are reading code, you aren't trying to jump about so much, but instead focusing on things like the algorithm's used for the specific thing you want to be using. This sort of stuff can't be modelled in UML as such (well you could do flow diagrams for small specific areas). This is where code comments come in handy as well.

  20. #20
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think josheli points out something more significant than he knows. I honestly think that some people can better understand procedural code, others can better understand OO code, while most are somewhere in the middle. I don't think it is just learning curve. No matter how many times that AlexBrina, MiiJaySung or others say that OO is just clearer, it's really just clearer to them. I code mostly OOP for many reasons, but I don't still really don't see the "Cat Sat on the mat" quality that the vocally pro-OOP often quote as a great benefit.

  21. #21
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I think josheli points out something more significant than he knows. I honestly think that some people can better understand procedural code, others can better understand OO code, while most are somewhere in the middle.
    I find that PHP is inherently procedural, at least in the sense that native or user-written functions are interpreted line by line, call by call. If you happen to include() a file too late, of course you'll generate an error. PHP is not multi-threaded.

    I find the advantage in OOP is thinking about a process. (I'll call it a process, because the term "task" may be too confusing.) Something as (relatively) simple as pulling information from a database and inserting it into a page template involves several steps and can be separated as such. So the OOp programmer might use a Database connection object, a result set object, a template object and a "controller" object to tie together the disparate tasks each of those objects performs.

    I don't think it is just learning curve. No matter how many times that AlexBrina, MiiJaySung or others say that OO is just clearer, it's really just clearer to them.
    Perhaps what reduces clarity in many people's minds is that the whole process is not in one file. If you try to figure out what OOP code is doing, you have to read several files and look at where you enter and leave each class (or at laest its instantiation as an object) by means of method/function calls. In more complicated systems, that can be pretty daunting. I still lose my way sometimes, but I do like the granularity and elegance of it.
    Zealotry is contingent upon 100 posts and addiction 200?

  22. #22
    ********* 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
    ...but I don't still really don't see the "Cat Sat on the mat" quality that the vocally pro-OOP often quote as a great benefit.
    The point is that the domain model, expressed here as a glossary, can be more accurately expressed in OO. You will find that functions and methods change frequently depending on the application. The underlying core knowledge that evolves into domain objects coalesces around classes. It's the power of expression of this domain language that allows the application changes to more accurately map onto the business changes. It also cuts down on the mental translation step from requirement to code.

    It is not enough to "do" OO to achieve this. You have to be willing to live with a code base for a while and watch it factor out into something more powerful. OO is the enabler for this process.

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

  23. #23
    SitePoint Zealot
    Join Date
    Dec 2003
    Location
    with my kids
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    actually, I think my biggest hinderance to fully embracing "OO" is not with the architecture or design or understanding, but with the veiled condescencion and self-righteous superiority of so many of its crusaders.

    seriously now....

    but if things are well NAMED and tested we minimize this problem to a reasonable level, we know what it does just reading the names, faster than procedural code.
    I like the whole OO paradigm. A peer "peers" at the data (in this case items), only looking at data that fits a "criteria", which is then "written" to the HTML document
    How is that a learning-curve? Unless you've worked with the specific application, how could you know?
    This is why documentation in heavily abstracted applications is a real requirement
    so which is it? where does the rubber meet the road, documentation or naming? "hopefully both" you'll say. gotcha.

    I find that PHP is inherently procedural
    i find that the universe is inherently procedural. you know, the whole "if action then reaction" thing. an important claim for OO is that it helpfully maps our feeble human thought processes to some system. i tend to disagree.

    1. I'm hungry.
    2. If i open the pantry, I can get some food, else i can't
    3. I open the pantry.
    4. While scanning pantry contents....
    5. if red beets: continue; if peanut butter: yes!
    6. Determine peanut butter quantity
    7. If peanut butter quanity sufficient, break scanning and grab jar, else continue scanning
    .....etc.

    now the alternative....

    1. I'm hungry
    2. pantryfinder, find pantry
    3. pantry open thyself
    4. while pantry next shelf
    5. shelf, find food by name, name = "peanut butter"
    6. peanutbutter calculate quantity....

    i just don't think that the Object model captures our thought process as well as is claimed. in the real world, we don't ask objects to perform actions or to tell us their state, we usually determine them at "runtime" (while driving, while cooking, etc.), based on various conditions and thought procedures. real objects just don't have the actions the OO paradigm foists upon them. perhaps my thinking here is due to the fact that at work i mostly deal with what might be considered "Entity" objects: Region, SurveyRespondent, UnitOffice, ComplaintForm, Constituent, etc. and it ends up being a bunch of data containers and associated "Managers/Finders/Factories" (see, i do use OOP ).

    ok, the above rambling doesn't support my point very well, but maybe you get the idea?

    The point is that the domain model, expressed here as a glossary, can be more accurately expressed in OO.
    debatable i think.

    The underlying core knowledge that evolves into domain objects coalesces around classes. It's the power of expression of this domain language that allows the application changes to more accurately map onto the business changes. It also cuts down on the mental translation step from requirement to code.
    this actually addresses some of what i rambled on about above, and makes sense, maybe because these remarks are so different from the normal prosletyzing one hears about OO (i.e. the inherent silver bullet savior-ism of OO). still, it's difficult to follow the bouncing ball.

    another point/question/remark....

    YAGNI is a revered wiki item in object land, yet much of OO design is centered around JICYMNI (Just In Case You Might Need It). The most repeated version of this is the infamous "what if you want to change storage/databases/schema (or templates/views/clients)?"
    indeed, isn't much of the touting of abstraction and encapsulation about making it easier to change/maintain related components in the future? but i thought i wasn't going to need it?

    a final question:
    is it standard practice to instantiate an object in order to just subsequently "delete" it?
    Code:
    while($person = $personIterator->nextPerson()){
      $personMapper->delete($person);
    }
    sorry for hijacking the thread. fire away. (no studly capped wiki page references please )

  24. #24
    ********* 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 josheli
    actually, I think my biggest hinderance to fully embracing "OO" is not with the architecture or design or understanding, but with the veiled condescencion and self-righteous superiority of so many of its crusaders.
    And you wouldn't want to start a flame war or anything . The OOers are enthusiastic. That said I can be condescending of the attitude that procedural works for me, I couldn't get OO to work, so OO must be crap. This certainly hasn't happened in this thread of course, but both sides of the divide can give this kind of thread a bad name. If we all keep our cool, forget about all those other nasty threads we have seen and steer a course towards genuine difficulty we could end up with a good thread.

    Quote Originally Posted by josheli
    so which is it? where does the rubber meet the road, documentation or naming? "hopefully both" you'll say. gotcha.
    There are no best practices with programming, only good practices. Some combinations of those good practices will be contradictory. BTW, when the Cynefin (http://www.cynefin.net/) project becomes operation I'll be able to put this statement into greater perspective.

    Quote Originally Posted by josheli
    i find that the universe is inherently procedural. you know, the whole "if action then reaction" thing. an important claim for OO is that it helpfully maps our feeble human thought processes to some system. i tend to disagree.
    Wrong problem space.

    A lot of languages are heavily influenced by Fortran, a language built for producing very simple simulations of physical reality. Performance is critical for these simulations and they used to be run on minimal hardware, so complied Fortran and C are the norm.

    Quote Originally Posted by josheli
    i just don't think that the Object model captures our thought process as well as is claimed. in the real world, we don't ask objects to perform actions or to tell us their state, we usually determine them at "runtime" (while driving, while cooking, etc.),
    I think this is where your own argument loses coherence. Any physical object that does anything complicated, rather than simply be picked up and put down, more naturally follows OO. The cooker and the car you mention are good examples. You send a message to the cooker timer to start. You send a message to the cooker to start, or the car to start. The target of that message is important because the outcome will be different.

    You are using a model of a central intelligence (us) manipulating the world. That is roughly OK for simply cooking in your kitchen, but falls down badly when handling an organisation of people, unless it's some George Orwell nightmare. With multiple agents you need a different model of reality.

    Quote Originally Posted by josheli
    ...and it ends up being a bunch of data containers and associated "Managers/Finders/Factories" (see, i do use OOP ).
    If they ended up being data containers then I am afraid you didn't "use" OO, at least not to it's full potential. You are doing procedural programming with some bits of OO syntax to name data groups. That's still a start, but nothing like a breakthrough.

    Now I get rather stuck here because I cannot think of a way of saying the next bit without sounding condescending. The next stage you go to will be to forget about the data and start thinking about behaviour only. Data and functions as separate is a procedural programmers controlling intelligence view of the world and takes about a year to get rid of. In saying this I am implying that I am simply one step ahead of you and if you follow me up the ladder, dear disciple, all will be fine. That's the condescending part I cannot work around.

    My difficulty is because I do actually believe this .

    The enthusiastic OOers notice this affect at gut level. As the data fades away their brains have less to struggle with. The code becomes more of a bunch of intelligent lumps, rather than tools to be brought to the data. A procedural programmer has to completely understand the data structures. Easy for small projects, impossible for large ones or ones that change frequently. Quietly freed from this yoke, the budding OOer is suddenly capable of taking on much deeper problems, but without really understanding what has changed.

    I think that's why it isn't always expressed so well.

    Quote Originally Posted by josheli
    debatable i think.
    Yes, but I believe I can convince you that this is so in the area of enterprise applications.

    Be careful not to identify yourself as a non-OOer. I have seen people actively avoid learning OO because they have boxed themselves in by nailing their own egos to a public viewpoint. Once you outgrow procedural, that will only leave relational as a career path. You have to wear a tie for that life .

    Quote Originally Posted by josheli
    still, it's difficult to follow the bouncing ball.
    The resolution of this is to use the encapsulation in combination with good naming so atht you don't have to follow the ball at all. Again,you don't have to dig down to the data in the same way you do with procedural. Freed from this constraint, life gets easier.

    The catch is that OO is high discipline because of the naming and encapsulation care. Bad OO code can force you to trace code and the bouncing ball now makes things worse. This is partly why OO is usually peoples second paradigm. These disciplines are good for any programming and it takes a few years for them to become automatic enough that they don't present a barrier to moving toward OO.

    Quote Originally Posted by josheli
    YAGNI is a revered wiki item in object land, yet much of OO design is centered around JICYMNI (Just In Case You Might Need It).
    Reuse has given way to flex points and YAGNI is a reaction against the big design up front movement (this is not OO specific, e.g XML-RPC vs. SOAP). These movements are progressions. You wouldn't try to apply them all at the same time.

    Quote Originally Posted by josheli
    indeed, isn't much of the touting of abstraction and encapsulation about making it easier to change/maintain related components in the future? but i thought i wasn't going to need it?
    OO gives you the chance to add it in later when you do need it. It's no accident that refactoring has come from the OO camp. In exposing software development to the world of business it has to exist with an intrinsictly chaotic (in the mathematical sense) world. Plans survive only as long as the time it takes for competitors to adapt. The development team has to interface with this world, hence the rise of iterative processes so as to give the business options. Iterative development combined with a clean refactorable code base is what allows YAGNI to work. All of this is only now becoming mainstream. A lot of the other stuff is so last century .

    Quote Originally Posted by josheli
    a final question:
    is it standard practice to instantiate an object in order to just subsequently "delete" it?
    I personally don't like it, but I've seen it done both ways.

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

  25. #25
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think lastcraft and auricle are good examples of programmers for whom OOP matches their thought processes and allows them to think about and live with their code more effectively. Abstracting as domain models, glossaries and tasks clarifies things for them.

    Yet josheli says essentially the same thing is a much less fancy way when he states he, "can look at the procedural code and know instantly what it's doing." It allows him think about and live with his code more effectively. The concreteness clarifies things for him.

    One can understand the difficulty in communication between these two groups as they really can't think in the way the other group thinks.


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
  •