I am trying to learn OOP. The so called 'real world' examples in the books I am reading aren't helping.
All the examples like Pet, Car, Human aren't helping me anymore. I need REAL LIFE examples that like registration, user profile pages, etc.
An example:
$user->userName = $_POST['userName'];//save username
$user->password = $_POST['password'];//save password
$user->saveUser();//insert in database
I've also seen:
$user->user = (array) $_POST;
where :
private $user = array();
Holds all the information in an array.
And within that same class lies
$user->getUser($uid);
// which sets the $this->user array equal to mysqli_fetch_assoc() using
//the user id.
Are there any real world examples implementing OOP in the many different php applications (registration, login, user account, etc)?
OOP is not only about how a single class looks and operates. It's also about how instances of one or more classes work together.
That's why you see so many examples based on "Cars" and "People" because they actually do a really good job of illustrating this principle.
In my opinion, the most important lessons in OOP are encapsulation and polymorphism.
Encapsulation: Coupling data and the logic which acts on that data together in a concise, logical manner
Polymorphism: The ability for one object to look-like and/or behave-like another.
A good real-world example of this would be something like a directory iterator. Where is this directory? Maybe it's a local folder, maybe it's remote like an FTP server. Who knows!
Here's a basic class tree that demonstrates encapsulation:
<?php
interface DirectoryIteratorInterface
{
/**
* #return \Traversable|array
*/
public function listDirs();
}
abstract class AbstractDirectoryIterator implements DirectoryIteratorInterface
{
protected $root;
public function __construct($root)
{
$this->root = $root;
}
}
class LocalDirectoryIterator extends AbstractDirectoryIterator
{
public function listDirs()
{
// logic to get the current directory nodes and return them
}
}
class FtpDirectoryIterator extends AbstractDirectoryIterator
{
public function listDirs()
{
// logic to get the current directory nodes and return them
}
}
Each class/object is responsible for its own method of retrieving a directory listing. The data (variables) are coupled to the logic (class functions i.e, methods) that use the data.
But the story is not over - remember how I said OOP is about how instances of classes work together, and not any single class or object?
Ok, so let's do something with this data - print it to the screen? Sure. But how? HTML? Plain-text? RSS? Let's address that.
<?php
interface DirectoryRendererInterface
{
public function render();
}
abstract class AbstractDirectoryRenderer implements DirectoryRendererInterface
{
protected $iterator;
public function __construct(DirectoryIteratorInterface $iterator)
{
$this->iterator = $iterator;
}
public function render()
{
$dirs = $this->iterator->listDirs();
foreach ($dirs as $dir) {
$this->renderDirectory($dir);
}
}
abstract protected function renderDirectory($directory);
}
class PlainTextDirectoryRenderer extends AbstractDirectoryRenderer
{
protected function renderDirectory($directory)
{
echo $directory, "\n";
}
}
class HtmlDirectoryRenderer extends AbstractDirectoryRenderer
{
protected function renderDirectory($directory)
{
echo $directory, "<br>";
}
}
Ok, now we have a couple class trees for traversing and rendering directory lists. How do we use them?
// Print a remote directory as HTML
$data = new HtmlDirectoryRenderer(
new FtpDirectoryIterator('ftp://example.com/path')
);
$data->render();
// Print a local directory a plain text
$data = new PlainTextDirectoryRenderer(
new LocalDirectoryIterator('/home/pbailey')
);
$data->render();
Now, I know what you're thinking, "But Peter, I don't need these big class trees to do this!" but if you think that then you're missing the point, much like I suspect you have been with the "Car" and "People" examples. Don't focus on the minutiae of the example - instead try to understand what's happening here.
We've created two class trees where one (*DirectoryRenderer) uses the other (*DirectoryIterator) in an expected way - this is often referred to as a contract. An instance of *DirectoryRenderer doesn't care which type of instance of *DirectoryIterator it receives, nor do instances of *DirectoryIterator care about how they're being rendered.
Why? Because we've designed them that way. They just plug into each other and work. This is OOP in action.
Purchase a book like "PHP and Mysql everyday apps for Dummies".
Its old I know [2005] but it shows concepts of User Logins, Forum, Shopping Carts, etc in both Procedural and Object Oriented with Mysqli.
It helped me learn Object Oriented PHP, I studied it a lot. Well worth the money.
OOP is much like grouping bits of your program into reuseable pieces. Its not that hard to be honest with you its just the idea of packing your functions into classes.
Real world mini example of OOP stuff below:
CLASS DATABASE
CLASS SESSIONS
CLASS WEBFORMS
CLASS EMAIL
CLASS ACCOUNTS (Example Functions below)
FUNCTION SELECTACCOUNT
FUNCTION CHECKPASSWORD
FUNCTION CHECKUSERNAME
FUNCTION CREATEACCOUNT
I hope you keep at it, PHP 6 will be re-engineered to support OOP more than ever.
Good Luck!
Whilst I know that this question has been answered already, I feel as though I can add value here.
I don't believe that you should use PHP as a programming language to learn OOP. If you wish to learn OOP for web applications, you should really be looking at C# or Java. Once you have learned OOP, then you can apply this knowledge to PHP. One example of a book I used to learn OOP was Big Java by Cay S. Horstmann
Why do I say this??? Because there are literally millions of examples on PHP of how to do stuff, however not many are examples of how to program properly. Further to this, PHP allows you to take many shortcuts, which would not be acceptable with the likes of Java. As such, if you program PHP with a Java head, then I believe that you will be a stronger programmer. OOP is not language specific, it is a programming paradigm.
If you must learn OOP using PHP, then I would recommend that you take a look at some real source code in public repositories of github. You can search them in packagist.org. If they are a decent public repository, they will contain a readme.md file which would show you how to use the composer packages. e.g https://github.com/moltin/laravel-cart is an example of a shopping cart package which you would be able to use in your application. Notice how you don't need to look at the package source code to understand what the packages do. The package has been written, and you don't care about how they work, but you use them so you only need to know how to use them. This is exactly what OOP is about.
I don't care how the shopping cart class adds an item to the cart, I just want to create a new cart and add something to it.
What you are doing however is diving into the source code as a tool to understand how OOP works.
Further to this, and probably more importantly, for web application development, I would research the MVC design pattern.
The MVC design Pattern stands for Model, View, Controller. Where in the case of a web application, The Model is responsible for modelling the database, the view is responsible for displaying content to the user. The controller is responsible for interacting with the model and handling user input.
I then think you should try to install the Laravel Framework or other "decent modern framework" on your local machine. Why do I say modern, because modern frameworks require a minumum PHP version of 5.3+ which mean that the PHP on your machine would support real OOP similar to that which you would get from the likes of Java.
There are many tutorials which will show you how to build web applications in laravel. Immediately, you will see that when you create a controller, you extend a BaseController. When you create a Model, you extend Eloquent. This means that you will already be using Polymorphism in your code. You will see that by using classes, they are being encapsulated, and you will see that each class has a specific role.
When you would like to interact with the database, you will initially create a new Model object within the controller methods. As you start to learn more, you will start learning how to inject dependencies into the controller, then learning how to dump your models and create repositories and program to interfaces instead.
A decent book on learning Laravel for beginners would be https://leanpub.com/codebright by Dale Rees. I met Dale at a Laravel meetup about 2 weeks ago.
Further to this, as you become more proficient building web applications, you will start to learn how to apply the following principles to your programming:
Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Segragation Principle
Dependency Inversion Principle
As astropanic said, you could take a look at the source code of a good PHP framework or library. I recommend Zend Framework, it's very modular and has a great, professional design. I would say it is a very good piece of object-oriented PHP code.
Still, I think it's not that easy to learn from a huge piece of production code, since it wasn't really made to teach you anything. But if you want real-world object-oriented PHP code, the Zend Framework (or Symfony, or maybe CakePHP) is probably the way to go.
I'd advise you to stay away from any framework at this moment, if you do not know OOP, digging into zend or any other framework would be too much.
PHP OOP is quit funny... like ha ha funny, because it's supported, but PHP is not an OOP language like java or c#.
Short example just to underline my statement:
// define class
class User {
// define properties and methods
public $name = "";
}
// instantiate class
$user = new User; // or new User() or new user, it's all the same
echo $user->name;
but if you want to do OOP "on the fly" you can do the following:
$user = (object) array('name' => 'Peter');
and then
$user->name;
but you can use OOP like you would in java or c# but not to the same extend - and have in mind, popular systems like wordpress and drupal are not pure OOP! but you can do inheritance and other classing OOP stuff in PHP as well.
I haven't gone far in PHP OOP, but the more i get into it the more easier it becomes. The objects examples are just there for you to understand how OOP works. I understand and been through this before, OOP is just about properties and methods ( normal variables and functions). I programed in real OOP myself applying the examples from my tutorials and didn't necessarily have to be in real world. That is just like been spoon fed and you would never understand OOP and would be easy to forget. My advice learn to understand. If you understand, you can do anything and would realize the power of OOP. I downloaded this book and i think you should too. But that is just like someone building your apps for you...
Here a link to the book PHP and Mysql everyday Apps For Dummies
you're right 99% of the tutorials that you'll find online are too basic, and they don't make sense. My suggestion to anybody trying to learn object oriented programming is:
find some code that you've written in procedural programming and try to convert it into OOP.
Take all your variables and make them a properties of a class, find a suitable class name. Then take all your functions, if you have functions, and group them within a class. If you wrote your code without using functions, first try to convert your code into a group of functions. find suitable function names, a function should define what a piece of code does. Once you have your functions move them into a class.
I'll give you a simple example of a pagination code that I converted into a reusable pagination class. find the full tutorial on youtube: https://www.youtube.com/watch?v=X38IRlyY_ww&t=91s , link to the source code is on the description box
class Paginator{
/*the class need to know the current page to calculate the offset
the offset tell my sql how many rows to skip */
private $current_page;
//the limit is the number of results to display per page
private $limit;
/*pagination links to display below the results with next
and previous button*/
private $pagination_links;
//the last page of your pagination links
private $last_page;
.
. etc
public function __contruct($number_of_rows_found,$results_to_display_per_page){
//the paginator uses the number_of_rows_found to determine the last page
$this->last_page = $number_of_rows_found/$results_to_display_per_page;
//get the current page, set it to 1 by default
$this->current_page = isset($_GET['page']) ? ($_GET['page'] : 1;
}
public function generate_pagination_links(){
this method uses the last_page property to generate pagination links
if the last page is 3, this will give you 3 pagination links
for ($page = 1; $page <= $this->last_page; $page++) {
//use
}
}
public function get_offset_and_limit(){
//this method calculates the offset based on the current page
return "LIMIT $this->per_page OFFSET ".($this->page - 1) * $this->per_page;
}
.
.
.etc
}
}
Then to use the pagination class, you create a new instance of it, and pass the
number of results you want to display per page, and the the number of results returned
by your query as parameters. The pagination class will generate pagination links for
you and calculate the offset and limit. That's a good example of a php reusable
class, you can use it in your multiple projects without having to rewrite or change it.
$paginator = New Paginator($rows_found,8);
$pagination_links = $paginator->get_pagination_links();
$offset_and_limit = $paginator->get_offset_and_limit();
//apend the limit and offset to your sql query
$query = $query. ' '.$offset_and_limit;
$connection = getdbconnection();
$stmt = $connection->prepare($query);
$stmt->execute();
$movies = $stmt->fetchAll();
Ofcourse there're more advanced concepts into OOP that are not covered in this example, but this should give you a basic understanding of how classes and objects work
I suggest also to see my wrapper Arrayzy. It's a native PHP arrays easy manipulation library in OOP way.
So if you work with native PHP array functions - you could do the same things in OOP and Arrayzy helps you with it, for example:
// Functional programming:
$array = ['a', 'b', 'c'];
$resultArray = array_merge($array, ['c', 'd']);
and
// Object-oriented programming:
$obj = Arrayzy\MutableArray::create(['a', 'b', 'c']);
$obj->mergeWith(['c', 'd']);
$resultArray = $obj->toArray();
In both cases the result array will be:
Array(
0 => 'a'
1 => 'b'
2 => 'c'
3 => 'c'
4 => 'd'
)
Check how does this mergeWith method (or other) works under the hood.
I think this is a nice example which shows that almost everything functional code you could replace with OOP code like in this library. But with OOP you get much more and you could also check Functional programming vs OOP question to learn more details what's a cons and props of it.
Related
I love the PHP language, Ive got SOME coding experience but I am fairly new to PHP although I have been learning a lot I feel I am now stuck / held back by not getting the hang of OOP concepts, although I have been browsing through multiple tutorials.
This is not so much a question about the code itself but rather behind the logic of it
Consider this tutorial I worked from
class person {
var $name;
function set_name($new_name) {
$this->name = $new_name;
}
function get_name() {
return $this->name
}
}
$stefan = new person();
$jimmy = new person;
$stefan->set_name("Stefan Mischook");
$jimmy->set_name("Nick Waddles");
echo "Stefan's full name: " . $stefan->get_name();
echo "Nick's full name: " . $jimmy->get_name(); ?>
I understand what is going on above and I understand the concept but I cant see the benefit of it, I just feel I could have created the above in a much simpler way by simply doing
function person($name){
return $name;
}
echo person("Tim Jones");
Why the getter and the setter function, why not just one function in class person?
Why go through all that code above when my function above is so much shorter?
Where is the benefit here?
I'm basically just looking for someone to give me a bit of clarification on the whole OOP concept which I cant seem to get by the many repetitive tutorials I have been reading.
A good case for using classes is when you may want to expand or rewrite functionality later on.
A few years back I wrote an application in PHP which was used to create issues within Jira. At this point, I was using SOAP to perform the actual issue creation and updates using the published API
Later on, within the same application, I needed to use features within Jira which were associated with the Atlassian Greenhopper/Agile extension. This extension used a REST API and it became apparent that Atlassian was moving all their APIs across to using REST
As I had used a class for the calls to Jira, all the actual grunt work in the background was abstracted. I knew which data was expected and what data I would be expecting
In the end, I wrote a new class to use REST (via cURL calls), and re-wrote the class which accessed Jira. I didn't have to go through the whole application and check each call to a Jira function as the data in and data out was the same.
In reality, the classes I wrote all descended from the REST class:
REST -> JIRA_BASE -> JIRA
The JIRA_BASE class contained methods which were common across all Jira projects (get project names, get user id's etc). The JIRA class itself contained a couple of functions (createJiraIssue and updateJiraIssue) which were particular to each Jira project
The other advantage of using classes and objects is that you can put place-holders in for functions. In the REST class, trying to use a DELETE method (rather than GET, POST or PUT) for a REST call would error straight away (I hadn't written it as I didn't need it). However, I have re-used the same class in another application where I did need to use the DELETE method so that is now written
It also became apparent that the new application needed a change in one aspect of functionality. This was implemented without re-writing any of the calling code
Getters and setters are used to ensure that data is accessed in a controlled manner. If you just use a variable within a script, any part of that script could alter the data. If that data is stored within a class and set to private, then only a call to the getter or setter can alter or retrieve that data.
Additionally, getters and setters can alter the way the data is actually stored but still present it in a usable format. For example, when performing a call to
$obj -> setName('DaveyBoy');
that data could be reversed, escaped, encrypted, stored in session variables, sent to a database and rot13'ed (in no particular order). But, a call to
$name = $obj -> getName()
would still store 'DaveyBoy' in $name without any intervening steps.
I've rambled about classes and why I use them but, hopefuly, this helps to explain a bit.
The advantages of OOP is that anything acting upon a class or object does not need to know how that class or object works under the hood, and much more complicated things can be accomplished in the background with the bulk of your application being un-involved, making your code much more readable.
Consider the following [partially]pseudocode web app example:
$users = array();
$users[] = new User('joe', ADMIN, ACTIVE);
$users[] = new User('jane', ADMIN, ACTIVE);
$users[] = new User('bill', USER, INACTIVE);
class User {
public $Name;
public $Security;
public $Active;
public function __construct($name, $security = USER, $active = INACTIVE) {
$this->Name = $name;
$this->Security = $security;
$this->Active = $active;
}
public function ToggleActive() {
//Not actual working code ahead
$this->Active = ($this->Active) ? INACTIVE : ACTIVE;
$sql->query('UPDATE users SET active=$this->Active WHERE name=$this->Name');
}
public function SetSecurity($security) {
//More non-functional examples
$this->Security = $security;
$sql->query('UPDATE users SET security=$this->Security WHERE name=$this->Name');
}
}
?>
<html>
<form>
<!-- this is, of course, the wrong markup, but the concept is there-->
foreach($users as $user) {
<name>$user->Name</name>
<security>$user->Security <button $user->SetSecurity(ADMIN)>Set Admin</button> <button $user->SetSecurity(User)>Set User</button>
<active>$user->Active <button $user->ToggleActive>Toggle Active</button>
}
<!-- you could even have the class itself output the form html with something like $user->DrawEntryHTML();-->
</form>
</html>
Obviously, there is a lot more that goes in to the web app interface of such an operation (AJAX, function handlers, etc.), but the basics are there, and only the user object itself needs to know how to perform the operation. The rest of your app can simply say Hey, user. You're active now.
OOP gives you an abstract but meaningful way of accomplishing what you want your application components to do. In most applications these days, when a user interacts, or a task happens, a number of things need to happen in order to store, display, and modify its elements. You also gain the advantage of only needing to change a small bit of code in your class in case of a change, update, or feature addition, rather than chasing all over the rest of your code for everything that relates to your users (in this case).
You'll find that a well-written OOP application has a very short program loop (or index.php), and the bulk of the work happens within its class objects.
Consider what happens when you want to change the behaviour of the code - suppose it's been running for a while and you discover that you have lots of duplicate records where people have used variants in the whitespace and capitals. You might then want to amend the code to....
function set_name($new_name) {
$new_name=trim(strtoupper($new_name));
$new_name=str_replace(' ',' ', $new_name);
$new_name=str_replace(' ',' ', $new_name);
$name_parts=explode(' ', $new_name);
$this->surname=array_pop($name_parts);
$this->forenames=implode(' ', $name_parts);
}
function get_name()
{
return $this->forenames . ' ' . $this->surname;
}
But you don't need to change any of the code which interacts with the object.
Now think about a class which describes organizations rather than individuals - they have names - but not forenames and surnames. If you have a class with the same interface (get_name, set_name) then you can throw a mixed bundle of person and organizations at your Christmas card printer application without having to amend the app to cope with the different data types.
(tutorial examples are kept very simple for a reason, unfortunately a lot of the benefits of OO only become apparent when dealing with complex problems - stick with it and you'll get there)
Notice that my answer focus not on the major strengths of OOP as you have already read on those and - as they currently don't apply to your situation - were meaningless. I'm going to focus on what OOP can do to you right now.
The example you give is actually a good one.
Say that you also wanted to attach height, weight, birthday and profession to a person.
Not using objects you could create an array of arrays (to store multiple persons with multiple attributes) but 2 hours into the coding you would try to access the persons job as:
echo $persons[0]['job'];
And it would fail as that field is actually named 'profession'; using objects not only will your IDE know the getters it will also help you.
The major strength of OOP is only really seen when you work in teams or expose code to be used by others however the example I gave should suffice to understand why even as a single developer there are benefits.
That being said, for over simplistic actions it can be overkill.
I'm working in a PHP project where testing software was neglected a long time.
The business logic is full of hard coded dependencies and immediate database access throught some hand-crafted (Oracle) SQL.
I've given up trying to build automated integration tests, because of complex database setup, tight compling to the (complex) database fixture and missing in-memory solutions.
For me it looks like the best place to start, is to test the business logic. Therefore I need to refactor the code to get the data access code seperated from the business logic, I guess. Still I'm struggeling with some basic design questions:
What is the preferred way to encapsulate/get rid of this complex SQL? Is there any design pattern which has some good hints on how to get data from the datasource in an configurable way? Injecting Propel Active Query objects seems the help in some cases, but in complex cases they will be very hard to mock I guess.
Is there a good book about Software Architecture + Unit Testing for Applications that need are heavily making use of their database?
To answer your 2nd question: Working Effectively with Legacy Code is what you need: it explains several pattern to break dependencies to make a code testable.
Regarding your first question: it depends on your current case. Here are a few example described in depth in the book:
Example 1 - Extract and override Call
If you have a classe like (example isn't in php, but you'll get the idea)
class MyClass {
int getNbEligibleItems(){
List<Item> rawItems = readInDb();
//Now count elegible ones
}
List<Item> readInDb(){
//Directly call DB and return a raw list
}
}
Then you could make readInDb virtual, and use a mock in tests:
class TestableMyClass : MyClass {
override List<Item> readInDb(){
//Return a list of hard code test items
}
}
Example 2 - Parametrized constructor
If you have a class like this
class MyClass {
private IDbReader _reader;
MyClass(){
_reader = new DbReader();
}
int work(){
List<item> items = _reader.read();
//Work with items
}
}
Then it would be possible to changes constructors to
MyClass() : this(new DbReader()){ }
MyClass(IDbReader reader){
_reader = reader;
}
So it would be possible to mock db in tests
So, to put it in a nutshell: there are a lot of technique that could help in your case. We' need some code to be more specific. And I recommend reading this book as it provide lot of answers in those cases.
Is there a PHP framework, that lets me write such code.
class Item
{
private $_id; //primary key
private $name;
private $price;
function __construct($name, $price) {
$this->name = $name;
$this->price = $price;
}
}
...
$item = new Item(...);
db->Save($item);
...
db->Delete($item);
...
db->Update($item);
...
Item[] = db->Fetch($whereClause);
Yes Admins, I searched on Google, but I got lost in the vast sea (Doctrine, Propel, ActiveRecords,...), asked a different question on SO (which prohibited me from comparison), so I am asking differently now, which framework lets me write such simple code, without much additional coding, no XML, YAML.
Or additionally how to write such if not there. Any pointers will be helpful. Off course I have PHP 5.3 and can use PDO, but performance is a concern (magic functions...), not extensive features list (we support this thing also, that you will never use).
OOPS: forgot to add, don't want a framework like CakePHP, etc. I am writing simple php without frameworks, want just some libraries that I can include into my project and call the above syntax. Its ok for me, if it requires a little SQL behind.
If you do not need a full application framework, for example, you might have written your own framework or if you are not using any framework, I can not recommend Redbean enough. On the plus side, Redbean also has bridges for frameworks such as Zend and CodeIgniter.
I like Redbean because it does not require much configuraion, no YAML, XML or other configuration. The library is very light and quite performant. The amount of features is about "just right", there are no superfluous features, but you do have all the things you need in there. The syntax is also very close to the one you want.
Now the downside: You need to adhere to strict table structures. For example, an ID column is need for link tables. Support for table name prefixes has also been removed in 3.0. However, I don't find these things to be important, so it isn't a huge issue for me.
If it is, you could even fork the library and modify it to your needs.
php-activerecord will probably fit your needs. Model classes should extend from ActiveRecord\Model:
<?php
class City extends ActiveRecord\Model {
// Table name will be defaulted to 'cities', but you can override it
static $table_name = 'mycities';
// Primary key will be defaulted to 'id', you can override it too
static $primary_key = 'city_id';
// Associations
static $belongs_to = array(
array('country')
);
static $has_many = array(
array('citizens', 'class_name' => 'User')
);
}
// Creating
$city = new City(array('name' => 'New York'));
$city->save();
// Find City with id=5, output some data
$anotherCity = City::find(5);
echo $anotherCity->country->location;
foreach ($anotherCity->citizens as $citizen) {
echo $citizen->full_name;
}
This is a very simple example, php-activerecord has some nice features:
Sensible conventions, you can reduce amount of code by following them (in fact, you should follow them if you're starting from scratch)
Validations to enforce business rules
CRUD for manipulating objects in OO-way
Callbacks - advanced pieces of code to associate with different lifetime events of your models
I think a lot of them. ZendFramework is one of such frameworks.
cake PHP is very near to your requirement
search scfolding with cake PHP is very near to your requirement
Thanks
There are many frameworks. See this for an example.
Every frameworks have there own way of API, through which you can use many features, such as db, xml.
For ORM only Doctrine is very Excellent
For rapid development and scaffolding features Codeigniter is very good.
For in-depth framework with many pre-built libraries Zend-Framework is one of the best. It has libraries for Doctrine too.
I recently started learning the basics of OOP in PHP.
I am new to a whole lot of concepts.
In the traditional procedural way of doing things, if I had a repetitive task, I wrote a function and called it each time.
Since this seems to be a regular occurence, I created a small library of 5-10 functions, which I included in my procedural projects and used.
In OOP, what is the valid way of using your functions and having them accessible from all objects?
To make things closer to the real world, I created a thumbnail class, that takes an image filename as an argument and can perform some operations on it.
In procedural programming. when I had a function for creating thumbnails, I also had a function to create a random md5 string, check a given folder if said string existed, and repeat if it did, so I could generate a unique name for my thumbnails before saving them.
But if I wanted to generate another unique name for another purpose, say saving a text file, I could call that function again.
So, long story short, what is the valid OOP way to have the method randomise_and_check($filename) (and all other methods in my library) accessible from all the objects in my application?
Great question. The first thing you want to do is identify the primary objects you will be working with. An easy way to do this is to identify all the nouns related to your project. In your example it sounds like you will be working with images and strings, from this we can create two classes which will contain related attributes (functions, member variables, etc). And as you wisely mentioned, we need to ensure that the algorithms you are converting into OOP can be called from any context, so we try to keep them abstract as possible (within reason).
So for your specific situation I would suggest something like:
// Good object reference, abstract enough to cover any type of image
// But specific enough to provide semantic API calls
class Image
{
// Using your example, but to ensure you follow the DRY principle
// (Don't repeat yourself) this method should be broken up into two
// separate methods
public static function randomise_and_check($fileUri)
{
// Your code here
....
// Example of call to another class from within this class
$hash = String::generateHash();
}
}
// Very abstract, but allows this class to grow over time, by adding more
// string related methods
class String
{
public static function generateHash()
{
return md5(rand());
}
}
// Calling code example
$imageStats = Image::radomise_and_check($fileUri);
There are several other approaches and ideas that can be employed, such as whether or not to instantiate objects, or whether we should create a parent class from which we can extend, but these concepts will become evident over time and with practice. I think the code snippet provided should give you a good idea what you can do to make the jump from procedural to OOP. And, as always, don't forget to read the docs for more info.
-- Update --
Adding an OOP example:
class Image
{
protected $sourceUri;
public function setSourceUri($sourceUri)
{
$this->sourceUri = $sourceUri;
}
public function generateThumb()
{
return YourGenerator::resize($this->getSourceUri);
}
}
$image = new Image();
$image->setSourceUri($imageUri);
$thumbnail = $image->generateThumbnail();
The way I see it, you have two options:
Don't worry about cramming yourself into OOP and just make them standard, global functions in some utilities.php file you include wherever you want to use it. This is my preferred method.
If you take the more OOP approach, you could make them static functions ("methods") in some utilities class. From the PHP documentation:
<?php
class Foo {
public static function aStaticMethod() {
// ...
}
}
Foo::aStaticMethod();
$classname = 'Foo';
$classname::aStaticMethod(); // As of PHP 5.3.0
?>
Create an (abstract) Util-class with static functions:
example from my Util class:
abstract Class Util{
public static function dump($object){
echo '<pre class=\"dump\">' . print_r($object, true) . '</pre>';
}
}
How to use:
<?
$object = new Whatever();
//what's in the object?
Util::dump($object);
?>
For a beginner, OOP development is not all that different from procedural (once you master the basic concepts it gets quite a bit different, but that's not important to learning the basics).
You deal in OO concepts all the time, you just don't realize it. When you click on a file in your file manager, and manipulate that file.. you're using Object Oriented concepts. The file has attributes (size, type, read-only, etc..) and things you can do with it (open, copy, delete).
You just apply those concepts to development by creating objects that have properties and things you can do with it (methods).
In the OOP world, you don't typically make things available to everything else. OOP is all about "encapsulation", which is limiting access to only that which is needed. Why would you make a "haircut" method available to an orange juice object? You wouldn't. You only make the "haircut" method available to objects that need haircuts.
Writing reusable OO software is very difficult. Even professionals can't get it right a lot of the time. It requires a mixture of experience, training, practice, and frankly luck in some cases.
You should read about Dependency Injection as it seems to apply to your specific problem. Basically, you have an object that depends on some abstraction, maybe the "Image Library" functionality. In your controller, you would create an instance of the "Image Library" object and inject that dependency into whatever other objects required it.
That is, you need to stop thinking on the global scope altogether. Instead, you have to compartmentalize functionailties in a sane way and tie them together. Basically, objects should only know about as little as they need to know (also look up Law of Demeter and SOLID). I reiterate, this is tough to do correctly, and most of the time you can still have an application that works beautifully even if it's done incorrectly.
If you want to be very strict about this you should apply this line of thinking to everything, but if you have a function that wraps something very simple like return isset($_POST[$key]) ? $_POST[$key] : $default; I see no real harm in creating a global function for that. You could create an HttpPost wrapper class, but that is overkill in most circumstances IMO.
The short answer: use ordinary function. OOP encourages you to think about data and associated routines, using static functions instead of ordinary does not make your program more object-oriented. Following the single programming paradigm is not practical, combine them when you see that this will make your program cleaner.
From a maintenance and code organization standpoint, in PHP5, does it make sense to create/define objects and classes for XML data coming from a web service?
Using Twitter's API as an example, I would have a class for each API method (statuses, users, direct_messages, etc). For statuses/public_timeline, I would have something like this:
class Statuses {
public $status = array(); // an array of Status objects
public function __construct($url) { // load the xml into the object }
}
class Status {
public $created_at, $id, $text; // and the rest of the attributes follow...
}
$public_timeline = new Statuses('http://twitter.com/statuses/public_timeline.xml');
echo $public_timeline->status[0]->text;
Or is it better to dump everything into an associative array, so items would be accessed like this:
// the load_xml function is just something that will dump xml into an array
$public_timeline = load_xml('http://twitter.com/statuses/public_timeline.xml');
echo $public_timeline['statuses']['status'][0]['text'];
First design:
Strictly following object-oriented principles
Seems like an approach better suited for compiled languages
Second design:
A lot less maintenance would be needed if the API is modified. If the API adds an attribute to the XML, the corresponding class would need to be updated in the first design.
I think this depends on your project ...
First design:
Strictly following object-oriented principles
Seems like an approach better suited for compiled languages
Necessary in a big application
Easy to reuse
Benefiting when passing data around
You have methods to add functionality, not just data
Second design:
A lot less maintenance would be needed if the API is modified. If the API adds an attribute to the XML, the corresponding class would need to be updated in the first design.
Straight forward & quick solution
Little code
I'm with Philippe: if your application is going to be really small (just calling the status methods for example), go with solution 2.
I agree that creating a bunch of classes just to echo status informations isn't really needed in the first place. But if your application it's going to be huge, design with solution 1 in mind. As you go along with your development, you're going to create specific methods that would belong to specific classes. Sometimes you would like to create a method to "order" status messages. Who knows? That's why we create classes, each one with it's own responsibility, so you wouldn't need to search a big php file with hundreds of functions.
I do believe that if you don't know how your application is going to grow, a "best-of-both worlds" approach would be creating classes to at least each Twitter categories (Timeline, Status, User, etc, totalizing maybe 12), instead of each method. Is a good solution IMO in your case, if you don't want to create too many classes.
If you're working with XML in PHP5 then I think the best would be to use SimpleXML. Then you have the best of both worlds. You can access your values in a very array-like way. However you can extend SimpleXML class to provide methods and other custom nice-to-haves.
// To get the effect of an array...
$twitte = 'http://twitter.com/statuses/public_timeline.xml';
$public_timeline = simplexml_load_file($twitte);
echo $public_timeline->statuses->status;
Or extend the SimpleXml Class
class MyXml extends SimpleXml
{
public function quickStatus()
{
$status = $this->xpath("/statuses/status");
return (string)$status[0];
}
}
// then access like
$twitte = 'http://twitter.com/statuses/public_timeline.xml';
$public_timeline = simplexml_load_file($twitte, 'MyXml');
echo $public_timeline->quickStatus();
The above example is just to show how to extend the class. If you'd like more info you can check out the XML class from a library I've created on Google Code