Persistent Learning

Static Methods versus Object Instantiation

2009-05-19T14:04:00.004-04:00

One of the arguments I have been having in my team lately is whether our models should be a set of static methods or an object that is instantiated with public methods. My background is such that I tend to lean towards object instantiation in 95% of the objects I develop. In addition, many of the objects with all static methods are simply a method for namespacing global functions. Using objects this way is 100% against my understanding of object oriented development.

Wikipedia (Objects) definitionIn computer science, an object commonly means a data structure consisting of data fields and procedures (methods) that can manipulate those fields.

Therefore a class of methods that behaves like a toolbox is simply not object oriented development. With that said, I read a good article yesterday while searching for more information about the two sides of the arguments that basically stated that unless the object has a persistent state beyond a single method invocation it might be worthwhile to consider making it public static. Reading this simply, if the object has no properties then it is a candidate to be a set of static methods.

In regards to Models, the problem I have with this is that I strongly believe that the database adapter should be decoupled from the Model itself. If all methods of a Model are static then this means the database adapter would be a required parameter for each method. This added complexity is unnecessary. In my opinion the database adapter should be a required parameter for instantiating a Model. After all, a Model is designed to interact with a data store so providing the adapter to do so makes a lot of sense. This decouples it and reduces the complexity in the parameters for each method the model implements.

This is synonymous of my approach to development in general in that I prefer to divide responsibilities into smaller, simpler methods. This facilitates easier and more complete unit testing in that smaller, simpler methods do not have many paths to traverse therefore testing every path is clear and straightforward. In addition, this approach reduces complexity of the code which is a common practice for improving flexibility and maintainability of code. If a method is not complex it is easier to understand what it is accomplishing as well as to refactor or add functionality.

This discussion has made me rethink other objects of our stack though. I realize that I have under utilized classes that have static methods. I still do not agree that methods should be simply made static and put in a class together if they do not actually represent an object. But I do see greater utility in static methods in general and will implement them more frequently.

Eclipse, PDT, and occurrences or annotations

2009-04-13T20:42:00.002-04:00

One of the features I really liked in the old PHPEclipse for Eclipse was the marking of occurrences or annotations(occurrences going forward). This functionality allows a developer to single click on a variable name and all occurrences of that variable (with the same name) are highlighted and marked in the right side occurrences bar. This can be very useful when working with legacy code or when you have a controller that is becoming rather complex. For those averse to using the mouse, moving the cursor to any position in the middle or beginning/end of a variable will act as if the variable were single clicked.

Recently I reinstalled Eclipse to remove the plugin developer environment(PDE) and suddenly the occurrences were not being marked in my PHP code. I was distraught because anyone who works in eclipse knows that all settings are stored in your workspace and not in the program directory so this setting should not have changed. Had some of my settings been wiped? Luckily after visiting PDT's home I found a ticket reference and some documentation around the fix for this behavior. By going into my preferences a la Windows->Preferences->PHP->Editor->Mark Occurrences I was able to re-enable this behavior and avert certain disaster! :P I don't ever recall explicitly setting this feature prior to the reinstall so maybe some oddity caused it to work prior to the re-install. Either way I must say that I still love Eclipse very much! <3

Using PHPUnit's dataProvider for comprehensive failure testing

2009-01-29T11:10:00.007-05:00

Writing tests to make sure your application handles failure conditions appropriately is one of the more difficult things to do. It's much easier to write a unit test case to make sure a function or method works when correct parameters are passed. PHPUnit provides some features that will enable you to easily write robust tests to test those failure conditions. Today I'm going to talk about using PHPUnit's dataProvider functionality.

Suppose you had the following static method:

class Example
{

