What is the name of having code structured with methods attached to objects?
For example:
" ... ".trim
or
obj.method()
At first many would argue this is Object oriented, but php is Object Oriented(well partially), yet it syntax is completely different trim(" ... ").
TL;DR "Object Oriented" and "Everything is an Object" aren't valid answers unlesss......
People constantly suggest PHP is "Object Oriented" and libraries are "Object Oriented", yet PHP library's code is often structured with tons of static classes.
For example RedBean:
R::dispense($bean)
R::store($bean)
R::trash($bean)
That doesn't follow the obj.method syntax, yet is supposedly Object Oriented. Is PHP's object orientation misleading, or is there a better name for obj.method() coding style.
PHP can do both. You can write object oriented code, and you can write procedural code.
Procedural code is much easier to understand and write, and most PHP programmers don't really understand OOP, so they write, what I call, procedural code disguised as OOP.
This includes things like static methods, and singletons.
Much of the core functions of PHP is C heritage, so don't get surprised if it doesn't follow OOP conventions.
The important thing is that calling methods on objects does follow OOP conventions.
Strings in PHP are not considered to be objects but scalar values. Therefore the syntax "..."->trim() cannot work unless the scalar string literal is converted to object first.
There is an open proposal for auto-boxing (auto-converting of a scalar value to object). This would allow the usual object oriented syntax. Auto-boxing, however does have a little performance penalty. See more here:
https://wiki.php.net/rfc/autoboxing
In the case of RedBeanPHP I use static methods for the facade. This is more user friendly than purist OO code. You don't have to know about all the internals of RedBeanPHP in order to use it (there is also an OO way to use the lib). In my opinion RedBeanPHP is really object oriented; behind the facade it uses inheritance, interfaces, polymorphism and patterns like adapters, factories, observers.
Also, I believe OOP is more like a way of thinking than just a syntax thing. For instance you can just as well craft object oriented systems using structs and function pointers or like GTK does. OOP features in languages are just to facilitate. Also, because PHP is a dynamic language (in contrast to static typed) it does not have to rely on types, it can just scan objects for desired behaviours. In my opinion this is a good thing because it is more flexible and more maintainable the deep class hierarchies like in Java. I used to be an OO purist but I have recently embraced OOP-pragmatism; just use the best of both worlds.
Related
I'm just beginning to learn PHP. Sorry, if it's a newbie question but I'm wondering how methods work. For example, if I wanted to remove white spaces at the beginning of a string. In Ruby, I would call something like:
string.strip!
But in PHP, I would have to do something like:
trim(string);
Obviously, the Ruby version is more elegant(in terms of object-oriented design), but I'm wondering how it works for PHP and other languages such Java. Is there a name for designing functions/methods this way(in PHP)? And where are those methods defined and why can they be accessed anywhere? Thanks a lot in advance!
There are two different paradigms here: object-oriented programming (OOP) and procedural programming.
In OOP, functions are defined in the context of data, encapsulated by classes; such functions are usually called methods. When a method is called on an object (e.g. an instance of a class), it inherently has access to the state of that object. So, in your example, strip already knows what string it's being called on, and so doesn't require any additional arguments. Whenever your function naturally operates on a particular object or set of data (e.g. as strip acts on a string), it is sensible to define it as an instance method in this way.
In procedural programming, functions are defined independently data structures (classes), and must be explicitly passed the data they are to work with. Sometimes this approach is in fact more natural; for example, a print function that prints some input to stdout, or similar, isn't naturally associated with any particular object or data.
Most modern languages have OO features built into them, as it's a very versatile and powerful programming paradigm. Languages like Java and C# encourage all code to be written in an object-oriented style. In these languages, even the basic data-types like strings and floating points are in fact objects and have their own methods and state. This is particularly true in C#, where all types inherit ultimately from System.Object (even int and double) and inherit all the common methods defined thereby. This is called a unified type hierarchy.
PHP, on the other hand, has a curious mixture of OOP and procedural features; it started life as a procedural language, and OOP was only introduced in version 3 (and only in a very rudimentary sense). While, as of PHP5, it has relatively good OOP support, most of its standard library is still implemented procedurally as loose collections of functions that expect to have the relevant state/data passed to them as arguments. OOP libraries are becoming more common, however (e.g. with mysqli).
You're looking at, essentially, the different between instance methods and class/static methods. Instance methods are called on a specific instance of a class, and they have access to the internal state of that instance. Class/static methods are not, and do not.
I'm not sure what you're looking for in asking "how it works for PHP and ... Java." With regard to instance vs non-instance methods, Ruby, PHP, and Java all work roughly the same.
I am about to start learning Objective-C and I was wondering whether or not the concepts are the same as with PHP. For example, are the concepts in Object Oriented PHP the same as Objective-C, such as "Class, Instance, Message, Method, Instance Variable, Inheritance, Superclass/Subclass, and Protocol"? If so, this will I am guessing it will be much easier for me to learn and grasp since I already know the basics and foundations of Object Oriented PHP. Or are they completely different from each other?
Any help and advice is greatly appreciated. Thanks!
They are basically the same idea, but not implementation, since most of those are CS theory concepts. Messages and protocols don't exist in PHP. PHP has what most languages call an interface which is akin to a protocol in Objective-C.
All "propper" OO language constructs should be essentially the same. They should always have all of, or a sub section of the the following (and probably more).
class / object (completely different)
method (vs function)
method visibility/access control (public, private, protected)
constructor
static/class variables & methods
destructor/finalizer
inheritance (and often, multiple inheritance)
interface/protocol
abstract class
overriding
overloading
there are plenty more terms to do with things that are more conceptual rather than language features, but that's a short (and reasonably incomplete) list of some things that you should know for programming in ANY OO language worth it's salt.
There's a nice little list of terms on Wikipedia to help if you'd like.
http://en.wikipedia.org/wiki/List_of_object-oriented_programming_terms
I'd suggest reading about the terms above, as well as
Instance variables
Polymorphism
Composition
Encapsulation
If you know your defenitions of OO, moving from one language to the next is far simpler, because you will have a very wide base to stand on and only have to learn subtle differences (as with learning any new language after knowing a few, but more so with OO concepts).
The short answer is "Yes." The medium-length answer has been written by Apple, and you can read it here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/OOP_ObjC/Introduction/Introduction.html
I have been reading around the definition of OOP and couldn't get why PHP is considered object oriented.
Can this have anything to do that the "basic level" of PHP isn't and more advanced features are?
OO features were added to PHP in stages through versions 3-5, after much of the standard library had already been created and the language was already established. Background
For this reason the standard library is not object-oriented and so everyday PHP scripts need not use any OO-style features at all. Although PHP by now has most of the standard features of an object-oriented language, many authors don't use them.
Library functions added to the language later continued to use functional style for consistency, though many extension modules do use objects.
Almost any language that allows you to create and instantiate classes can be considered object oriented.
PHP has these capabilities, but doesn't really stretch them. You can use OOP to help your code, but it isn't required. Java and C# barely allow you to write non-OO code, as everything must be in a class.
Can this have anything to do that the "basic level" of PHP isn´t and more advanced features are?
You could say that about just about any OO language. The general definition of OO code is where you create classes and instantiate them in your code, calling methods on them from other classes. Nothing stops you from using only static methods or one super class with a 'run' method that only calls other methods inside the class, both of which would definitely NOT be object oriented. As far as I know, there aren't any languages that say "You must create classes and instantiate them or you will be banished!" (I haven't looked into Smalltalk though).
Beginners often learn the basics while putting all their code in just one method that gets called at the stat of the program. Once they get to more 'advanced' features like methods and classes, they are offered other options.
There is already a sufficient (and accepted) answer here, but I thought I'd throw another log on the fire for clarity's sake.
The "class" keyword (and the enforcement of its ubiquity, as in Java) does not Object-Oriented Programming make. As CrazyJungleDrummer pointed out, it is perfectly feasible (and all too common) to write entirely procedural code in something like Java; the fact that the code lies between curly braces in a class called HelloWorld doesn't change that fact. And just hiding a bunch of functions in a class and calling them static methods isn't OOP either -- it's namespacing.
Think of a proper object as a struct (or "custom type", depending on your previous language exposure) that knows what to do. Objects are data that you don't (or shouldn't) act upon directly; you ask them to do things to themselves, and you ask them to tell you about themselves. You create entities and pass messages. OOP is about treating your data like it's all grown up and can handle itself. It's not about where the main line of code lives, but how data are treated.
Oh, and one more thing -- even in a language that is more obviously canted toward OOP, real OOP is not always the right approach. It's all about the data.
You can write classes with PHP, but most of the core features are not object-oriented.
It's been a long time since this question but I came upon this article and wanted to shre the author's point of view.
PHP is not object oriented!
This answer is inspired by this Man and his answer.
Object-Oriented technology is often described in
terms of encapsulation, polymorphism, and inheritance. But
these are only identity.
If object-oriented technology is to be successfully
it must emphasis on the object.
When we say Object-oriented or Object-orientation it can refer to several things:
Object-oriented analysis and design[OOAD]
Object-oriented design[OAD]
Object-oriented database
Object-oriented modeling
Object-oriented operating system
Object-oriented programming[OOP]-->topic of concern
Object-oriented software engineering
Object-oriented user interface
What Pure Object Oriented Programming Language[OOP] is?
Alan Kays["Considered by some to be the father of object-oriented programming"] [Defination]5 link by Gordon:
EverythingIsAnObject.
Objects communicate by sending and receiving messages (in terms of objects).
Objects have their own memory (in terms of objects).
Every object is an instance of a class (which must be an object).
The class holds the shared behavior for its instances (in the form of objects in a program list)
Now clearly it can be seen Java,C++ and PHP violates rule 1?Why bcoz int, float etc. (there are a total of eight primitive types). so it cannot be Object oriented in strict sense but some folk's considered it as OOP.
The general approach of OOP is to view a software system as a collection of interacting entities called "objects" each of which is defined by an identity, a state described in terms of member variables, and a behavior described in terms of methods that can be invoked
What OOP is not?
Object-Oriented technology is often described in
terms of encapsulation, polymorphism, and inheritance. But
these are only identity.
An Object Oriented system, language, or environment should include at least Encapsulation, Polymorphism, and Inheritance.
Polymorphism and Inheritance are certainly patterns that facilitate
OO programming, but not only bound to it
The object-oriented paradigm isn't completely the domain of
high-level programming languages -->may topic of debate but i came
across this OOP in Assembly
Uncle Bob aka Bob Martin in his lecture shows How C implements Encapsulation,Inheritance,and Polymorphism LINK
OO is based on modeling real-world objects // For Marketing purpose
Difference Between OOP and Functional?
This may be not be perfect answer but i gave a try,Thnks to knowledge of valley.
Note:
Images are randomly found on google
This may be a silly question, but it's been bugging me.
I've been writing what I believe to be procedural code, but I'm using classes which group together related public and private functions according to purpose. Instead of using objects and methods, I call the functions when needed with a scope resolution operator. ie: db::execute($sql)
I know it's ridiculous, but I just now realized everyone immediately associates classes with OOP. Am I committing some perverted heresy?
you're basically abusing one language construct (class) to emulate another one (namespace). This is totally normal, as long as you use a language that doesn't support the latter (php 5.2-).
If you know the distinction between classes and "OOP use of classes" then I guess it is not a real problem ...
"Perverted heresy" might be taking it a little far, but you're certainly missing out on much of the organizational power of object oriented programming.
It sounds to me like you're using classes as namespaces.
I don't see anything particularly wrong with this - it provides logical separation of concerns, and presumably makes things easier for you to develop/maintain.
You'd definitely be better off learning more about Object-Oriented Programming so you can take advantage of the benefits it offers.
As long as you don't claim to be doing OOP, I don't see anything wrong with using static methods for procedural programming to make up for PHP's lack of namespaces.
You are not doing anything wrong.
Some classes are used only to contain utility functions (for example the Arrays class in Java), actually called "static methods".
What you are doing is using this feature in substitution of namespaces. For clarity you should use the latter.
What is the best way to deal with "utility" functions in a OOP PHP framework? Right now, we just have a file with several functions that are needed throughout the system. (For example, a distribute() function which accepts a value and an array, and returns an array with the value distributed in the same proportions and same keys as the input array.)
I have always felt "dirty" using that because it's not object-oriented at all. Is it better practice to move these into various classes as static methods, or is that just a semantic workaround? Or is there just going to be a level in a framework where some stuff is going to fall outside of the OOP structure?
I tend to make a Util() class that contains only static methods, has no attributes, and is not inherited from. Essentially, it acts as a "namespace" to a bunch of utility functions. I will allow this class to grow in size, but will occasionally split of methods into their own classes if it is clear that those methods are designed only to work with certain kinds of data or if it is clear that a group of related methods should be grouped into a class along with, perhaps, some attributes.
I think it's perfectly OK to deviate from purely OOP practices so long as the code that deviates is well-organized and is not creating architectural flaws in your system that make it harder to understand and maintain.
I've always been more pragmatic about questions like these.
If you want to go full-OOP, you should obviously stick these into classes. However, these classes are only going to be container classes, because they don't really represent objects of any kind.
Also: using classes would require you to either have an instance of that class, using the singleton pattern or declaring every function static. The first one is slower (okay, might not be that much, but in a large framework things like that get large, too - especially in interpreted languages like PHP), while the second and third ones are just plain useless and simply an OOP wrapper for a set of functions (especially the third approach).
EDIT: Feel free to prove me wrong. I might be. I'm not too experienced and always saw it that way, but I might be wrong.
I always think of utility functions as extensions of the standard php functions. They are not object oriented because you don't really get any benefit from making them OO.