>(But if you see them, why did you choose for PHP anyway?
Doesn't J2EE seem more appropriate?)
Certainly not! Java's strong typing in combination with it's primitive
datatypes is a pain in the ass. So is it's obligation to either handle
exceptions or declare to be throwing them. It is allso a matter of
mentality: Java's developers tend to make everything unnecessary
complicated. For example this absurd idea of EJB (Enterprise Java Beans, a
part of J2EE) that everything is distributed. This means that looping
through a thousend objects and retrieving a value form each will require a
thousend remote method invocations (these are at least a hundred times
slower then local method calls, but if these objects happen to reside on the
other end of the world each method call takes half a second or more). (in
the end they had te reintroduce
local objects kind of through a back door).
The more generic (= reusable) your code gets, the more you
run into the inflexibilities and bad designs of Java. I'm not alone here,
look at the Lightwieght Languages workshop (
http://ll1.ai.mit.edu/) and its
discussion archive
(
http://www.ai.mit.edu/~gregs/ll1-dis...l/threads.html - takes
a few minutes to download)
But let's talk about the advantages of OO. It comes down to:
- delegation + polymorphism
- encapsulation
- inheritance
Delegation means that you want something done but you do not do it yourself
but have an object do it for you. This is done by using a service, wich is
dispatched tp a function on an object. Now what is the difference between
calling a normal function and using a service? Polymorphism! The class of
which the object is intstantiated is decisive for which function is actually
executed. For example if i am building an ecommerce website i could have a
class "DeliveryServic e" with a subclass "ExpessDelivery " and another
subclass "Standard Delivery". Somehwere in the order intake i ask the
customer to select a delivery service. On the basis of his selection i
instantiate the corresponding class and tell the object te delivery adress.
Then i can ask the object for the dilivery price and maybe how long the
delivery will take. If the object is an instance of ExpessDelivery it will
ececute the functions of ExpessDelivery to calculate the price, which will
probably be higher then for a StandardDeliver y.
So far you could reach the same result with some case swithches in normal
functions. But here comes the trick: When the owner of the ecommerce website
asks me to add another delivery service, let's say "Collect On Delivery",
where his customer can pay on delivery to the guy that delivers the order, i
can simply add another class CollectOnDelive ry and implement it's functions.
With case swithches i would have to add a case to each case switch. In order
to do that i would first have to find all these case switches hidden in
whatever function where i have (or worse, someone else has) once written
them. This makes well-designed OO software more flexible and easier to
maintain.
You can see it like this: in OOP we put our functions into a large
multilayered
case switch, called the class hierarchy, while in conventional
programming you have to replicate many case switches throughout you code.
So, if you have little case switches (including if-elseif-etc) you will
probably not
need OOP. If your case switches are becoming a headache you should obviously
have used OO right from the start.
OK, this is more then enough, i suggest someone else explains encapsualtion
and
inheritance and their advantages.
Greetings,
Henk Verhoeven,
www.metaclass.nl 