    /**
     * An example method
     *
     * @param   array  $data
     * @return  void
     */
    public static function one($data)
    {

        if (!is_array($data)) {
            throw new Exception('Array expected');
        }

        if (!array_key_exists('one', $data)) {
            throw new Exception('Key (one) is required');
        }

        if (!array_key_exists('two', $data)) {
            throw new Exception('Key (two) is required');
        }

        $data['one'] = true;
        $data['two'] = false;
        return $data;
    }
}

Let's use PHPUnit's dataProvider to test all the failure conditions of the method Example::one(). Data providers must return an array of arrays representing the parameter set of the test method. In this case we are going to have a test method that accepts 3 parameters; a data set, an exception type, and an exception message.

class ExampleTest extends PHPUnit_Framework_TestCase
{
    /**
     * Test failure
     *
     * @test
     * @dataProvider failureDataProvider
     * @return  void
     */
    public function failure($data, $exception, $message)
    {
        $this->setExpectedException($exception, $message);
        Example::one($data);
    }
}

As you will notice, the PHPDoc of the test method defines the data provider method name using the '@dataProvider' tag. Let's define the data provider.

    /**
     * Failure Data Provider
     * @return  array
     */
    public function failureDataProvider()
    {
        return array(
            array('', 'Exception', 'Array expected'),
            array(false, 'Exception', 'Array expected'),
            array('foo', 'Exception', 'Array expected'),
            array(new Example(), 'Exception', 'Array expected'),
            array(array(), 'Exception', 'Key (one) is required'),
            array(array('somekey' => 'somevalue'), 'Exception', 'Key (one) is required'),
            array(array('one' => 'somevalue'), 'Exception', 'Key (two) is required'),
        );
    }

In this data provider we test all the possible failure conditions for the method Example::one(). Using a data provider keeps your tests clear and concise and enables the addition of additional test parameters with ease. All you need to do is simply add another array to test a new value. Let's see the result of our test.

# phpunit --verbose ExampleTest.php
PHPUnit 3.3.9 by Sebastian Bergmann.

ExampleTest
 ExampleTest::failure
 .......

Time: 0 seconds

OK (7 tests, 14 assertions)

The data provider functionality makes it easy to test large combinations of parameters for any method. Read more about the data provider functionality in the PHPUnit documentation.

Coding Efficiency or Maintenance Nightmare: using full descriptive naming in development

2009-01-26T13:11:00.009-05:00

As a developer who prides myself in the less popular things such as documentation and standardized code I find it frustrating when I read code that has been "shortened" or "abbreviated" in the name of efficiency. A common theme I am struggling with these days is developers who choose to abbreviate their code for reasons such as "its easier to type" or "it fits better on the screen". As an example, I am frequently seeing the use of a variable name of 'q' instead of 'query' or 'u' instead of 'username'. Don't get me wrong, I am all for efficiencies. But when maintaining this code I find it is much more difficult to understand in order to improve or fix when these abbreviations have been used throughout the code. Imagine a method that finds data in several databases and the variables in scope are 'q', 'u', 'p', 'r', 'd'. Thats a headscratcher if any complexity is involved in the method.

Adding to the frustration is the argument that involves simple editors as a valid reason for this approach. I love 'vi' but for development a good IDE is second to none. Using context assist in eclipse can reduce your overall keystrokes when you need to type out 'username' instead of 'u' and can prevent you from typos. Yes, I see tons of typos in code developed by developers using 'vi'(probably an exception to the rule, but I have my doubts). Using a simple editor is not an excuse.

Is it really too much to ask to type out 'query' instead of 'q'? Descriptive naming in classes, methods, and variables/properties can result in less protracted maintenance over the life of a piece of code. I personally found it difficult when I first decided to be more descriptive in my syntax. However, in a short amount of time you will find it becomes much easier to find appropriate and descriptive names and your code will improve. In the end, you owe it to your fellow developers to do everything in your power to make everyone's life easier through more descriptive syntax.

Code Templates in Eclipse

2008-01-08T16:16:00.000-05:00

