Book Review – Head First Object Oriented Analysis and Design

Head First: Object Oriented Analysis & Design

This was the first book I’ve read from the Head First collection, and it certainly is quite different than any other technical book I’ve ever read. Head First OOAD is a cross between your typical technical publication, a middle/highschool textbook, and the sundary newspaper funny pages (complete with wordsearch and crossword puzzles… seriously!)

What I Liked

As an introduction to object oriented programming, it’s great. It brings developers who are used to working with objects but not realizing it, into thinking of a completely object oriented based perspective and how and when to create their own custom objects.

I have had experience with developing objects prior to reading this book, however, this helped me to really look at everything as an object working together with other objects. It helped me move away from simply calling functions that were housed in oversized generic classes, and gave better definition to how encapsulation and inheritance properly work.

What I Wasn’t Crazy About

The book intentionally repeats itself over and over again as a learning device to pound it in to the readers memory whatever topic they may be covering. I may be unjustly arrogant about this, but I think it’s unnecessary and fairly annoying at times. Others may appreciate this type of reinforcement, but for me, it was almost distracting.

Additionally, the tone sometimes approaches that of a stereotypical bratty kid, which at times, turned me off. I like to think of coding as being something educated, intelligent, and something generally smart people do (ok, so perhaps I’m glamourizing development – and myself – a bit…), but the characters in Head First OOAD seem kind of, well, uneducated is a good euphemism. This is again, most likely intentional because it comes during sections of the book where develeoper characters are talking back and forth with each other, or playing advocate against one and other, but another thing I’m not a huge fan of.

Finally, for a .NET developer, it’s always great to see examples in your native language, which, you won’t find. All code is written in Java, but it’s not too distracting. Besides, the book is more about conceptuals than code language/syntax.

Would I Recommend the Read?

Definately, especially for developers who are not used to thinking in true object oriented fashion. Additionally, there is a lot of good information regarding software development life cycle, testing, use-case scenarios, and conceptual development that many developers, including myself, would gain a lot from.

However, if you are already senior level, and constantly working with polymorphism, encapsulation, inheritance, and other OO principles regularly, you should probably pickup a more advanced book. I would like to make book reviews a regular part of blog posts, and hopefully I will have some recommendations in future posts. (If anyone would like to leave comments as recommended reading, please do so!)

If you would like to purchase the book, feel free to click the following link (full disclosure: Amazon does pay a percent commission to any sales purchased through this link, helping to support this blog – sort of.)

Not Photoshop VS. Fireworks, Photoshop AND Fireworks

After a pretty lengthy discussion with my colleagues, all of which are developers and not graphic designers, I try and put a different spin on an old debate.

Photoshop vs. Fireworks; which one is better? Like other age old questions – chicken or the egg? – mac or pc? – blonde or brunette? – this question has been debated for years. There is certainly a preference for one or the other when presented with a choice between the two. Here are some of the highlights for Photoshop:

  • Industry standard for photo editing
  • Colorization is more exact
  • Far richer in features and functionality

A few of the highlights for Fireworks:

  • Lighter memory footprint
  • Faster and easier to work with
  • Smaller learning curve for non-graphic designers

However, by pitting Photoshop against Fireworks are many of us missing the real advantages of these tools? I believe this is a case where you should have your cake and eat it too! Use both Fireworks and Photoshop for very specific tasks and get the best of both, because in reality, these are two very different animals.

In my opinion, Photoshop should be used where it’s strength lies, and that is in photo editing. Conversely, Fireworks should be used where it shines, layout design. When you begin developing UI, webpages especially, you generally start with a rough layout, refine the layout, and then begin adding (hopefully) powerful imagery to support your content. Designing layout, where generally you employ vector-based primitive shapes, gradients, and shadowing is extremely fast and easy in Fireworks. If changes need to be made because of sizing, it’s extremely well suited. Next, open up Photoshop and begin designing that dynamite wow-factor image that you can meticulously edit, add filters, etc. Grab that image, put it back into your layout in Fireworks and utilize far friendlier slicing and image optimizing to export images out to be called in your HTML.

Can you do all of these things in Fireworks alone? Sure. Photoshop as well? Yep. However, there is a reason why Adobe has maintained both applications in parallel after they merged with Macromedia. Photoshop is well suited for graphic design of high quality, pixel based, images. Fireworks handles vectors a bit friendlier while being specifically designed for Web Designers first and foremost. If you’re not a professional graphic designer, (and if you’re reading the rest of the posts on this blog you probably aren’t), then you may really like working in both Photoshop for the fine details and Fireworks for layouts and similar mockups.

Let me demo a brief example of the process I quickly outlined. Below is the beginning layout of a website. I’ve used Fireworks to layout the logo, navigation, hoverstates, standard font selection, and the general positioning of elements on the page to get a feel for how the website will be laid out.

Fireworks Layout

Next, I used Photoshop to make changes to this photograph. I’ve added a few filters, created some transparencies on the edges of the photo, and changed the colors slightly. This is the point where a real graphic designer would go to town!

Photoshop Detail

Finally, I put it all together back in Fireworks and begin slicing images out the way I want. The images are optimized for the web and are placed into HTML or CSS-based websites.

Fireworks Slicing

I hope this gives a little bit of a different perspective on how and when to use Photoshop and Fireworks for developers. Happy designing!

Let’s Talk Unit Tests

What is it?

Unit testing is just what it sounds like; you programmatically test very small pieces of code (units) for specific results.
A unit test is code testing code that once written, can be ran over and over again to quickly test changes in environment or code. Code that is unit tested has very specific criteria that can be checked to determine if it is running properly and is isolated from other implementation code to narrow the identifiable problems that may cause a unit test to fail.

