Monthly Archives: August 2013

PHP Interfaces — Why Use Them?

In PHP, an interface is nothing more than the ‘skeleton’ of a class.  You can’t put any non-public code into it, you can’t add properties, or otherwise add functionality.  It doesn’t in any way help with the normal approach to abstraction, wherein lower level classes handle details so the higher level ones can focus on other things.  In many ways, it seems an absolutely pointless idea.

In and of itself, you could make that argument.  Interfaces don’t ‘do’ anything on their own other than add restrictions to your code.  If you implement an interface, you’re required to add all the required methods — even if you don’t think some of them are needed or make any sense.

The real ‘power’ of an interface isn’t in helping to re-use code, it’s in the fact that it’s a ‘contract’ that your classes are obliged to fulfill.  Yes, it requires more work, but it’s work that’s designed to help the programmers.  As my immediately previous post about Objective-C points out, with more powerful compilers and computers, we have the option of backing away from having to work and think like a machine would.  Instead, we can focus on things that machines can’t do — like create logic that is suitable to a task.  Interfaces are a language level tool to help us do that.  They provide the framework that tells us we need to complete a given set of methods, which allows auto complete to fill in calls to those methods even before we finish writing them.  They actually improve code-reuse by allowing us to focus on a specific set of code, while leaving other details to the implimentor.  A plugin can simply say ‘give me a class that fulfills this interface’ and proceed on using it, not knowing or caring how you fulfill your responsibilities — be they saving data (to a disk, a database, or remote server), or actually sending the text message you just created.

In a sense, Interfaces allow you to invert the normal inheritance approach towards abstraction, defining lower level tasks without worrying about big picture items.  Your interface lets you say ‘OK, I’ve done this work for you.  Now, I need you to save this file to disk to retrieve later’.

In some cases, this could be done through the use of abstract classes.  That’s also a very valid approach.  But the use of abstract classes enforced a hierarchical decision, whereas interfaces allow for ‘sibling’ classes that don’t interact at all, except via the interface.  It’s a tool, no more and no less.  Use it as appropriate, don’t use it when another tool fits better.

Adapt Languages to People, Not People To Languages

I recently read an blog post on how to make binary branches in a function definition more readable.  In and of itself this is a laudable goal, but frankly I think it’s completely backwards.

Instead of trying to find ways to use a given programming language in a more readable manner, focus instead on developing a new paradigm for programming syntax. The majority of languages are so similar that the syntactical differences are largely a matter of learning the appropriate keywords and to use a period in place of an arrow (the -> you see in C++ for example).  Python is more or less identical to C++, just with a slightly different way of expressing the exact same concepts, and a different way of typing out various STL features. The implementation is different, but the underlying logic behind the syntax remains the same.

Objective-C is my preferred language whenever possible because the developers actually took the time to consider how humans think, and then programmed the language to work more naturally with us. Instead of changing your code to make it easier to read, the changed the language.

The only real ‘downside’ to their approach is that it isn’t just object-oriented, it actually requires that you use objects if you want to gain the benefits of the language. And, to me, this is *not* a downside. OOP has proven itself a superior paradigm for most programming efforts, so enforcing it’s use just makes sense, even if it does require a degree of ‘magic’ to get started with.

I don’t care how you try to pretty it up; runSomeLogic(account, person, TRUE, FALSE); is always going to be harder to read than [account runSomeLogicWithPerson:person usingCache:YES withSecurity:no]; It’s just… human nature. The self-documenting function of the Objective-C method name is a huge mnemonic aid, and the only downside to it is the extra typing required. And that downside is easily solved by the incredibly helpful feature commonly reffered to as ‘intelisense': the ability of an IDE to guess what you’re trying to type, and help you finish it. That feature may be a ‘crutch’, but it’s a crutch that is far more helpful than harmful. In my experience, maybe one time in ten the reason intelisense can’t finish for me is because I made a mistake typing out a function or variable name (and almost invariably it’s because the function or variable name isn’t following standard conventions). The other nine times, I either had an error elsewhere in my code that was causing intelisense to be confused, or I had a data-type mis-match.

In the end, I’ll choose Objective-C over other languages precisely because, whether it’s wordy or not, it’s easier to read and understand.  The hard work of programming isn’t typing, it’s understanding what to write and then fixing the mistakes you’ve made.  Anything that helps in those two goals, even if it requires extra typing, is a huge aid.