Where to place utility functions in the OO application

[OfficeOfTheLaw]

Er... Making the class to conform is useless.

Or, to make it a bit more precise: making the variable to conform is useless, or rather pointless. A class should do whatever is it's responsibility.

I'm sure I'll just get another canned "LA LA LA LA LA I can't hear you!" response, but oh well.

First, let me beat you over the head with the word encspulation. Your object variables should never be exposed... that's just bad practice. There's more than enough literature out there that illustrates why... most importantly, these are difficult to mock out if you're unit testing.

The second thing, it is important that a class conform to an interface if it uses it. Say, for example, I want to have a DataSource interface that describes a common way to access a generic datasource (say, getValue, setValue, etc). Now, I can have classes implement this interface that have their own special methods to do different things. One class can use a database as it's datasource. Another could use XML as a datasource (I bet you're howling now), one could use CSV, another could even use SOAP. Thanks to the contract in place by the interface, classes using the data source do not need to concearn themselves at all over what the data source is... you can happily swap out a DBDataSource and use an XMLDataSource with no problem... because the methods the other object uses to access that data source are present... thanks to the contract.

Now at this time I bet you'll say "well, that's the developers job not to be so retarded to leave those methods out!". Well, what if someone else needs to write a datasource? Let's say they want to use an existing one from something else that doesn't implement the interface? No problem. Just subclass the existing datasource class (or even write an adapter), have it implement the interface, and add the methods in and define yourself how it should access the datasource in a way that any class using the abstract datasource would expect. No worries about "Call to undefined method" errors, no worries about a data source asking for more than it should.

Dependency Injection is a concept that relies quite a bit on interfaces, so making blantant statements like "Making a class conform is useless", while perhaps valid in your case, is rather preposterous.

@Dr Livingston: I'm not sure what you mean under "Interfaces", probably the Java incarnation. The primary purpose of interfaces in java is to get your program compiled. If you don't compile, why do you need them?

Only if you're programming by coincidence. I'm reminded of the class on thedailywtf.com that had a variable namned PleaseCompile = true Amongst other programmers, it's good practice to refer to user interfaces as... well, user interfaces. This is the only other interface I can think of besides actual interfaces, which are used in dozens of languages, including php5.

[BerislavLopac]

I'm sure I'll just get another canned "LA LA LA LA LA I can't hear you!" response, but oh well.

I hear you very well. And your points are all perfectly valid.

But have nothing to do with the issue at hand.

First, let me beat you over the head with the word encspulation. Your object variables should never be exposed... that's just bad practice. There's more than enough literature out there that illustrates why... most importantly, these are difficult to mock out if you're unit testing.

Misunderstanding is one thing, but this is plain offensive. I nowhere mentioned "object variables", and I never would -- I call them "attributes".

The second thing, it is important that a class conform to an interface if it uses it.

I'm not sure if you wrote what you meant to say... An interface has nothing to do with it being used by the class that implements it. Interface (lowercase) is meant for other objects to peruse.

Say, for example, I want to have a DataSource interface that describes a common way to access a generic datasource (say, getValue, setValue, etc). Now, I can have classes implement this interface that have their own special methods to do different things. One class can use a database as it's datasource. Another could use XML as a datasource (I bet you're howling now), one could use CSV, another could even use SOAP. Thanks to the contract in place by the interface, classes using the data source do not need to concearn themselves at all over what the data source is... you can happily swap out a DBDataSource and use an XMLDataSource with no problem... because the methods the other object uses to access that data source are present... thanks to the contract.

All perfectly correct and valid. What you're saying is that classes with common behaviour should implement a same interface (lowercase), and I heartily agree. All I'm saying is that in dynamically typed languages, such as PHP (or Python, or Ruby, or Javascript), you don't need to use (and in fact can be harmed by using) the formal Interfaces (capital).

Now at this time I bet you'll say "well, that's the developers job not to be so retarded to leave those methods out!". Well, what if someone else needs to write a datasource? Let's say they want to use an existing one from something else that doesn't implement the interface? No problem. Just subclass the existing datasource class (or even write an adapter), have it implement the interface, and add the methods in and define yourself how it should access the datasource in a way that any class using the abstract datasource would expect. No worries about "Call to undefined method" errors, no worries about a data source asking for more than it should.

This is where you're starting to shoot way off the mark.

If someone else needs to write a datasource, how will they know what methods to implement, i.e. what is a datasource interface (lowercase)? They'll look at the documentation. In dynamic languages, interfaces are just formalized documentation, nothing else.

In static languages, you need interfaces if you want to a) avoid multiple inheritance while still b) being able to have an object that is of several types at the same time. Interface (capital) makes it possible for your variables to be of several types at the same time -- which makes them dynamic to an extent.

As for the "undefined method" errors: how are they a problem? When you use an Interface (capital), you implement all the methods it requires just in order to avoid an error, even if they will never be called on the class in question. YAGNI!

