Linked by John Collins on Wed 21st Apr 2004 06:42 UTC
The purpose of this article is to give a novice programmer the basic idea of what OOP is, as implemented using PHP. Readers should have a basic knowledge of programming ie what variables are, variable types, basic methods of writing comments, and how to enter code into a text editor.
Permalink for comment
To read all comments associated with this story, please click here.
Personally, in defense of object oriented programming, I have to say that it's made my life eaiser, in most cases (where it is appropriate to use).
It doesn't solve every problem every time one is presented, but such is any programming language or technology and...such is life.
It wouldn't be practical to sit down and say "I only know or like C++, so I want to write a web site in C++" and then continue to sit down and write a simple web site by using C++ (I know the example is farfetched but it's also a possibility). In this particular situation, you would use HTML and perhaps combine that with other web-centric technologies such as CSS, JavaScript, or on the server side Java, C#, and perhaps even some C++-based web services.
A few years ago I wrote quite a bit of code in ASP/COM and other web-centric Microsoft technologies.
In procedural ASP (using say, VBScript), I would tend to write a TON of the same type of code repeatedly and it grew quite difficult to maintain in larger projects. Even writing VB COM components posed a lot of problems with maintainence issues.
Now, for example, using ASP.NET and .NET assemblies to contain highly OO code, I've found my projects easier to envision, plan, test, build, and maintain.
Rather than grabbing a Recordset and repeatedly looping through it over and over and over to display data (spaghetti-coding it together with HTML) I can now create a clean, simple business object to represent my data, populate it with data using the appropriate design pattern, and display it on the client very easily with data-binding.
Should I want to do something particular to each record after it's bound, I can simply extract it with an event-handler
Product product = (Product)e.Item.DataItem;
product.Name
product.Price
...
...and then do whatever I like with it's methods and properties.
It's a beautiful thing, I'm a big OO proponent for most programming tasks!
However, it does not solve every problem and for small web sites, applications, etc. - procedural works just fine and in that sense, will never go away or be considered obsolete.
Personally, in defense of object oriented programming, I have to say that it's made my life eaiser, in most cases (where it is appropriate to use).
It doesn't solve every problem every time one is presented, but such is any programming language or technology and...such is life.
It wouldn't be practical to sit down and say "I only know or like C++, so I want to write a web site in C++" and then continue to sit down and write a simple web site by using C++ (I know the example is farfetched but it's also a possibility). In this particular situation, you would use HTML and perhaps combine that with other web-centric technologies such as CSS, JavaScript, or on the server side Java, C#, and perhaps even some C++-based web services.
A few years ago I wrote quite a bit of code in ASP/COM and other web-centric Microsoft technologies.
In procedural ASP (using say, VBScript), I would tend to write a TON of the same type of code repeatedly and it grew quite difficult to maintain in larger projects. Even writing VB COM components posed a lot of problems with maintainence issues.
Now, for example, using ASP.NET and .NET assemblies to contain highly OO code, I've found my projects easier to envision, plan, test, build, and maintain.
Rather than grabbing a Recordset and repeatedly looping through it over and over and over to display data (spaghetti-coding it together with HTML) I can now create a clean, simple business object to represent my data, populate it with data using the appropriate design pattern, and display it on the client very easily with data-binding.
Should I want to do something particular to each record after it's bound, I can simply extract it with an event-handler
Product product = (Product)e.Item.DataItem;
product.Name
product.Price
...
...and then do whatever I like with it's methods and properties.
It's a beautiful thing, I'm a big OO proponent for most programming tasks!
However, it does not solve every problem and for small web sites, applications, etc. - procedural works just fine and in that sense, will never go away or be considered obsolete.
Just my $0.02!