On 20 February 2011 23:51, tolga <kacmaztolga@xxxxxxxxx> wrote: > 21.02.2011 01:41, Richard Quadling yazmÄÅ: >> >> On 20 February 2011 23:34, Richard Quadling<rquadling@xxxxxxxxx> Âwrote: >>> >>> On 18 February 2011 19:03, Pete Woodhead<pete.woodheadvb@xxxxxxxxx> >>> Âwrote: >>>> >>>> Hi I'm Pete Woodhead. ÂI'm new to the list and to PHP. ÂTo be honest I >>>> very >>>> new to code writing. >>>> Thought this would be a good way to learn good habits as well as good >>>> code >>>> writing. >>>> Looking forward to learning and participating. >>>> >>> Assume that all the data you get from the user is out to get you. It >>> probably isn't. Most of the time. But when it does, it'll be your >>> fault. Unless you've left the company by then. >>> >>> Also, poka-yoke is a great concept to learn about (thanks to a great >>> article in php|Architect all the way back when). >>> >>> Richard. >>> >>> -- >>> Richard Quadling >>> Twitter : EE : Zend >>> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY >>> >> http://www.phparch.com/magazine/2006-2/february/ in case anyone was >> wondering. >> > i'm interested in php about 3 maybe 4 years but i still couldnt get the > logic of classes. it makes no sense to me. i couldnt understand whats about > classes good at or how to use or write it. and i can say that " is 'class' > really necessery? " Necessary? No. They are not necessary. But they can certainly help. I'm not an expert or a teacher but here is a short list of "features" that I've found the most useful when it comes to using OOP techniques over procedural or linear programming and trying to explain them to non OOP developers. 1 - Encapsulation. http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) : "A benefit of encapsulation is that it can reduce system complexity, and thus increases robustness, by allowing the developer to limit the interdependencies between software components." For any given program, there will be groups of functions and variables which are either loosely associated with each other, or maybe more tightly bound. In a procedural environment, you may need to pass the same parameters to every function in the related group. In its simplest form, encapsulation allows you to place the shared variables and the methods into a closed group (a class). The class becomes the container for all the variables and functions (or properties and methods if you prefer). You don't need to pass around the parameters to every function as they are already part of the class. Encapsulation allows the combination of "data" and "behaviour" into the "object". So, for example, say you want to connect to a database. Commonly, you'll need the name of the server, a username and a password. You may also require a database name. That would be the "properties". The behaviour could be limited to "connect" and "disconnect". Depending upon your preference, you may have "isConnected" as a property which is maintained dynamically, or a method "getConnectedState" which investigates the state of the connection in real time. Whatever really. The properties defined within the class can be protected from inspection/alteration from anything outside of the class (or a subclass). This means that the global list of all know variables/function names has shrunk considerably for an OOP app. Having 2 libraries of code which havbe been coded with the same function names ... how do you know which function to call. Often the code will complain due to a collision of names. But for variables, maybe not. Redeclaring a variable name may be fine in your language and not be an error. Maybe not a great example, but OOP is about building blocks, so ... 2 - Inheritence. http://en.wikipedia.org/wiki/Inheritance_(computer_science) : "Inheritance is a way to compartmentalize and reuse code by creating collections of attributes and behaviors called objects which can be based on previously created objects." So, having built an object which exhibits behaviour and has properties (like things in the real world), you may often want to produce something that is "like" the thing you created. A common approach in procedural code is to add another variable to the mix which has to somehow be stored and differentiated between "this" type of thing and "that" type of thing. You may have MANY types, all requiring their own additional data and differentiating behaviour. Complex/long switch() or if/then/else blocks ensue. Inheritence allows you to do this in a very simple way. A "class" (just a collection of data and behaviour) can be "extended" to include new properties and/or behaviour and maybe alter the behaviour, or even obscure existing behaviour (there are issues about doing this and it is not a trivial issue if you get it wrong). So, for example, you've got your database connection class. Now you need to include connecting to the database through another connection type (say a VPN tunnel). So, you could simply add parameters indicating the data required for VPN connectivity or you could create a new class based upon the initial database connectivity class. This is commonly known as subclassing. The subclass would have all the properties and methods of the main class (and without any need to copy them in code, that is done for you because you "extend"-ed the base class), so all you need to do is add the new data (properties) and functions (methods) to the new subclass. 3 - Polymorphism. http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming : "Subtype polymorphism, almost universally called just polymorphism in the context of object-oriented programming, is the ability to create a variable, a function, or an object that has more than one form" This one is a little more complex. The first two features can be seen as nothing more than a form of grouping. They are hopefully fairly simple to understand. It is probably possible to implement both of those features in procedural code without too much difficulty. So, what is this third feature. I don't know of a similar technique in procedural code, so the explantion may be awkward. Following on from the DB connectivity example ... so you've built your DB connectivity classes. You have a base class which does the raw DB connectivity. You have several sub-classes dealing with making that connectivity through additional security (VPN, firewall, dialup - whatever). All of these options are for the purpose of one thing - connect to a database. You now come to the part of your application where you need to initiate the connection. Your code requires an object that is of the appropriate type (just like you can typehint string, integer, boolean in some languages, in PHP, you can also type hint class types). But what type do you set? Your app allows the user to determine which connection they want to use at run-time. How do you hint all those different connection types? Well, you don't. The main advantage of polymorphism is that it allows you to pass a subclass off as the main class. So, as long as subclass x is extended from class y, your type hint will be for class y and all subclasses will be allowed to be passed to the method. Hmmm. And now you can see why I'm not a teacher. I get the feature, but I can't easily explain it. There are MANY more features that you can use when if comes to OOP, but, for me, these three really do make the next big leap from procecural programming to OOP. Linear -> procedural -> OOP. OOP is an evolution. In my opinion, AOP is the next big leap and is an evolution of OOP. But that's another story. Here endeth the lesson. Regards, Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
