Forum Moderators: coopster
I have read a beginners article on the 'net about OOP, using PHP as an example and I think I kind of understand the basics in that objects are like functions. If anyone can offer me a better definition please do!
As I understand it PHP is not an OOP language as such, but it does have the functionality to be one if needed.
When I have used PHP I have used it in a purely procedural manner, why would people need to use it in an OOP way? Can anyone give an example of how OOP might be used in a web development context, so I can understand it's practical use.
Cheers,
Helen.
There are a number of links to tutorials and practical examples on this page:
[faqts.com ]
In regards to web development, however, I have found one of the greatest benefits is based on the concept of Encapsulation. Centralizing both the business rules and the data management in one piece of code will greatly reduce initial bugs. Additionally, future maintenance can be done more quickly and with lower risk of introducing new bugs.
Besides the obvious fact that encapsulating rules with the data provides one point of maintenance, there is a very underrated value of freeing up your mind to always focus on the task at hand. When you are writing code/script to generate HTML, there is no way that you should have to be concerned about pricing formulas. It is much easier to set properties on the object to reflect the current buyer, quantity, address, etc. details and then simply read the price property. Stated another way, it lets you easily move your thinking from one level to another without worrying about some details getting lost.
One "downfall" of OOP for websites is that a great deal of the literature on OOP was originally written for client/server, heavy client, or single machine applications. So when a "Customer" object is loaded, there may not be too many problems with simultaneously loading all of their addresses, contacts, phone numbers, and order numbers (maybe even each order). That's because that data could stay in RAM as the user went from one screen to another.
That doesn't work for web apps. So one of the challenges in building a good OO website is to create objects that give you the benefits of business/data encapsulation, but don't require you to load an entire object tree for every page hit.
Also, one of the things that you really need to have a handle on is n-tier architecture. It has other names also. But what it refers to is that you need to add layers for the OO model to really deliver benefit. That is, you need to clearly define your presentation, business, data access, and data layers. Each of these may be further divided. The presentation layer, for instance, has elements on your server (the php that cranks out the html & javascript) and on the client. The data layer is at the bottom, and the client at the top. No layer has any knowledge of, and makes no calls into any of the layers above itself.
I know that's more than you wanted on the n-tier stuff. But working with other programmers that were new to OO concepts, I found that a lack of understanding in that area was always at the root of breakdowns in coding.
One other question I forgot to ask...
Are there things you can only do if you use OOP or are the uses of classes and functions etc, just a way to improve and condense your code?
The biggest benefit of OOP is, as someone already said, encapsulation. All the information about a given thing is within that object. For example, the customer's name, address, zip code, credit terms, etc. are all right there. I'm currently working on a project in VB where someone didn't understand this and instead kept everything in parallel arrays. It's a nightmare.
Included in that encapsulation is the ability to call the object's own functions. The customer has its own Save routine, for example. It makes code reuse much easier than if you had a globally accessible SaveCustomer function to which you passed the Customer object or structure.
A real OO language includes inheritance. Here we leave VB6 behind ... I'm not sure about PHP. Perhaps all customers share many charactaristics. But some customers are corporate customers, some government customers, some private customres, and some donors. Each of these types of customers has some unique charactaristics. You would then have a Customer base class from which your specific customer classes would inherit. They all get the properties and methods of the Customer class, but each can add its own. In addition, each can override the function of that base class. For example, the Save function may handle everything for the corporate and private customers, but the government customer is saved differently. The GovernmentCustomer class has its own Save routine that is called instead of the base class Save.
Finally, OO offers polymorphism, its most difficult concept. Suppose you keep a list of the Customer objects in your application. You don't want a separate list for each type of customer. You tell your application that you have a list of Customers. When the time comes to call Save, the appropriate Save is called because each Customer calls its own Save routine -- whether that's the Save defined in the base class or the specialized Save for the GovernmentCustomer class.
Hope that helps. I've gained a new appreciation for each aspect of OOP recently. Actually designing a system that uses polymorphism extensively, and at the same time working on an old one that doesn't even use encapsulation makes OOP look SO helpful!
[csis.pace.edu...]
Notice that all four solutions use classes, but they are not considered OOP.
If you can get to the "naive OOP solution" in three days, that's pretty darn good.
I think you had better plan on *much* longer for the better solutions.
When I said I needed to learn about OOP in 3 days, don't worry, I don't expect to learn OOP in it's entirety. I think I have some of you worried that I might be underestimating the task in hand!
From what I've read so far, it seems to me that OOP is just a different way of thinking about coding. I must admit it hasn't blown my mind and made me rethink the way I do things yet, the way that css and xml did when I first read about them. But perhaps OOP is a bit different from that.
All I'm really hoping for is to not look a complete dunce on Monday ;)
just a different way of thinking about coding
Just! heh heh heh.
Conceptually, the jump to CSS is, I would say, nothing compared to the jump to OOP.
Speaking as someone who has been coding PHP with "OOP" for a while now but just hasn't taken the time to really learn about this PATTERN stuff, I know enough to know that if you don't understand patterns, you aren't truly getting OOP.
Tom
1) Instead of writing special code for each instance, you maintain a set of classes
2) When in use, page rendering looks to the class-set
i.e.
<font color="red" size="4" face="Arial">big red</font>
<font class="bigred">big red</font>
Using the "bigred" class anywhere you need big, red text simplifies your code, cuts down on client overhead, and enables swift global modifications to what "big and red" means.
Likewise:
<?
function getCustomDate() {
$thisdate=strftime("%B %d, %Y");
return $thisdate;
}
?>
<h1>Today is <?echo getCustomDate()?></h1>
Using the "getCustomDate()" function anywhere you need its custom date format simplifies your code, cuts down on server overhead, and enables swift global modifications to what the current date printout looks like.
Basically, you make "objects" that perform complex routines, and then call those objects when you need them, either for use by themselves (not very OOP) or as subroutines in larger, even more complex "objects".
Like in "Jurrasic Park"...all of those running dinosaurs...did they individually program each one? Nope. They made one model, then replicated it hundreds of times and modified the replicants with local environment variables to achieve the "flocking" effects. OO-animation!
OOP is great for (as mentioned) encapsulation. It can also make things easier for future developers on the same site and it makes for more reusable code so that future projects take less time.
On the other hand it provides no performance benefits of any kind and, in the majority of cases, will decrease the performance of your scripts by causing them to use both more memory and more CPU time.
Only mentioning this because it seems to be so often overlooked. OOP does not create "better" scripts. It's sole purpose is to make things easier for developers.
As someone mentioned, OOP started off in compiled languages meant for non internet applications where the app is running for single (or a handfull of) users and an entire sytem of resources to devote to them. In this kind of situation the performance degradation is irrelevant. In a multi-user web application it is not.
Now as per my learning experience
I think the basics which worked for me were:
Class (as a skeleton frame)
Function (0r actions!)can also be ref as "Method"
Properties or attributes (Which define further the class)
in the same time learn about instantiation (creating an object in the code)
and initialization (when assigning a value to a var)
here is a real life example used in my "templating" sys
<?php # HtmlTemplate2_group.class
// it reads a template, sets its values, proceed to the browser.
class HtmlTemplate2_group {
// Set the attributes.
var $template;
var $html;
var $parameters = array();
function HtmlTemplate2_group ($template) { /* names template to be used and introduce you to “$this-> */
$this->template = $template;
$this->html = implode ("", (file($this->template))); // Read the template into an array, then create a string.
}
function SetParameter ($variable, $value) { // This function sets the particular values.
$this->parameters[$variable] = $value;
}
function CreatePage () { // This function does the bulk of the work.
foreach ($this->parameters as $key => $value) { // Loop through all the parameters and set the variables to values.
$template_name = '<!--{' . $key . '}-->';
$this->html = str_replace ($template_name, $value, $this->html);
}
echo $this->html;
}
Now if I create a page
I’ll do that
Require ..... conn DB etc..
require_once ("../classes/HtmlTemplate2_group.class"); // Including the class.
$page = new HtmlTemplate2_group ("../templates/main_template_index.inc.php"); // there we create an instance.
$page->SetParameter("PAGE_TITLE", "Home Page");
$content .= '';
include "includes/business_name.inc.php";
$page->SetParameter("BUSINESS_NAME", $content);
And call a main template that hold the HTML (for ex main_template_index.inc.php
(it demonstrates well separation of php script and pure html/css/js and more..
</head>
<title><!--{PAGE_TITLE}--></title>
it seems like the Rosette stone however again the book I earlier recomended help me to teach myself about OOP
best learning: well you already know
crank your favorite coding tool
experiment pull your hairs
and comeback here
honestly without the board support I was very far away from this a few months ago - and still may and do hit a snag with very basic!
regards
Henry
I can't claim to be an OO expert yet but I'm a lot closer to being one than I was last week.
You'll be glad to hear that I didn't have to wear a dunce's cap or stand in the corner.