Dependency Injection is a concept that relies quite a bit on interfaces, so making blantant statements like "Making a class conform is useless", while perhaps valid in your case, is rather preposterous.

I now realize that what I wrote was mistaken. What I intended, and should have written, is this: in a dynamically-typed language, forcing a class to conform to an Interface (capital) is pointless.

Only if you're programming by coincidence. I'm reminded of the class on thedailywtf.com that had a variable namned PleaseCompile = true Amongst other programmers, it's good practice to refer to user interfaces as... well, user interfaces. This is the only other interface I can think of besides actual interfaces, which are used in dozens of languages, including php5.

The important point here is to ask yourself: how many dynamically-typed languages, besides PHP5, do you know that implement Interfaces (capital)?

The problem with this whole debate is that the really important things have become muddled by the keywords and actual implementations. Interfaces (capital) are not really the issue here -- it's the concept of type.

In OOP, an object's type is defined by its behavior, which means what it can be asked to do, which means the collection of its public methods, which means its interface (lowercase). This is the concept, and everything else is practical implementation which will naturally differ in different languages.

PHP has since its beginnings been a dynamically-typed language par excellance, and it is exactly one of its benefits which made it so popular as it is today. It has for a long time been lacking proper OO support, and when it finally got it, Java was taken as the primary model to base that support upon.

I can only guess why it was decided to be the way to go, but Java has a number of problems both as an OOP implementation and as a language in general, but it is not really a big deal, especially if it allowed us to keep backward compatibility to the extent that it did.

However, the adoption of Java-like concepts went somewhat too far, and we got fed type hinting and Interfaces (capital), neither of which really have a place in a dynamically-typed language.

In a statically typed language, where you must have a type associated with a variable, it makes sense to go "tell me if you're a duck so I can ask you to quack"; in dynamically typed languages, you don't give a damn about what type is a variable; you just go: "You! Quack!".

Luckily, we are not forced to use type hinting or Interfaces (capital) in PHP5. On the other hand, we can use them if we don't know better, which is OK in some ways, as it enables people with Java background to use PHP.

That being said, I rather prefer a language that forces you to be a better programer over a language that allows you to be a lousy programmer. Which is way I don't like Java.

[OfficeOfTheLaw]

My bad... miscommunication.

I find type hinting useful in instances where I have methods that require an object of a certain type, a lot better that testing to see if is an object and of a specific class. The good thing is this is optional and doesn't have to be used if you don't want it.

[33degrees]

Surprisingly that is one part that I didn't actually mind about; In fact it helped me to keep focus to a certain degree, and in fact is one feature that I was looking forward to seeing in PHP5; Unfortunately it wasn't to be, but who knows... PHP6?

Well, clearly then static typing has some appeal to you, which probably explains why you like using Interfaces as well. To me, having types and casts everywhere is noise that detracts from focusing on what the code is really trying to do.

Take, for example, a CommandDispatcher. With a command dispatcher, one can add multiple Commands with some kind of key or state that indicates when the command should be executed, and when the command dispatcher is ran with that state or key, it finds the appropriate Command and calls it. Now, with an interface that says all Command objects must implement an execute method that accepts certain arguements, you can easily ensure that anyone who write a command for that particular command dispatcher can just glance at the interface and know to implement the method. You don't have to worry about them programming by coincidence, and if they don't implement the interface in their command object, you can reject adding the command object to the dispatcher.

Why not just use an abstract class for this?

[BerislavLopac]

My bad... miscommunication.

No problem.

I find type hinting useful in instances where I have methods that require an object of a certain type, a lot better that testing to see if is an object and of a specific class.

This exact sentence is what should tip you off to my point: your method require an object of a certain type.

Type != class, although in practice thea are usually equivalent. As I said previously, a "type" is defined by its behavior, or rather responsibility: to be of a certain type, an object has to know certain things (i.e. have certain attributes) and to be able to do certain things (i.e. have certain methods) -- in other words, to have a certain public Interface (capital). And some objects may have multiple types.

In static languages, you must specify a class literally; in some, that was replaced by the ability to instead specify a type (i.e. an Interface), but you still have to specify something. In dynamic languages, you don't care of the actual type -- all you need to know whether an object can to do something. Or as an example: when your object enters the water, your program doesn't care whether it's of Fish, Duck, Dolphin, IanThorpe or Submarine class -- all that is important is that it has implemented the method swim(). Even if its implementation goes like this:

public function swim()
{
    $this->drown();
} 

[stereofrog]

Only if you're programming by coincidence. I'm reminded of the class on thedailywtf.com that had a variable namned PleaseCompile = true Amongst other programmers, it's good practice to refer to user interfaces as... well, user interfaces. This is the only other interface I can think of besides actual interfaces, which are used in dozens of languages, including php5.

"Amongst other programmers" it's also common to define terms they're talking about.

Let's define "interface". Is it

a) forced separation of interface and implementation like in C, Objective-C, Modula etc

b) Java language keyword.

Advanced question:

why (a) is a Good Thing and why (b) sucks