Unit tests in Visual Studio are simply classes in a Test Project that are integrated into the development environment for easy development and analysis of

How do you use unit tests?

There are several ways to go about developing unit tests conceptually, and it depends greatly on the goal of your unit tests as well as the development culture/style that you participate in. Very large organizations use unit testing
much differently than smaller shops because they generally have more procedural policies as well as a deeper pool of resources to dedicate specifically to unit testing. In smaller shops, unit testing may be done by the original developer of the application which some organizations are strictly against. The benefit of splitting the work between developers or developer groups is that it provides either the developer specific scenarios to satisfy, as in the case of red-green development; or the unit tester the ability to check the developers work for bugs they may not have been aware of.

I use unit tests primarily either in parallel current development or immediately after because I use
unit tests to verify the work that I've done, as well as prepare for how the application responds in the future when a change or enhancement has been made.

Once the unit tests are written, I run through all of them and check how successful they are. When I notice one that has failed or proved inconclusive I investigate why the failure occurred and can generally pinpoint the offending code fairly swiftly.

You can see below the test results of a list of unit tests that have ran inside Visual Studio for one of my projects.

Unit Test Results

Getting Started

In Visual Studio, you can either create a new Test Project and add Unit Tests to the project, or right click on a function you have created and click Create Unit Tests… This will bring up a list of functions to create unit tests for, select the ones you are interested in and begin.

Personally, I prefer creating my own Test Project, and adding unit tests manually. It’s not quite as automated, but I get exactly the
setup of the test I want with none of the fluff added during automation.

How do you write a unit test?

Writing unit tests are as easy or complex as you want them to be, but it as almost always better to lean towards simplicity. Remember, unit tests by nature should only test a single unit of code and should each have identifiable pass/fail results. Let’s look at some examples and discuss the pro’s and con’s of the approach taken in these examples.

First, we’ll write a simple test to check the retrieval of a single entity based on ID. This is a pretty common action when working with data. Specy is a Linq2SQL entity in my project, so don’t let that throw you off at all.

public void GetSpeciesTest()
    Specy results = null;
    int speciesID = 1;  //a valid speciesID

    results = TSDLC.GetSpecies(speciesID);
    //Check if null

    //Check that species ID returned is species ID supplied
    if (results.SpeciesID != 1)
    //Todo: add any additional checks on the data being returned

    //Check that the species returned is null when not found
    speciesID = 0;  //an invalid speciesID
    results = TSDLC.GetSpecies(speciesID);

First, when you set up a unit test, you need to specify (manually) all of the inputs that your testing function will need; in this case we’re providing a known good speciesID to look up the Specy. Obviously if someone deletes this record then this unit test will fail, so we know as a pre-requisite, this record in the database must exist. Next, we call our function we want to test to retrieve the Specy. If anything within that function throws an unhandled error, the unit test will fail (which is good to know). From here, we can test the result to see if it is as we expect. For demonstration, I’m checking if the ID of the returned Specy does not match the ID provided then we know the function failed to return the data we expected.

Assert.Fail(), simply notifies the test that it has failed and can be called anytime you feel the test has failed.

At this point, a purist would say that’s it; any more information would justify creating a seperate unit test. I, on the other hand, prefer to consider other situations that test the validity of this function as part of this unit test. Please note, this is a personal preference and there are pro’s and con’s to doing so.
Pro is that I believe it’s more manageable than to have such a huge number of unit tests to manage and create as well as conceptually if it fails at any point while trying to do such a basic function, in my mind, the unit as a whole failed. Con is it can be ambiguous without debugging/investigating further exactly which aspect of the test failed, in this case, did it fail in the function call itself, in analysis of the returned result, or when we passed in an empty speciesID.

The last part, check’s what happens when things don’t go as planned, such as passing in an invalid speciesID, does it return back null as we expect, or does it blow up (or perhaps return back a legitimate Specy we didn’t expect – and didn’t want).

A slightly longer example

Here is an example of a slightly more detailed unit test, which creates a new record and then checks to ensure the database creating all of the fields in the record with the data that was passed to it. After it is finished, it calls a delete function to clean up the newly created entry to avoid having entries from unit tests left in the database.

public void CreateRecordTest()
    //init results default
    int results = 0;
    //setup variables for test
    int userID = 1;
    decimal latitude = (decimal)26.2341;
    decimal longitude = (decimal)-81.1234;
    DateTime recordedDate = DateTime.Now;
    string name = "UnitTest";
    string description = "UnitTest - Please delete.";
    decimal quantity = 1;

    //create record
    results = TSDLC.CreateRecord(userID, latitude, longitude, recordedDate, name, description, quantity);

    //results = id, check if valid
    if (results <= 0)

    //Load record and make sure it has same values as entered
    Record record = TSDLC.GetRecord(results);

    if (record.UserID != userID)
    if (record.Latitude.Value != latitude)
    if (record.Longitude.Value != longitude)
    if(record.Recorded.ToShortDateString() != recordedDate.ToShortDateString())
    if(record.Name != name)
    if(record.Description != description)
    if(record.Quantity != quantity)
    //Cleanup (and test delete record)

Using the Test View in Visual Studio

Test View

Once all of these tests are coded, you’re going to want to run them. To run several unit tests at a time you can use the Test View panel (pictured right) in Visual Studio by clicking Test > Windows > Test View. After running the tests the Test Results panel should appear (pictured above), to show you the outcome of each test ran.

Hope this was helpful, and as always please feel free to leave comments about this post below; I look forward to knowing if readers agree, disagree, or have additional suggestions for working with Unit Testing in Visual Studio.