SitePoint Sponsor |
|
User Tag List
Results 126 to 150 of 190
-
May 22, 2006, 04:52 #126
- Join Date
- May 2005
- Posts
- 255
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by McGruff
- Templates themselves (a "templating" class is usually a good idea, but templates should be pretty much just plain text with some conditional logic thrown in).
- Entry points / boot strapping
- Maintenance scripts
The primary advantages of classes are:
- Modularity (irrelevant since in php you're dealing with individual files...everything is already highly modular)
- Encapsulation (depending on context can be important or not. Generally speaking, it's a lot easier to encapsulate data with classes than without, but php's file-scoped nature means that you have other options).
- Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)
- Aiding in self-documenting code (ppp methods are more about documentation than actually enforcing anything. Many languages don't actually enforce the constraints at run time, and are only checked at compile time).
That being said, using classes within php generally gives you some advantages, but they aren't the traditional variety:
- Using classes as "namespaces"
- Taking advantage of autoload / class_exists / method_exists / interfaces for some truly dynamic programming.
- Ability to override behavior of many engine internals using SPL.
And, of course, exceptions are tremendously useful, but there's no real reason why an exception has to have anything to do with objects.
Most of the traditional advantages afforded by classes are beneficial in the nasty world of strong, statically typed, compiled languages, but have little impact on the paradigm under which PHP shines.
Well, you can't deny that a code is definatly of better quality if it uses one class to handle let's say all the news functions instead of retyping all of the code everytime you need to do something with news.
The problem with java in this regard is that primitives aren't objects; if they were, all that functionality could simply be replaced with method calls to number objects, as they are in Ruby. So really, this is a case of the language not being OO enough.
Wrapping functions in a class is useful in PHP because there isn't a namespace, but wrapping the native functions that you're never likely to alter in a class just for the sake of being "more OOP" is a waste of your time. I can say with a fair degree of certainty that you're not going to be re-implementing functions like sqrt, pow, and other basic math routines any time soon.
There's nothing wrong with mixing procedural and OO code. Think about ordinary human language -- some times you say something with the noun first, then the verb, and other times you do the reverse.
dog.poop() makes sense, but
walk(dog) does too.
poop.dog() and dog.walk() aren't things I think anyone is interested in seeing.
yes you can program everything in procedural (but u can also do the same thing in assembly, (or even binary)) but it just gets rediculos!
OOP doesn't really make development go any faster or make it any easier to maintain. In many cases (such as C++, which is usually just more trouble than it's worth unless you stick to the basic features), it actually slows development down.
or if you have a fetish for brackets you can program in SCHEME, same thing the program will work but ittl be a waste of your time
write a multithreaded server and graphical browser in Java then write the same in procedural C and then youll see for yourself
except for php5 which as language is quite nice and fast but lacks thousands of packages and classes that make Java and .NET languages so usefull for programmers
You have missed the key feature of OO...
PHP Code:
$table = new WithCrossLinks(new TableDisplay(new DefaultAccount()));
$table = withCrossLinks(tableDisplay(getDefaultAccount());
doSomethingWith($table);
Changing the noun-verb relationship has very little real impact on project development.
OO vs procedural code usually boils down to...
PHP Code:$obj = new Object();
$obj->doFirstThing();
$obj->doSecondThing();
$obj->doOtherThingWith(new Thing());
PHP Code:$obj = Object();
doFirstThing($obj);
doSecondThing($obj);
doOtherThingWith($obj,Thing());
A lot of the OO stuff doesn't work so well in dynamically typed languages for other reasons; for example, most languages have all kinds of funky ways of creating containers. In php you pretty much always just use a map (what they call "array"). You never think about iterators or insertion operators or any of that. It's just not a problem that has to be solved.
The biggest failing of OOP is that it attempts to solve the problem of "large" systems, when in truth large systems should simply be avoided like the plague. You should break up large systems into small, modular, and INDEPENDENT chunks, ideally with each one operating in separate environments. For large scale systems, this is a must anyway, since scalability pretty much mandates that every component of the system operate on a separate piece of hardware. In this model, OOP vs procedural is meaningless.
Yes, as long as they address problems in PHP, not some other language
-
May 22, 2006, 06:25 #127
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
Originally Posted by Etnu
Originally Posted by Etnu
Originally Posted by Etnu
In the example, you gave (the second), there is a static coupling between the utilizing code and the function Thing(). In the first example (which uses OOP syntax), you could pass the object in, and thus decouple that relationship.
-
May 22, 2006, 07:17 #128
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
I agree with some of the things you've said but I also think that OOP is not just for large systems. Any non-trivial piece of code will benefit from OOP. You will find different roles - ie objects - if you hunt them down.
-
May 22, 2006, 08:04 #129
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I think it is easier to get design right with object oriented style. You have high level objects, which operate on lower level objects, which in turn operate on even lower level objects. You can spin this both ways, see?
The primary advantages of classes are:
- Modularity (irrelevant since in php you're dealing with individual files...everything is already highly modular)
I think you have better modularity (on a small scale) if you use functions because every function is essentially a module, "which separates cleanly". With OOP, an entire class is a module, and the functions depend on each other's effects, so a *class* is a module. I don't know if this makes a huge difference on this small level, but it could.
- Encapsulation (depending on context can be important or not. Generally speaking, it's a lot easier to encapsulate data with classes than without, but php's file-scoped nature means that you have other options).
- Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)
As you said, you can easily reuse the same function or class. I think that functions are more reusable, because you could be able to reuse one (or two) methods of a class for a new one. You can't do that (unless you inherit from the existing class, which is a problem if you want to inherit from another class too), but with functions, you can easily reuse one function for different things. I don't think there is much difference here if you have multiple inheritance or something like mix-ins, but PHP doesn't have these.
- Aiding in self-documenting code (ppp methods are more about documentation than actually enforcing anything. Many languages don't actually enforce the constraints at run time, and are only checked at compile time).
Code:# these functions work on #{kind-of-thing}
Example:
Code:function add_to_todo($todo_list, $item){}
And if we'd written it like this:
Code:function add_to_todo($item, $todo_list){}
If you use a class, that function would probably be in the TodoList class. If I'm uncertain about the order of arguments I want a function to have, I ask myself in which class I would put it if I were using OOP, and use that as the first argument ;-). So maybe some things are easier to get "right" if you use OOP.
Not really. You are assuming a procedural mind set, which of course will lead to similar code in the to syntaxes.
Code:(method object arg1 arg2 .. argn)
Code:$object->method($arg1, $arg2, .. $argn)
In the example, you gave (the second), there is a static coupling between the utilizing code and the function Thing(). In the first example (which uses OOP syntax), you could pass the object in, and thus decouple that relationship.
I agree with some of the things you've said but I also think that OOP is not just for large systems. Any non-trivial piece of code will benefit from OOP. You will find different roles - ie objects - if you hunt them down.
-
May 22, 2006, 09:13 #130
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Fenrir2
Aren't you the least bit worried about not being able to create your own data types? With the way you're going, you'll need to emulate them with in-built structures on the spot, and have to handle them using special functions instead of them being neatly wrapped and contained. I have a hard time imagining encapsulation in procedural form. That's just in my head, of course, but it might be an indication of which approach would be easier to handle.
Some pseudo:Code:def output(data): switch(true): case is_string(data): print data; break; case is_int(data): print i_to_s(data); break; case is_float(data): print f_to_s(data); break; case is_array(data): foreach key => value in data: output(key) print " => " output(value) print "\r\n" end break end end # vs. def output(data): print data.to_s end
Last edited by Ezku; May 22, 2006 at 10:26.
-
May 22, 2006, 10:33 #131
- Join Date
- Apr 2003
- Location
- Albany, NY
- Posts
- 417
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I'm just amazed that my little comment in another thread was the catalyst for such a great discussion.
Sean P Sullivan
Web Hosting::Web Templates::Free Smilies
Free Image Hosting::DIY Home Repair::DIY Gardening::Flash Games
-
May 22, 2006, 11:49 #132
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Really? Ever heard of, say, a Facade?
Aren't you the least bit worried about not being able to create your own data types? With the way you're going, you'll need to emulate them with in-built structures on the spot, and have to handle them using special functions instead of them being neatly wrapped and contained. I have a hard time imagining encapsulation in procedural form. That's just in my head, of course, but it might be an indication of which approach would be easier to handle.
The example code you give is ridiculous. The functional equivalent would be:
Code:def output(data) print to_s(data) end
The ability to dispatch on types has nothing to do with OOP:
Instead of doing:
Code:class Integer def to_s # do something end end class String def to_s self end end
Code:def to_s(Integer i) # do something end def to_s(String s) s end
-
May 22, 2006, 12:00 #133
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Fenrir2
-
May 22, 2006, 12:07 #134
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Of course, it's like defining a class. (but you'd have multiple dispatch).
Bah, I think I have to create my own language.
-
May 22, 2006, 13:26 #135
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Fenrir2
What I meant is that with OOP, an object should handle all operations on the object (encapsulation). Some operations could be low level, others will be high level. They all belong in the same class.
The ability to dispatch on types has nothing to do with OOPThe functional equivalent would be:Code:def output(data) print to_s(data) end
Code:def to_s(Integer i) # do something end def to_s(String s) s end
- the language of choice doesn't support defining the same function multiple times with different arguments (or overriding the function with an ability to call the overrided one from the inside, in effect creating a CoR), or
- to_s() receives something that on top looks like, say, an array, but you'd like it to be formatted differently - you can't differentiate your "types" from the base ones
Am I making sense?
(do you program in Ruby too? Your code is nearly correct Ruby code)
-
May 22, 2006, 14:03 #136
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Are you guys are talking about function overloading being somewhat analgous to two classes that share a common interface? (or even implement an Interface proper?)
-
May 22, 2006, 14:12 #137
- Join Date
- Jan 2005
- Location
- Ireland
- Posts
- 349
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by beetle
-
May 22, 2006, 21:59 #138
- Join Date
- May 2005
- Posts
- 255
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by McGruff
I agree with some of the things you've said but I also think that OOP is not just for large systems. Any non-trivial piece of code will benefit from OOP. You will find different roles - ie objects - if you hunt them down.
-
May 23, 2006, 04:03 #139
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
-
May 23, 2006, 06:08 #140
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
-
May 23, 2006, 06:51 #141
I have to echo the above sentiments - I'm not sure where you get the idea that polymorphism isn't useful in dynamic languages - polymorphism is just as useful in either static and dynamic languages even though implementation for one isn't neccesarily appropriate for the other (interfaces and typehinting in static languages vs duck typing in dynamic languages).
-
May 23, 2006, 07:20 #142
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Fenrir2
take a look at the multi class:
Code:multi(:foo, Integer) { |x| puts "integer #{x}" } multi(:foo, String) { |x| puts "string #{x}" } foo 10 foo "hello"
-
May 23, 2006, 08:19 #143
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I think that polymorphism is important, even in dynamically typed language (but maybe less important). For example, Ruby's method === is based on it, and because Ruby has polymorphism, functions like Enumerable#grep() (wich uses ===) can be made.
Quite nifty, isn't it?
-
May 23, 2006, 13:33 #144
- Join Date
- Mar 2004
- Location
- Grand Junction, CO
- Posts
- 292
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
Before I show any examples, I want to point out that Ruby is the only dynamic language I know. I imagine other dynamic languages support duck-typing as well, but I'm not positive.
In Java, you could have the following code:
Code:class Animal { public String talk() { return ""; } } class Dog extends Animal { public String talk() { return "woof"; } } class Cat extends Animal { public String talk() { return "meow"; } } // Some random method public void speak(Animal a) { System.out.println(a.talk()); } speak(new Dog()); # woof speak(new Cat()); # meow
In Ruby, there's no need to create a base class or an interface. You just make sure that the class supports the #talk method.
Code:class Dog def talk; "woof"; end end class Cat def talk; "meow"; end end def speak(a) puts a.talk end speak Dog.new # woof speak Cat.new # meow
-
May 23, 2006, 13:56 #145
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by pergesu
Originally Posted by pergesu
Off Topic:
Originally Posted by pergesu
-
May 23, 2006, 14:07 #146
- Join Date
- Mar 2004
- Location
- Grand Junction, CO
- Posts
- 292
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
So that leaves me wondering what Etnu was talking aboutI just took my best shot...and missed
Off Topic:
Does ruby code compile ? I thought it was interpreted ?
-
May 23, 2006, 14:11 #147
Originally Posted by pergesu
Your Ruby example above is actually a perfect illustration of polymorphism. How does ruby determine what code to run when your speak() function calls a.talk? It determines this based on the way your a object responds to the "talk" message. Dog's implementation differs from Cat's implementation, but the speak() function doesn't need to know or worry about that. As long as the parameter can respond to the "talk" message (in some way, even if it ends up using a missing method handler) everything is fine. This is polymorphism...
-
May 23, 2006, 15:09 #148
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi.
Enough point scoring already. What makes good code?
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
May 23, 2006, 15:30 #149
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
I suppose that we can keep enumerating technicalities, which are good practice, but doesn't ensure anything in and by itself. The real answer isn't a technical one though - it's the same as to "What makes a good novel". Good code has good litterary qualities.
As a programmer I often feel a bit misunderstood by my non-computer friends (I have a few left, yes). The general assumption is that programming is an engineering discipline - we all know the metaphore of 1's and 0's. Of course to some extend it is, but I have always felt that programming is much more of a linguistic discipline than a technical one. I failed math horribly in highschool, yet I make a good programmer (should I say it myself at least).
-
May 23, 2006, 15:33 #150
- Join Date
- Jan 2006
- Location
- Norway
- Posts
- 18
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Good code is like the perfect woman.
Hard to define, but it is love at first "site"
Bookmarks