SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 52
  1. #26
    SitePoint Zealot
    Join Date
    May 2003
    Posts
    164
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by frank1 View Post
    one truth is that, when php started it was known for its simplicity....so every body jumped in....web programming was never so easy....

    then the traditional programmer(java,perl,C) saw great fan following with php....and they decided to turn php to other programming language..(like C ,java,.NET and some others...)

    They were some how able to convince people that their way of programming(JAVA,C etc) would bring more power to PHP....the main people or most php people got convinced...and we could see whole php is changing into other language especially in the name of frameworks....

    May be the so called OOP way (which was being used in other languages like java) was able to add some power but every one forget that that so called power was gained at the cost of simplicity....

    For eg when a traditional php programmer sees jooma's code or may be symfony framework's code...she asks...is it really php? or she is not able to program straight away...

    so i fear some day,java coding and php coding will be same....(at least in structure and way)

    if some body ask me,i think php people should be first thought how to gain power retaining the simplicity...rather than opting for C,JAVA OOP style directly....

    and to be frank most of these frameworks and all are based on microsoft .net framework concept...(they are brining what is being done in .net as tools and naming it framework...for eg CRUD operations and validations..and many more...)

    so people are changing php in the name of OOP ....which may be good...but every one is forgetting about simplicity....where the real pwer of the php lie..and php is turing into other languages....

    i imagine if somebody could have brought those features(what is done in good OOP) in traditional fashion without losing simplicity,php would have been one the most powerful language for ever....
    the simplicity wasnt necessarily in the language but in its paradigm. PHP was as procedural as C was.

    similar challenges that were faced when "C saw the necessity to evolve to C++" also later applied to PHP. The major difference between old PHP and new PHP is support for OO and the changes in it that make it also Object Based. Its the terms that seem to complicate concepts that are rather simple to understand.

    OOP supports Object Oriented Design...which is just a sophisticated word for solving (computer) problems using real-life analogies. A person has hands, feet, lips that hold,walk,kissand speak. The person is tall,slender,charming and cute. The person is the object, the rest are methods/properties and data.

    If you find Joomla and other CMSs and frameworks difficult to understand, it isnt really the concept that's difficult but the way it was implemented and the way in which you grasp it.

    my 2c
    Elgg Customisation & Theme development
    Modx Custom Development
    PHP programming

  2. #27
    SitePoint Guru rageh's Avatar
    Join Date
    Apr 2006
    Location
    London, Formerly Somalia
    Posts
    612
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Coding in OOP is another way to do things. You learn things from another angle. And more importantly, it will be a nice addition to your skillset. OOp also adds structure to your code. And that alone is very important. But I must emphasise that one has to really learn OOP methodolgies thoroughly before trying. The benefit will be many-folds.
    ------------------

  3. #28
    SitePoint Addict
    Join Date
    Jan 2008
    Location
    Shaw AFB
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I definitely saw the benefits of OOP and MVC when I started learning CodeIgniter.
    ~ Nate L ~

  4. #29
    SitePoint Wizard frank1's Avatar
    Join Date
    Oct 2005
    Posts
    1,392
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tinonetic View Post
    the simplicity wasnt necessarily in the language but in its paradigm. PHP was as procedural as C was.

    similar challenges that were faced when "C saw the necessity to evolve to C++" also later applied to PHP. The major difference between old PHP and new PHP is support for OO and the changes in it that make it also Object Based. Its the terms that seem to complicate concepts that are rather simple to understand.

    OOP supports Object Oriented Design...which is just a sophisticated word for solving (computer) problems using real-life analogies. A person has hands, feet, lips that hold,walk,kissand speak. The person is tall,slender,charming and cute. The person is the object, the rest are methods/properties and data.

    If you find Joomla and other CMSs and frameworks difficult to understand, it isnt really the concept that's difficult but the way it was implemented and the way in which you grasp it.

    my 2c
    thanks for thoughts

    first thing ,i am not trying to say OOP may not be better than procedural approach.Well,there may be debate.....but rather than plunging php into other OOP style of other language.....would not it have been better if people have thought, "could that oop benefits brought into php in traditional style without losing simplicity?"....that is what i am trying to say....

    now the php4 and php5 programming completely looks different....way things are organized ...way programmers things...

    so rather than upgrade it was total change

    lets take an example...
    php was suppose x years old guy....now he was growing and developing in process....but all of the sudden now some so called elite people(father) brought some another guy(java,.net...) and said..."ok from next year ,you will call this new guy php(not the guy which was growing)".

    this excatly is the case....

    and people may or may not agree with me...but many people are doing javalization,.netlization,c++lization of php....

    it may have introduced some benefits...but we forgot the oppurtunity cost....rather than copying other's style...if php was able to introduce those features/benefits on its own way ,with the simplicity for what php is known for,php would have been king of web programming....

    many people even me can see what can be done in oop can be done in traditional way(with out following java style...)
    but one sad thing is that...now php main developers themselves seems to be convinced that OOP and other language's style is the future of php...which is really not good...

  5. #30
    SitePoint Wizard frank1's Avatar
    Join Date
    Oct 2005
    Posts
    1,392
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by NateL View Post
    I definitely saw the benefits of OOP and MVC when I started learning CodeIgniter.
    my personal experice codeigniter seems to be much novice infront of cakephp.....

    i tried both ...just personal thought....

    and i think symfony is unnecessarily complicated....

    and zend framework is .net version of php...

    personal thought from experience

  6. #31
    SitePoint Member
    Join Date
    Aug 2009
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think there's a more important question you should ask to help you decide:

    "What type of site are you developing?"

    If you're a freelancer working solo to crank out small sites to tight deadlines - e.g. a 5 page brochure or even a site with a small admin section, then procedural PHP is fine (or OOP if you keep it simple). TomB's example was great.

    If you're web 'site' is turning more into a complex web 'application', then OOP.

    You'd be doing yourself a favour either way to learn OOP. You become a better programmer and if you build a few sites to grasp the basics of OOP you'll save yourself headaches down the line if you start using an MVC framework like Zend, Symfony, or any other language.

    With OOP you open up a range of proven design patterns (MVC, factories, etc. etc.) that are proven solutions to common programming problems and would be unavailable with procedural programming.

    The learning curve is a bit steeper but the long term pay off is definitely worth it.

  7. #32
    SitePoint Enthusiast Codebox's Avatar
    Join Date
    Jan 2004
    Posts
    78
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One thing that I would like to mention is that OOP encourages a thought process that is similar to our natural way of thinking. This means that you can easily architect an application in a nice manner if you use OOP concepts.

    OOP provides mechanisms such as data hiding and polymorphism plus inheritance is a cool thing to have too.

    Complex systems are preferably built using OOP methodology because the design principles of OOP enable easy modification and readability and component based programming model - which is not as convenient in traditional procedural programming as it is in OOP.

  8. #33
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by frank1 View Post
    thanks for thoughts

    many people even me can see what can be done in oop can be done in traditional way(with out following java style...)
    but one sad thing is that...now php main developers themselves seems to be convinced that OOP and other language's style is the future of php...which is really not good...
    Why is that not a good thing? I can go easily from programming in PHP to programming in Java or C++ because the share the same principles. Why would php try to reinvent the wheel when there are known, tried and tested methodologies which have evolved over the last 20+ years? Hell there's a lot in other OO languages which PHP doesn't support (multiple inheritance, overloading, design by contract)

  9. #34
    SitePoint Addict reboltutorial's Avatar
    Join Date
    Jan 2009
    Posts
    309
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A funny analogy:

    “In order to solve some of the deepest mysteries of the universe, the rules that govern large objects like galaxies must be combined with the rules that govern small objects like subatomic particles.”

    Source: NOVA – The Elegant Universe By Brian Greene , String Theorist
    http://www.pbs.org/wgbh/nova/elegant/program.html

    “In order to solve some of the deepest complexities of software engineering, the rules that govern large systems like groupware systems must be combined with the rules that govern small objects like classes.”

    Me: http://bit.ly/megut

    More concretely, you have to mix both, so next trend is FP + OOP like in Scala (the future of Java) or Rebol since inception 10 years ago already.

    Today the use of OOP (kind of non-linear stuff) alone is a daily battle with a lot of tools to compensate the lack of Functional Programming (new sexy name for old procedural or sequential or linear stuff).

  10. #35
    SitePoint Wizard frank1's Avatar
    Join Date
    Oct 2005
    Posts
    1,392
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Why is that not a good thing? I can go easily from programming in PHP to programming in Java or C++ because the share the same principles. Why would php try to reinvent the wheel when there are known, tried and tested methodologies which have evolved over the last 20+ years? Hell there's a lot in other OO languages which PHP doesn't support (multiple inheritance, overloading, design by contract)
    it may be very good thing from one prespect ...but every one is discouraging the use traditional php ...and the language itself is going oop way with less support and encouragement for the people who started php with traditional way(with out oop backgroud...) so i mean bad for them....now they dont have any other option rather than joining the band...

    for reinvent: even when there was no OOP php people were able to get resuability in their code...through functions...libraries and all so it is not that oop automatically eradicates reinventing.....for eg with out late static binding(before php 5.2) one has to have same functions suppose insert,update,delete on each class...(cannot make it generic...in database class)
    so we opted for oop way styles rather than investigating if we can acquire that feature in traditional way...

    multiple inheritance, overloading.....ok though these terms and mechanism are not language constrained....these were coined in other languages....
    so that is what i calll
    we are trying to do c++lization ,javalization of php.....
    lets bring every thing available there to php....has been strategedy...

  11. #36
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I honestly don't know what you're suggesting OO works because it allows you to model systems based on real world scenarions. e.g. "I have a client, who buys products" from a requirements engineering/design point of view it's easy to translate this into Objects. Obviosuly you'd have a "client" object and a "product" object, where the user will have a buy method.

    What alternative are you suggesting PHP implement? A whole new style? Can you provide some code examples?

    OOP works. It is vastly superior to procedural code in a lot of ways. With procedural code, you have to have messy constructs to keep track of sets of data (e.g. storing/manipulating data about a specific user from a set).

    I don't know why you wouldn't want PHP to have this. PHP doesn't force you to use OOP it's just there as another tool you can use. Most code designed for PHP 3 will still work on PHP5.3 with very few changes... that's 10 years worth of development.

    Why have functions or native arrays? These were copied from other languages too. Why shouldn't PHP find it's own 'simple' way to handle this?

    Almost any problem can be solved with just variables, and basic language constructs if/while/for it just makes it far more difficult. Should PHP go back to this? Why wouldn't you wan't PHP to evolve and allow a lot more flexibility?

  12. #37
    SitePoint Addict reboltutorial's Avatar
    Join Date
    Jan 2009
    Posts
    309
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Complexity cannot not reduced, only overcomplication can, this is the law of Entropy in Physics. If a system is inherently complex, it will stay complex no matter what [the vendors marketing make you believe]. The advantage of OOP is that you can split complexity between several objects for several persons or even for you alone so that it is more manageable locally, but in truth it is a necessary evil because by doing so you will lose the sequential viewpoint that you had with procedural programming, so you have to get tools to reconstruct this view for example with UML Sequence Diagrams or at the Business Analyst Level BMP Tools, and for many programmers it is just in their head until they forget because they didn't document the stuff.

  13. #38
    SitePoint Member
    Join Date
    Aug 2009
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    LOL I enjoyed reading all the comments so far ... IMHO it all boils down to personal or group preference.

    PHP is a language that gives us both possibilities OO and Procedural working (both an imperative programming style IIRC, btw C++ is translated to C before it's compiled by certain compilers; so OO is just a different way off looking at a problem)

    Nowadays PHP offers dozens o'classes through PEAR/PECL and the Standard PHP Library, so the expression power of OO vs the expression power of Procedural programming in PHP is almost the same (perhaps OO has a slight advantage on this level for inheritance and decoration are made easier)

    Having said this, I've only one point left to address. Framework like symfony and systems like joomla are blamed for being complex and hard to understand. Well let me ask you this, is a project like phpMyAdmin easy to understand at first glance?

    Don't blame the programming methodology that's in use for the complexity off big systems. It's the system size and age that make it hard to understand, not the programming methodology that's being used.

    My advice for jsbarra, try OO for some simple and minor problems. For instance create a class to manage a mysql_query resource ... if ya want, I'll gladly provide you with some code ... let the code fetch the first, last results, let it give you the power to hook that class into language constructs like for instance a foreach ... (something that cannot be done in a procedural manner within PHP)

  14. #39
    SitePoint Member
    Join Date
    Aug 2009
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    I honestly don't know what you're suggesting OO works because it allows you to model systems based on real world scenarions. e.g. "I have a client, who buys products" from a requirements engineering/design point of view it's easy to translate this into Objects. Obviosuly you'd have a "client" object and a "product" object, where the user will have a buy method.

    What alternative are you suggesting PHP implement? A whole new style? Can you provide some code examples?

    OOP works. It is vastly superior to procedural code in a lot of ways. With procedural code, you have to have messy constructs to keep track of sets of data (e.g. storing/manipulating data about a specific user from a set).

    I don't know why you wouldn't want PHP to have this. PHP doesn't force you to use OOP it's just there as another tool you can use. Most code designed for PHP 3 will still work on PHP5.3 with very few changes... that's 10 years worth of development.

    Why have functions or native arrays? These were copied from other languages too. Why shouldn't PHP find it's own 'simple' way to handle this?

    Almost any problem can be solved with just variables, and basic language constructs if/while/for it just makes it far more difficult. Should PHP go back to this? Why wouldn't you wan't PHP to evolve and allow a lot more flexibility?
    lol we can solve any programming problem with Assembler ... or even with basic binary instructions :P the only reason we invented higher level programming languages had to with a thing called expression power ... and to get away from those annoying things like being dependant with your program on one kind off processor :P

  15. #40
    SitePoint Zealot
    Join Date
    May 2003
    Posts
    164
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    there is good reason why most popular languages have had to evolve to Object Orientation. there is a science to it and it is due to past experiences with procedural and non-structured coding. Like all disciplines, the programming field also builds on past knowledge and research.

    any problem encountered in any field is best solved by breaking it down to smaller bits. whether its a social, physical or other science

    OOP makes it easier to this simple idea of problem solving, PHP had to follow suit. To be simple,in this case the problem is "how best we can write web application X" and the solution being "OOP with A,B,C doing X,YZ"

    if you havent taken time to appreciate why its necessary, dont worry, there'll be a light-bulb moment after going through many projects and trying to find how best to do it in PHP.

    you obviously cannot say....hmmm, how do I use OOP to echo a statement in php. I know,I will create a PHP object for every echo statement
    PHP Code:
    class Echoer
    {
    var 
    $txt;

    function 
    Echoer($echoText="")
    {
       
    $this->txt $echoText;
    }

    funtion echoPrint()
    {
       if(
    $this->txt != "")
          echo 
    $this->txt;
       else
          echo 
    "Echoer Error! Contact your admin";
    }

    that's just plain funny and overkill...which we do see sometimes.

    imagine going to Autocad first before you build bridges using a deck of cards...when all you want to do is play with your kids...

    lots of programmers do get confused by poorly written code. using OO methods does not absolve a person from coding practice like documenting(through good comments) and following an easy to understand structure. there are many popular CMS's that I find hideous to follow. some would need me to learn and read that code for a while before I grasp the developers' thinking. I know there are many people who share the same sentiment.

    I would say blame the pianist, not the piano.

    OO is just a tool
    Elgg Customisation & Theme development
    Modx Custom Development
    PHP programming

  16. #41
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,182
    Mentioned
    16 Post(s)
    Tagged
    4 Thread(s)
    Portability is huge +. Its very easy to move libraries from one project to the next reducing time and cost it would take to remake things that already work well. That's not to say you can't achieve the same thing using procedural coding, but using a OO paradigm also makes it possible to change implementation while keeping the core consistent. This would not be easily achieved using procedural style. The only way to achieve this in procedural code is to build functions on top of functions. However, the big flaw here is a function can't access the state of another. So all your able to do is modify the return value unless your resorting to globals. In a OO paradigm inheritance makes it possible for any number of subclasses to access the state of of their ancestors. Making the OO paradigm very flexible in reuse across multiple applications. This also speaks to the ability to completely separate interface from implementation supporting the idea of loose coupling. So even though an idea may stay consistent across several platforms its actual implementation can be changed to suit the needs at that given time yet all the other code can stay the same! – a huge selling point if you support loose coupling and are a fan of interfaces. Practices that ultimately result in more maintainable, understandable and flexible code across a single application or multiple sharing single classes or multiple packages

  17. #42
    SitePoint Member
    Join Date
    Sep 2009
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Vali View Post
    - You find a "bug" in your code, and you know that this code has been used in 50 sites.

    "Old School PHP" solution:
    -- Go to the site where you found the bug, and do a fix, creating a patch (to be merged in all other sites).
    -- Go in each site, see if that site is using your "buggy" code, and add the patch. if your lucky, you don't get many conflicts...
    --- Then go in and test each site, 1 by 1 to make sure that change did not break anything. You do this by testing from the client side, and by looking at all the code.

    "OOP" solution:
    -- Go to the site where you found the bug, and do a fix, creating a patch (to be merged in all other sites), and the tests sets to go with your change.
    -- Since your site is OOP (good OOP), your change will affect 1 class only.
    -- Go in each site, see if that site is using your "buggy" code, and add the patch.
    NOTE: since your code is good OOP, you will never have conflicts here, since all 100 sites have the exact same class.

    Correct me if I'm wrong, but if you gather some functions in one file, and include that file where needed, that's not considered OOP, right? As no classes are used.
    Now, if that file is used in 100 sites and you find an error in it, all you need to do is patch that one file and spread the patch to all other sites. You don't need to check anything because every site uses the same file.

    The way I read it, you assumed that the functions are declared in the same file as they are used.

  18. #43
    SitePoint Member
    Join Date
    Aug 2009
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by StijnH View Post
    Correct me if I'm wrong, but if you gather some functions in one file, and include that file where needed, that's not considered OOP, right? As no classes are used.
    Now, if that file is used in 100 sites and you find an error in it, all you need to do is patch that one file and spread the patch to all other sites. You don't need to check anything because every site uses the same file.

    The way I read it, you assumed that the functions are declared in the same file as they are used.
    Hmm... and here is where testing kicks in; how can you be sure none o'those 100 sites abused the bug you found in that one class ... Btw real OOP can still mean you have to patch a "bug" in several classes at once, for most o'the time a bug is found in a algorithm

  19. #44
    SitePoint Enthusiast nrg_alpha's Avatar
    Join Date
    Dec 2008
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pascalvree View Post
    Btw real OOP can still mean you have to patch a "bug" in several classes at once, for most o'the time a bug is found in a algorithm
    In books like Head First: Design Patterns as well as the legendary Gang of Four's Design Patterns: Elements of Reusable Object Oriented Software, one shouldn't have to 'patch bugs in several classes at once' (if this is the case, you can probably chalk that up as poor OOP design).

    The idea is that classes each do a very specific thing, and do it well, so one of the principals of OOP is that classes are 'closed to modification, but open to extensibility'. That is to say, ensure that the class performs its specific role (including debugging it), and once it does, close it to further modifications.. should there be a need for additional features, further classes can handle this (thus the extensibility / program requirements subject to change). I would recommend those books to anyone wanting to learn OOP, as the prinicipals are very sound, tried, true and tested ones.

  20. #45
    SitePoint Member
    Join Date
    Aug 2009
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nrg_alpha View Post
    In books like Head First: Design Patterns as well as the legendary Gang of Four's Design Patterns: Elements of Reusable Object Oriented Software, one shouldn't have to 'patch bugs in several classes at once' (if this is the case, you can probably chalk that up as poor OOP design).

    The idea is that classes each do a very specific thing, and do it well, so one of the principals of OOP is that classes are 'closed to modification, but open to extensibility'. That is to say, ensure that the class performs its specific role (including debugging it), and once it does, close it to further modifications.. should there be a need for additional features, further classes can handle this (thus the extensibility / program requirements subject to change). I would recommend those books to anyone wanting to learn OOP, as the prinicipals are very sound, tried, true and tested ones.
    Well mostly we agree, but patching a bug at one place; introduces new bugs at other places; or put differently, you'll always patch the source for ur bug at one place; but most o'the time you also have to update code at other places in order to work with the updated version.

    There is a big difference between the theory and practise for this point at least for the company where I work currently ...

    Btw those are great books (although I prefer the whole GoF readinglist above the headfirst series)

  21. #46
    SitePoint Wizard
    Join Date
    Mar 2008
    Posts
    1,149
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't really see the need, or personally the existence, of a divide between OOP and procedural. If you understand the idea behind both, you'll know when OOP is appropriate for the situation, and when procedural is appropriate. Comparing OOP and procedural is like comparing green apples to red apples. The difference is so minuscule compared to imperative vs. declarative programming, which have entirely different ways of approaching the same problem.

    When the OO instructions finally get to the processor, they are very procedural. So the real lesson is to know both, and not spend too much time trying to set one's sight on only one methodology.

  22. #47
    SitePoint Addict Divisive Cotton's Avatar
    Join Date
    Jun 2008
    Location
    Andy lives in London, UK
    Posts
    393
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jsbarra View Post
    I am still not convinced it is worth switching to.
    One good reason to use OOP is that most PHP coders use it nowadays (and that % will only increase in time) and I think I'm right in stating that it is used in all frameworks and PEAR. By not knowing it you are leaving yourself the possibility of being excluded from the wider PHP community.
    Let everyday be Christmas

  23. #48
    SitePoint Member
    Join Date
    Aug 2009
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sk89q View Post
    I don't really see the need, or personally the existence, of a divide between OOP and procedural. If you understand the idea behind both, you'll know when OOP is appropriate for the situation, and when procedural is appropriate. Comparing OOP and procedural is like comparing green apples to red apples. The difference is so minuscule compared to imperative vs. declarative programming, which have entirely different ways of approaching the same problem.

    When the OO instructions finally get to the processor, they are very procedural. So the real lesson is to know both, and not spend too much time trying to set one's sight on only one methodology.
    we completly agree (there is a project out there, which tries ro run java class files directly on the processor :P)

  24. #49
    SitePoint Member
    Join Date
    Sep 2009
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Divisive Cotton View Post
    One good reason to use OOP is that most PHP coders use it nowadays (and that % will only increase in time) and I think I'm right in stating that it is used in all frameworks and PEAR. By not knowing it you are leaving yourself the possibility of being excluded from the wider PHP community.
    That's not a good reason.

  25. #50
    SitePoint Guru risoknop's Avatar
    Join Date
    Feb 2008
    Location
    end($world)
    Posts
    834
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One positive thing is that OOP isn't syntactically very different from structured code (apart from few new keywords such as class, public, private etc) so everything you have learned so far by writing structured PHP code can be used in OOP, functions, variables, comments, arrays etc.

    The major difference is in a way of looking at applications. You will be trying to mimick natural objects and organisms and interactions between them in your code. You can easily compare objects in programming languages to a natural objects such as animals. Every object is independent from other objects and has a limited set of physical abilities (methods) and attributes (properties). However, even though each object is completely independent there can be multiple similar objects with the same attributes and abilities, for example all dogs are of the same specie (class).

    To sum it up, class is a "definiton" of objects and describes how all objects derived from this class will behave (their set of properties and methods). Every object of the same class will have the same set of properties and methods but this doesn't mean these objects are identical. Every one of them can have different values of properties and can be using different methods at a time.

    Analogy with dogs is quite good here, too. Surely all dogs have 4 legs, a tail, they can run, bark, eat, poo etc but that doesn't mean they are like an army of clones and all are doing the same thing at the same time.


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
  •