SitePoint Sponsor |
|
User Tag List
Results 1 to 25 of 59
-
Jul 31, 2006, 11:24 #1
- Join Date
- Dec 2005
- Location
- Essex, UK
- Posts
- 241
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Advantages of Interfaces and Public Methods and Members
I'm pretty new to the OO side of things and have a few questions to ask.
1) What are the advantages of stating your members as public?
i.e. Which is better?
Code:class foo { var $bar; ..... }
Code:class foo { public $bar; ..... }
2) Similar to the previous question, what are the advantages of stating your methods as public?
At the moment I just leave any public methods without any declaration to their visibility. Is there anything wrong with this? Are there any advantages to stating their visibility?
3) What are the advantages of using interfaces?
As I said I'm fairly new to OOP and have looked a bit at interfaces. I don't see the point in them! Maybe I'm just not 'getting' interfaces but they seem very reduntant. If anyone has any good tutorials on Interfaces or reasons to use them I would appreciate it.
-
Jul 31, 2006, 11:55 #2
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
here's my take on it
- There's really no difference other than version compatibility. var is the PHP4 way, and public is the PHP5 way. So, if you're writing PHP5 and want PHP4 compatibility, use var. Note: In PHP5, if you don't explicitly state the visibility of a member, it's implicity public. All object members in PHP4 are public so this is irrelevant for PHP4.
- Same thing.
- Interfaces are like rules for developers. Functionally, I don't think there's any benefit. Since you can typehint in PHP5, and interfaces are treated like classes, you can write methods to expect a parameter object with certain interface without forcing the developer to extend one of your classes. Some of the SPL interfaces are good examples of this, such as Iterator.
-
Jul 31, 2006, 12:11 #3
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by stardustwd
At the moment I just leave any public methods without any declaration to their visibility. Is there anything wrong with this? Are there any advantages to stating their visibility?
What are the advantages of using interfaces?
PHP5 also has the SPL library, which provides you with means to override certain functionalities such as iterating over an object, accessing it as an array etc. by implementing a predefined interface. It's quite powerful, and I recommend you take use of it when appropriate.
-
Jul 31, 2006, 12:58 #4
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
(1) & (2) None that I can think of. I'll be annoyed with the extra clutter whenever I finally move on from php4. It feels like a step back to Victorian times when people were mortified if a lady showed her ankles but nowadays we wonder what all the fuss was about. You can have a well-defined interface without them (nobody is doing $foo->bar, right...?) and I can't think of a unit test which would fail because something is public which should be private (private parts are not normally manipulated in unit tests).
working on: Aperiplus, Rephactor, Phemto
useful links: xUnit test patterns, martinfowler.com, c2 wiki
-
Jul 31, 2006, 13:07 #5
In 5.2.0RC1, var is seemingly a psynonym for public and no longer raises a strict warning.
Code:>php -r "error_reporting(E_ALL | E_STRICT); class P { var $p; } echo phpversion();"
Code:5.2.0RC1
-
Jul 31, 2006, 13:10 #6
- Join Date
- Dec 2005
- Location
- Essex, UK
- Posts
- 241
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Thanks for the quick replies. I think I will start using global instead of var for my class members; didn't realise that var was deprecated.
As for methods, I'm still undecided. It seems as though it just creates a bit more clutter and is kind of unneccessary. Would like to hear other people's opinions on this though.
Ezku, beetle: I can only really see the benefits of interfaces as you stated when using things such as iterators. It's only me using at the code so most of the time I feel that interfaces are reduntant. Has anyone got any good tutorials on interfaces so that I can understand them a little bit better?
Thanks
-
Jul 31, 2006, 13:25 #7
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Well, regarding interfaces, consider the following.
PHP Code:<?php
class Config
{
public function isDev()
{
// example
return ( $_SERVER['DEV'] == 1 );
}
}
class DomainObject
{
protected $config;
public function __construct( Config $config )
{
$this->config = $config;
}
public function logError( $message )
{
if ( $this->config->isDev() )
{
echo 'Error! <br/>';
echo '<pre>';
print_r( $message );
echo '</pre>';
exit;
} else {
mail( 'admin@site.com', 'Error', $message );
header( "Location: /404.htm" );
exit;
}
}
}
?>
PHP Code:<?php
interface iConfig
{
public function isDev();
}
class Config implements iConfig
{
public function isDev()
{
// example
return ( $_SERVER['DEV'] == 1 );
}
}
class DomainObject
{
protected $config;
public function __construct( iConfig $config )
{
$this->config = $config;
}
public function logError( $message )
{
if ( $this->config->isDev() )
{
echo 'Error! <br/>';
echo '<pre>';
print_r( $message );
echo '</pre>';
exit;
} else {
mail( 'admin@site.com', 'Error', $message );
header( "Location: /404.htm" );
exit;
}
}
}
?>
P.S. This is just an example :P
-
Jul 31, 2006, 13:42 #8
Originally Posted by stardustwd
Below is not a tutorial, its a discussion but longer than this one is (so far) I really liked it and bookmarked it as the "barking dog interface" thread:
http://www.sitepoint.com/forums/showthread.php?t=353663Upgrading to Mysql 5? Auto-increment fields now strict
use NULL
Or zero or leave the field name out completely.
-
Jul 31, 2006, 13:47 #9
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by McGruff
For the sake of symmetry, I have begun writing out the redundant public, but I'm not sure it's really appropriate.
Originally Posted by stardustwd
Originally Posted by stardustwd
It's a bit academic, but I recently read this article, which among other things gives a good explanation of the role of interfaces vs. inheritance.
-
Jul 31, 2006, 16:36 #10
- Join Date
- Dec 2005
- Location
- Essex, UK
- Posts
- 241
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
Thanks beetle, i think i might be finally getting my head around this.
I've been thinking and I think it might be best to get a book on this. Can anyone recommend any decent OO books for PHP; I know the basics but I get a little lost on things like interfaces, abstract classes and the more advanced bits of it.
-
Jul 31, 2006, 17:23 #11
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Php Architect Guide to Design Patterns is worth getting hold of. Lot of material on unit testing as well as design patterns.
working on: Aperiplus, Rephactor, Phemto
useful links: xUnit test patterns, martinfowler.com, c2 wiki
-
Jul 31, 2006, 18:07 #12
- Join Date
- Nov 2003
- Location
- Los Angeles, CA
- Posts
- 460
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
here's another reason I exclusivley use php5 ....
I'm in charge of creating a "framework" of sorts that let other application developers plug into and use parts of our system. Being able to define protected and private variables allows me to have tighter code because I know some lazy app developer isn't going to try and use my members directly but actually have to use the public API call I provide them
cuts down on alot of bugs.My-Bic - Easiest AJAX/PHP Framework Around
Now Debug PHP scripts with Firebug!
-
Jul 31, 2006, 18:32 #13
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by jplush76
-
Aug 1, 2006, 09:09 #14
Think of public and private as a way to create a blackbox from your classes.
Not much needed, unless you share them with other people
-
Aug 2, 2006, 02:44 #15
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by beetle
Let me rewrite the above paragraph for the situation where you don't use the interface:
This means ANY object can be passed in, so we're no longer forcing the user (code) to extend the Config class. Try to call isDev() method, and PHP will trigger a fatal error.
That's called duck typing, and is much more appropriate for a dynamic language. Interfaces have their value, as documentation.
-
Aug 2, 2006, 06:00 #16
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
I don't ask that to be frictional, I really mean it. I'd rather make sure the user (coder) passed in an object with the correct interface than likely have an error anywhere else past that. Or, god forbid, they incidentally pass in an object that shares a method name but does something completely different.
If an object was coded to an interface, it's much more likely the developer designed it as you intended. Documentation, indeed, but that's not all their good for IMO.
-
Aug 2, 2006, 11:23 #17
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
> Interfaces have their value, as documentation.
Interfaces have other uses, and more to the point (the point that you so elegantly forget) have their purposes, and value, regardless of the language.
> If an object was coded to an interface, it's much more likely the developer designed
> it as you intended.
That is how I see it; If I've spent a number of hours over a period of time designing an Interface(s) then that is how I would want the script to be implemented, not only by myself, but other developers that I employ and use my code base.
Beris., if you have such as issue with PHP5, then go back to PHP4 where you won't have to face the use of Interfaces
-
Aug 3, 2006, 01:04 #18
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
1. Static-typing (and interfaces as its spawn): In static languages like Java, interfaces are a way to make variables "dynamic", i.e. to be able to put completely unrelated objects (in the sense of inheritance) to a same variable; in dynamic languages that need doesn't exist. I mean, interfaces always exist, simply as a collection of an object's public members, and if an object doesn't comply with the interface you need it will show up as soon as you try using it.
2. Confusion of classes and objects: as I mentioned in another thread, the whole private/protected/public (and package in Java) mess came up because of confusion between classes and objects. Visibility of a property should not affect its extendability, and especially the idea that a private (or any for that matter) property cannot be inherited is an utter nonsense. The OO principles call for a) all properties must be inherited, as they define a type, and b) properties should be either private, which means that only their own instance can access them, and public, which means that any other instance of any class can access them (of course, private should be the default and public should be explicitely announced).
-
Aug 3, 2006, 01:10 #19
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by beetle
In programming, more freedom is always better than more restrictions. Of course, we have all met bad programmers, but in the long run it much more pays off to educate (or fire if all else fails) bad developers than restrict everyone.
-
Aug 3, 2006, 01:45 #20
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I suppose the reasoning is that it prevents action at a distance, since the program would fail early. I agree with you about dynamic languages vs. interfaces. I think a sort of weak interfaces would be much more useful.
-
Aug 3, 2006, 07:36 #21
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
For example, tak using the SPL Iterator interface. You can't go in and change the methods names of a class that implements it from Object::current() to say... Object::currentElement() and still use Object in a foreach() loop.
For the point I'm arguing, interfaces are a guide to achieveing the desired result by the programmer. I want x-object to work in a foreach() loop, so I implement Iterator. If ProgrammerB wants an object to behave in a system designed by ProgrammerA, ProgrammerB will implement InterfaceX because that's how ProgrammerA set it up.
Back to your counterpoint. Yes, freedom is programming is good. But when working with something as part of a system, restrictions can be necessary. Unless you think you should have so much freedom that you could change Object::current() to Object::someThingElse() and still get the desired result.
-
Aug 3, 2006, 08:31 #22
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by beetle
You need to understand the difference with interfaces (as in collections of public members of an object) and Interfaces (as in formal language entity). The first is something that exists whether we want it or not; that's just a property of OOP. The latter, OTOH, are unnecesary and misleading in dynamic language like PHP.
If you use an object, of course you'll need to know its interface and of course you wouldn't want it to suddenly change.
-
Aug 3, 2006, 09:48 #23
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
But hey, I don't have any context to discuss the dynamic nature of PHP and Interfaces with you - aside from knowing javascript, I fiddle with Ruby and have a layman's knowledge of C++. I openly admit that's the breadth of my experience (ok, I took TurboPascal in high school and BASIC in grade school :P).
Perhaps you could help me understand why interfaces (proper) are, to use your word, "misleading" in a dynamic language? Because, as the framework developer for a team of four, I find them rather useful.
-
Aug 3, 2006, 10:40 #24
In a truly dynamic language, you can add, remove and rename methods at will, which renders Interfaces completely useless. In a truly dynamic language, it doesn't matter what type an object is, the only thing that matters is, does it contain a given method?
Now, I wouldn't use the word "misleading" to describe them, but they are definitely unneccesary.
-
Aug 4, 2006, 01:29 #25
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by beetle
Watch out for those multiple negations.
Originally Posted by beetle
Originally Posted by beetle
PHP5 has introduced some great dynamic OOP features such as overloading methods (__set, __get, __call...), but at the same time has introduced the static features like interfaces and type hinting. Specifically, type hinting in itself isn't of much value without interfaces (which is why the latter were introduced in, say, Java), which means that the two make sense only if they're used together (which is of course not needed).
Specifically, the issue here is not that much with the interfaces in PHP than in type hinting. It introduces a whole new set of rules into programming practice here. Someone said that if you wanted the users of your class to use it as you intended, you'll design an interface they must abide with. But what if you made a mistake, or if you simply didn't consider all the facts?
Imagine that you write a Fish interface that has several propertires, including a swimDeep() method. But later you want to expand your aquarium simulation application to support both tiny human divers and tiny submarines, that have the swimDeep() but none of the other properties of Fish.
So if you implement that interface by both submarines and divers, you'll also have to implement a bunch of methods they shouldn't have (breatheWater(), hatchEggs() etc). The alternative is to create a new interface, Swimmer, and give it just the swimDeep() method (and perhaps any others that might be appropriate, such as surface()); but now you not only have to change your old classes to implement two interfaces, but also change all type hints from Fish to Swimmer. (Of course, you could also use some kind of Decorator pattern, but that's a whole 'nother issue.)
In static languages this is pretty normal and there are tools that assist you in that kind of refactoring; but dynamic languages have a much simpler way of dealing with that. This specific issue is easily resolved by duck typing, and if an object doesn't have a required method, and error is thrown; as simple as that.
Bookmarks