Today I read an interesting blog(Developing at the speed of thought) which discussed how little time developers should be coding versus the amount of time they should be designing and thinking about how to code something. I find that the stronger I get as a developer the more time I spend thinking about the design of a process. Its an interesting though considering that when I started developing I used to write code, lots of it, and then turn around and remove quite a bit during refactoring. More often than not these days I find that the majority of code I write needs very little refactoring or altering whatsoever. Several things have caused this change in my abilities. Two that come immediately to mind are coding standards and code templates. The first of which should be self explanatory and the second is partially about using the power of an IDE. I use Eclipse for almost all of my development and therefore I use their code templates quite often. I also have setup quite a few of my own templates and that is what I am going to talk about today.

Code templates in Eclipse are defined in the Eclipse parameters. The templates are per language and it is generally found under the language's editor section in the preferences. I am going to show you a few PHP code templates using PDT. To follow these steps you would need to open your preferences in Eclipse and expand PHP and then click on Templates. This will open the Templates section and allow you to preview, create, edit, or remove templates. As you will see PDT ships with some helpful code templates for most conditional statements and control structures, as well as function and class definitions. When viewing the templates screen the name is what you would type to trigger the template and the context is when it is available to be triggered. Most of the PDT templates will have a context of PHP or HTML therefore you don't have to worry about these template conflicting when you are editing a Java source file or SQL file, for example.

I work with Zend Framework and there are many calls that I have setup code templates for. One of the more frequently used templates that I use is for Zend_Debug::dump(). So let's create a template for this now. Click New and this will open the Edit Template dialog box. Again, the name is the text that you will type to trigger the template. Let's name this template 'dump'. The description will be something like 'Zend Debug dump method call' and its sole purpose is to be descriptive text for identification. The pattern is where you define the actual template and in this case let's enter the pattern like this:

Zend_Debug::dump($$${variable});${cursor}

You might notice the numerous dollars signs in use, Ill come back to that in a minute. First let me tell you that templates can have pattern variables which allow you to autopopulate values such as an array variable, a class name, a variable name, or date and time. Pattern variables are defined by the syntax ${variablename} in the pattern. You are not constrained to the pattern variables found in the insert variable dialog box, you can define your own variable names but they may or may not resolve to anything when you trigger the template. The important thing to note is that when the template is applied to your code you will be able to tab from the first pattern variable to the last and edit it to be whatever you want. Yes, shift tab will take you back from the last to the first as well. Lastly, the double dollar sign resolves to a single dollar sign when the template is applied.

Once you have entered this in the pattern field click ok and then apply in the preferences window. Then go into a php source file and type 'dump' and then click cntl+space to trigger the template to see how it all works. When this template is applied you will receive a selectable list of recently used variable names that are in scope. This is triggered by the pattern variable ${variable}. When you hit the tab key it will take you to the position of the cursor pattern variable where you can quickly hit enter or maybe you want to add a comment at the end of the line. The point is that you don't have to move your hand to the mouse to continue your development.

Here are a few other simple but helpful Zend Framework templates:

Zend_Registry::get('${index}')${method};${cursor}

Zend_Registry::set('${index}', $$${variable});${cursor}

Templating can save you tons of time in the long run, investing the time to set up useful templates will pay off ten fold. =] Enjoy!

First Post

2007-12-22T11:43:00.000-05:00

Ha! I've never been much of a writer, I actually chose to study computer science so I wouldn't have to write. So this blogging seems pretty damn foreign to me. However, the benefit of having some place where I have stored some useful information is very attractive to me. So today i will commence doing what I decided not to do in college, write. Well, maybe not today... at least not beyond this intro. =]

I work for a company that is currently writing facebook apps. I use the word company loosely because there are only three of us. The owners hired me as their first employee actually. So I do lot's of web tech stuff and have a unquenched desire to always be learning how to improve my skills. In that regards I have actually learned quite a bit about the web and feel I have some things to share. So that is what this blog is going to be all about. Shew, preview done! =]