Related
When I started to learn OOP programming I read that everything is an object. For the most time I develop in PHP. Arrays have important role here. In languages like C# in most cases you really have to use and pass objects not arrays.
For example:
Class Product
{
private $data = array();
public function __construct()
{
$this->data['setting_1'] = 'a';
$this->data['setting_2'] = 'b';
$this->data['setting_3'] = 'c';
$this->data['setting_4'] = 'd';
$this->data['setting_5'] = 'e';
}
}
Is there any sense to create classes for everything when you use PHP? For example:
Class Product
{
private $setting_1, $setting_2, $setting_3, $setting_4, $setting_5;
}
And then instantiate class Product in another class (eg. Model) and return object instead of array (eg. to Controller)?
The answer is simple.
Everything is an object
is just an ideal.
In most real world OOP languages there are simple data types as well. Even in Java or CSharp. In PHP there is even an array as a complex, non object data type. You should not worry using it, also in OOP context of course.
Note that having the powerful array data type is more an advantage than a disadvantage. In my opinion the most lacking OOP feature of PHP is polymorphism, btw.
However, PHP5 introduced a suite of iterators and data structures, in the so called Standard PHP Library (SPL) extension, which is part of the PHP core distribution. You can have a look at them, but in most cases the array data type should work well (and performant).
No. Not everything needs to be in a class. This isn't Java. :P
PHP is a multi-paradigm language. That means it's perfectly legitimate to use some OO without going whole-hog. The OOP wonks might tell you how horrible a person you are, but OOP is only worthwhile when it reduces overall complexity. Wrapping every value up in a class, for the sake of doing it, adds complexity for no real gain.
A class is basically a template for data that has some unique behavior of its own. If your data doesn't need behavior associated with it (special construction, validation, interpretation, or persistence, for example), wrapping it up in objects is often overkill.
In the "everything is an object" mindset, keep in mind this applies to languages that were OO based from day 1. PHP is not one of those languages, objects were added after the fact. So your simple variable types in PHP are not objects, they are smaller & simpler pieces of memory.
It's splitting hairs, but if you don't need to use an object in PHP, then don't, simple arrays are lighter than objects that contain an array. By lighter I mean they use less ram, and in turn, run slightly faster.
The best advice you can get about writing PHP is KISS (Keep It Simple Stupid).
Answering "Is there any sense to create classes for everything when you use PHP?" as "Is there any sense to create properties in classes for everything when you use PHP?"
Yes, it is very difficult to develop on someone else's code when all that was used was arrays. Specially if there are no constants making it very possible to mistype something to create a bug which would be extremely hard to find.
Also, not that you are not talking about "creating objects for everything" but properties vs a list (array) of values, which is what I based my answer on.
I do a lot of work in WordPress, and I've noticed that far more functions return objects than arrays. Database results are returned as objects unless you specifically ask for an array. Errors are returned as objects. Outside of WordPress, most APIs give you an object instead of an array.
My question is, why do they use objects instead of arrays? For the most part it doesn't matter too much, but in some cases I find objects harder to not only process but to wrap my head around. Is there a performance reason for using an object?
I'm a self-taught PHP programmer. I've got a liberal arts degree. So forgive me if I'm missing a fundamental aspect of computer science. ;)
These are the reasons why I prefer objects in general:
Objects not only contain data but also functionality.
Objects have (in most cases) a predefined structure. This is very useful for API design. Furthermore, you can set properties as public, protected, or private.
objects better fit object oriented development.
In most IDE's auto-completion only works for objects.
Here is something to read:
Object Vs. Array in PHP
PHP stdClass: Storing Data in an Object Instead of an Array
When should I use stdClass and when should I use an array in php5 oo code
PHP Objects vs Arrays
Mysql results in PHP - arrays or objects?
PHP objects vs arrays performance myth
A Set of Objects in PHP: Arrays vs. SplObjectStorage
Better Object-Oriented Arrays
This probably isn't something you are going to deeply understand until you have worked on a large software project for several years. Many fresh computer science majors will give you an answer with all the right words (encapsulation, functionality with data, and maintainability) but few will really understand why all that stuff is good to have.
Let's run through a few examples.
If arrays were returned, then either all of the values need to be computed up front or lots of little values need to be returned with which you can build the more complex values from.
Think about an API method that returns a list of WordPress posts. These posts all have authors, authors have names, e-mail address, maybe even profiles with their biographies.
If you are returning all of the posts in an array, you'll either have to limit yourself to returning an array of post IDs:
[233, 41, 204, 111]
or returning a massive array that looks something like:
[ title: 'somePost', body: 'blah blah', 'author': ['name': 'billy', 'email': 'bill#bill.com', 'profile': ['interests': ['interest1', 'interest2', ...], 'bio': 'info...']] ]
[id: '2', .....]]
The first case of returning a list of IDs isn't very helpful to you because then you need to make an API call for each ID in order to get some information about that post.
The second case will pull way more information than you need 90% of the time and be doing way more work (especially if any of those fields is very complicated to build).
An object on the other hand can provide you with access to all the information you need, but not have actually pulled that information yet. Determining the values of fields can be done lazily (that is, when the value is needed and not beforehand) when using an object.
Arrays expose more data and capabilities than intended
Go back to the example of the massive array being returned. Now someone may likely build an application that iterates over each value inside the post array and prints it. If the API is updated to add just one extra element to that post array then the application code is going to break since it will be printing some new field that it probably shouldn't. If the order of items in the post array returned by the API changes, that will break the application code as well. So returning an array creates all sorts of possible dependencies that an object would not create.
Functionality
An object can hold information inside of it that will allow it to provide useful functionality to you. A post object, for instance, could be smart enough to return the previous or next posts. An array couldn't ever do that for you.
Flexibility
All of the benefits of objects mentioned above help to create a more flexible system.
My question is, why do they use objects instead of arrays?
Probably two reasons:
WordPress is quite old
arrays are faster and take less memory in most cases
easier to serialize
Is there a performance reason for using an object?
No. But a lot of good other reasons, for example:
you may store logic in the objects (methods, closures, etc.)
you may force object structure using an interface
better autocompletion in IDE
you don't get notices for not undefined array keys
in the end, you may easily convert any object to array
OOP != AOP :)
(For example, in Ruby, everything is an object. PHP was procedural/scripting language previously.)
WordPress (and a fair amount of other PHP applications) use objects rather than arrays, for conceptual, rather than technical reasons.
An object (even if just an instance of stdClass) is a representation of one thing. In WordPress that might be a post, a comment, or a user. An array on the other hand is a collection of things. (For example, a list of posts.)
Historically, PHP hasn't had great object support so arrays became quite powerful early on. (For example, the ability to have arbitrary keys rather than just being zero-indexed.) With the object support available in PHP 5, developers now have a choice between using arrays or objects as key-value stores. Personally, I prefer the WordPress approach as I like the syntactic difference between 'entities' and 'collections' that objects and arrays provide.
My question is, why do they (Wordpress) use objects instead of arrays?
That's really a good question and not easy to answer. I can only assume that it's common in Wordpress to use stdClass objects because they're using a database class that by default returns records as a stdClass object. They got used to it (8 years and more) and that's it. I don't think there is much more thought behind the simple fact.
syntactic sugar for associative arrays
-- Zeev Suraski about the standard object since PHP 3
stdClass objects are not really better than arrays. They are pretty much the same. That's for some historical reasons of the language as well as stdClass objects are really limited and actually are only sort of value objects in a very basic sense.
stdClass objects store values for their members like an array does per entry. And that's it.
Only PHP freaks are able to create stdClass objects with private members. There is not much benefit - if any - doing so.
stdClass objects do not have any methods/functions. So no use of that in Wordpress.
Compared with array, there are far less helpful functions to deal with a list or semi-structured data.
However, if you're used to arrays, just cast:
$array = (array) $object;
And you can access the data previously being an object, as an array. Or you like it the other way round:
$object = (object) $array;
Which will only drop invalid member names, like numbers. So take a little care. But I think you get the big picture: There is not much difference as long as it is about arrays and objects of stdClass.
Related:
Converting to object PHP Manual
Reserved Classes PHP Manual
What is stdClass in PHP?
The code looks cooler that way
Objects pass by reference
Objects are more strong typed then arrays, hence lees pron to errors (or give you a meaningful error message when you try to use un-existing member)
All the IDEs today have auto-complete, so when working with defined objects, the IDE does a lot for you and speeds up things
Easilly encapsulate logic and data in the same box, where with arrays, you store the data in the array, and then use a set of different function to process it.
Inheritance, If you would have a similar array with almost but not similar functionality, you would have to duplicate more code then if you are to do it with objects
Probably some more reason I have thought about
Objects are much more powerful than arrays can be.
Each object as an instance of a class can have functions attached.
If you have data that need processing then you need a function that does the processing.
With an array you would have to call that function on that array and therefore associate the logic yourself to the data.
With an object this association is already done and you don't have to care about it any more.
Also you should consider the OO principle of information hiding. Not everything that comes back from or goes to the database should be directly accessible.
There are several reasons to return objects:
Writing $myObject->property requires fewer "overhead" characters than $myArray['element']
Object can return data and functionality; arrays can contain only data.
Enable chaining: $myobject->getData()->parseData()->toXML();
Easier coding: IDE autocompletion can provide method and property hints for object.
In terms of performance, arrays are often faster than objects. In addition to performance, there are several reasons to use arrays:
The the functionality provided by the array_*() family of functions can reduce the amount of coding necessary in some cases.
Operations such as count() and foreach() can be performed on arrays. Objects do not offer this (unless they implement Iterator or Countable).
It's usually not going to be because of performance reasons. Typically, objects cost more than arrays.
For a lot of APIs, it probably has to do with the objects providing other functionality besides being a storage mechanism. Otherwise, it's a matter of preference and there is really no benefit to returning an object vs an array.
An array is just an index of values. Whereas an object contains methods which can generate the result for you. Sure, sometimes you can access an objects values directly, but the "right way to do it" is to access an objects methods (a function operating on the values of that object).
$obj = new MyObject;
$obj->getName(); // this calls a method (function), so it can decide what to return based on conditions or other criteria
$array['name']; // this is just the string "name". there is no logic to it.
Sometimes you are accessing an objects variables directly, this is usually frowned upon, but it happens quite often still.
$obj->name; // accessing the string "name" ... not really different from an array in this case.
However, consider that the MyObject class doesn't have a variable called 'name', but instead has a first_name and last_name variable.
$obj->getName(); // this would return first_name and last_name joined.
$obj->name; // would fail...
$obj->first_name;
$obj->last_name; // would be accessing the variables of that object directly.
This is a very simple example, but you can see where this is going. A class provides a collection of variables and the functions which can operate on those variables all within a self-contained logical entity. An instance of that entity is called an object, and it introduces logic and dynamic results, which an array simply doesn't have.
Most of the time objects are just as fast, if not faster than arrays, in PHP there isn't a noticeable difference. the main reason is that objects are more powerful than arrays. Object orientated programming allows you to create objects and store not only data, but functionality in them, for example in PHP the MySQLi Class allows you to have a database object that you can manipulate using a host of inbuilt functions, rather than the procedural approach.
So the main reason is that OOP is an excellent paradigm. I wrote an article about why using OOP is a good idea, and explaining the concept, you can take a look here: http://tomsbigbox.com/an-introduction-to-oop/
As a minor plus you also type less to get data from an object - $test->data is better than $test['data'].
I'm unfamiliar with word press. A lot of answers here suggest that a strength of objects is there ability to contain functional code. When returning an object from a function/API call it shouldn't contain utility functions. Just properties.
The strength in returning objects is that whatever lies behind the API can change without breaking your code.
Example: You get an array of data with key/value pairs, key representing the DB column. If the DB column gets renamed your code will break.
Im running the next test in php 5.3.10 (windows) :
for ($i = 0; $i < 1000000; $i++) {
$x = array();
$x['a'] = 'a';
$x['b'] = 'b';
}
and
for ($i = 0; $i < 1000000; $i++) {
$x = new stdClass;
$x->a = 'a';
$x->b = 'b';
}
Copied from http://atomized.org/2009/02/really-damn-slow-a-look-at-php-objects/comment-page-1/#comment-186961
Calling the function for 10 concurrent users and 10 times (for to obtain an average) then
Arrays : 100%
Object : 214% – 216% (2 times slower).
AKA, Object it is still painful slow. OOP keeps the things tidy however it should be used carefully.
What Wordpress is applying?. Well, both solutions, is using objects, arrays and object & arrays, Class wpdb uses the later (and it is the heart of Wordpress).
It follows the boxing and unboxing principle of OOP. While languages such as Java and C# support this natively, PHP does not. However it can be accomplished, to some degree in PHP, just not eloquently as the language itself does not have constructs to support it. Having box types in PHP could help with chaining, keeping everything object oriented and allows for type hinting in method signatures. The downside is overhead and the fact that you now have extra checking to do using the “instanceof†construct. Having a type system is also a plus when using development tools that have intellisense or code assist like PDT. Rather than having to google/bing/yahoo for the method, it exists on the object, and you can use the tool to provide a drop down.
Although the points made about objects being more than just data are valid since they are usually data and behaviour there is at least one pattern mentioned in Martin Fowler's "Patterns of Enterprise Application Architecture" that applies to this type of cenario in which you're transfering data from one system (the application behind the API) and another (your application).
Its the Data Transfer Object - An object that carries data between processes in order to reduce the number of method calls.
So if the question is whether APIs should return a DTO or an array I would say that if the performance cost is negligible then you should choose the option that is more maintainable which I would argue is the DTO option... but of course you also have to consider the skills and culture of the team that is developing your system and the language or IDE support for each of the options.
I come from a Java background and have only recently started learning PHP and CodeIgniter.
While I find the framework awesome for its clean design and impressive documentation, I notice that the framework doesn't necessarily discourage the use of data arrays instead of value objects for passing data around. For ex., the database queries return the result in an array which you can then pass over to the views for rendering. Similarly, most of the core library methods take associative arrays as inputs.
This, to me, seems like a bad design for an Object Oriented language which should promote and maybe even enforce using value objects for their obvious benefits of encapsulation.
Is this really an example of bad design or simply a matter of style/preference ? Are there any obvious benefits of using arrays for data over a more OO approach ?
Don't be misled by the myth that "everything has to be an object" for your code to be "good Object Oriented design". When you start trying to formulate rationalisations that "I shouldn't be allowed to do this, because it's not good OOP", you're programming backwards.
When you want a list of pieces of data, a data array will suffice. Indeed, it's appropriate.
Why build a complicated object structure when a hash will do? IMHO, many things in the java world are over-engineered. This opinion seems to be shared with many dynamic languages and toolsets, such as Ruby on Rails.
An array is an object and perfectly valid to use for passing data around. No need to define your own class when a built in one will do.
PHP is not an object oriented language. It's an hybrid language.
Arrays are used everywhere because they are significantly more powerful than in other languages (Java in particular). And behind the scenes both arrays and objects use the same dictionary implementation in PHP.
If you want to objectize arrays, then wrap them in:
$array = new ArrayObject($array, ArrayObject::ARRAY_AS_PROPS);
Or you can just typecast an array 1:1 into an value object:
$obj = (object) $array;
And back:
$array = (array) $obj;
They work alike in quite a few contexts anyway (foreaching over them is easy).
Well, an obvious reason to use value objects instead of associative arrays is that if you're passing data in an array all around the place and then you have to change the name of a db table column, you'll have to update the way you access it everywhere in your code, whereas if you have a value object, you need to update only a one line (inside the VO constructor)
I have a large class with lots of methods (25, interrelated of course). I'm not sure I should split it up and create a derivative and base class instead. I don't see any opportunity coming in the future for another class inheriting from the base. So what are the driving factors for breaking a large class down into smaller parts?
Yes, with 20+ methods, break it up.
Sometimes it needs experimentation.
Another option is to look at how to reduce the number of methods. For example do you have the same method (by name) taking different number and/or types of parameters? In that case you might look at commonalities between those signatures. This leads me to another suggestion.
If you have a method that takes more than - let's say 4 - parameters, then look at them and maybe there is an option to turn them into a class by themselves. This can result in some of the functionality moving out into the new class.
Look at the number of fields (= member variables) in your class. Can you group the methods in such a way that they operate largely on a subset of those member variables? Maybe you can turn these methods and the values they operate on into a new class.
what are the driving factors for breaking a large class down into smaller parts?
You should do it when it makes logical sense to do it in terms of separate objects. If all those methods you've defined truly do operate on a single object and couldn't logically be thought of as pertaining to different objects, then keep them in one.
I'm not sure I should split it up and create a derivative and base class instead
Not sure what you mean here. You would derive from a base class when you need an object that inherits some behaviours from a base class but modifies or adds others, but want your base class to remain as it is as well. You don't inherit just to break up your code into manageable chunks.
"Large Class" is a classic "code smell". See here: http://sourcemaking.com/refactoring/large-class
When you have a large class, it may or may not mean you have a good candidate for refactoring. That's what a "code smell" is... It may be your code is fine, but only a good hard look at it can you be sure.
Follow the advice given in the article I've linked. Even thought it wasn't written for PHP, the concepts and strategies still apply.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
What are the benefits of OO programming? Will it help me write better code?
OO PHP Explanation for a braindead n00b
Just started learning/playing with creating classes in PHP and I'm wondering what pain do they solve? It seems like I can get the same job done with just a collection of functions that I include into the file. So my question is: Why should I use classes?
The Three Pillars of Object Oriented Programming. Learn them well:
http://codeidol.com/csharp/learncsharp2/Object-Oriented-Programming/The-Three-Pillars-of-Object-Oriented-Programming/
Encapsulation
The first pillar of object-oriented programming is encapsulation. The idea behind encapsulation is that you want to keep each type or class discreet and self-contained, so that you can change the implementation of one class without affecting any other class.
Specialization
The second pillar of object-oriented programming , specialization , is implemented through inheritance ; specifically by declaring that a new class derives from an existing class. The specialized class inherits the characteristics of the more general class. The specialized class is called a derived class, while the more general class is known as a base class.
Rather than cutting and pasting code from one type to another, the derived type inherits the shared fields and methods. If you change how a shared ability is implemented in the base class, you do not have to update code in every derived type; they inherit the changes.
Polymorphism
Polymorphism allows values of different data types to be handled using a uniform interface. The primary usage of polymorphism is the ability of objects belonging to different types to respond to method, field, or property calls of the same name, each one according to an appropriate type-specific behavior. The programmer (and the program) does not have to know the exact type of the object in advance, and so the exact behavior is determined at run time
See also:
http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming
http://en.wikipedia.org/wiki/Type_polymorphism
It's a way to view your code in a more intuitive, real-world way. (You package the data and all possible operations on that data together.) It also encourages encapsulation, abstraction, data hiding... What you're really looking for is the advantages of OOP.
Basically, classes allow you to put your data with the code - i.e. organization.
Also, classes allow your "followers" to customize your classes without rewriting your code, but rather creating new inherited classes.
Every class-based code might be rewritten with functions, but it would be much harder to understand.
Generally, its so that you can customize the behavior of that set of functions. Typically you have a bunch of functions that work in concert.
People who use these functions may want to only modify one of them for some special case. Or maybe you provide a class that forces the functions to interact in a certain why, but you can't define what they'll actually do.
A trite example: imagine if you had some library to check that some things didn't overlap.
class Comparator:
def Greater(self, left, right): pass
def Less(self, left, right): pass
def EnforceNoOverlap(self, comparator, left, right)
assert comparator.Greater(left, right) != comparator.Lesser(left, right)
It a way to make your code more granular, with proper data hiding, separation of concerns and some other best practices.
IMO using only functions in your code sooner or later leads to spaghetti-code that is hard to maintain and extend. It's harder to fix bugs, its harder to implement new features, because often there are lots of code replication.
Also you can't use polymorphism in your code design, so you can't work with abstractions.
the classes/object is the way of implementation object-oriented application design. it covered detailed in numerous OOAD/OOP books.