Vacation!

Diving in the Caymans, four days so far. Had a really informative and in depth (OK no pun intended) lesson and dive with Theunis from Cathy Church's Photo Centre. Highly recommended if you'd like to learn more about underwater photography. I'll post and link my photos soon.

Currently Reading

I'm re-reading "Object Oriented Programming: An Evolutionary Approach" by Brad Cox. This was published in 1986 and featured Objective-C as the language of discourse. I read it back in 1987 and object orientation was a little hard to understand. My computer science education to that point was procedural languages and standard data structures. There was some foreshadowing of OOP while I was programming Mac OS 6 at that time - especially with my own popup menus and calling functions with a passed structure describing the state of the popup menu, and there were some calls in the Mac OS Toolbox (Dialog and Control Manager) which were of that type.

Things covered:

  • Loose vs tight coupling
  • Software ICs - these are reusable object classes, usually generic.
  • Dynamic vs Static Binding
  • I'm resonating with the concepts in the book - goes to show that even after 20 years on, things are still valid.

CRineta Bookclub

The Cedar Rapids .Net group (CRineta) is holding a monthly bookclub at Roaster's. We're presently reading "Foundations of Programming" by Karl Seguin. It's available for download from his blog.

The book is extremely .Net centric with respect to examples and focus.

That aside, there are some nuggets of information for us five-percenters (i.e. Mac folk) - we've read the first four chapters so far and here's what I have found:

  • Domain driven design (versus data driven design) - it's important to always keep in mind the end user of your product. Remember that they are the ones who will ultimately be subjected to your application. Software developers tend to be very effective in getting the code to interact with the data, not so much with the users. My take is that sound techniques such as use-case analyses and requirements drive the design of the application rather letting data dictate that.
  • Let requirements drive the design - YAGNI (You Aren’t Going to Need It) referenced on pages 8-9 illustrates the need to come up with a good understanding of the requirements. The YAGNI concept refers to the extent to which you should make your application flexible and adaptable - having requirements will bound that flexibility. The other nice thing about requirements is that they let you derive function pre- and post- conditions which then let you construct unit tests.
  • Many concepts come up over and over in software development - such as cohesion and coupling. I studied these in University back in 1984 under Structured Analysis. Do we forget these concepts only to re-discover them? Do we not teach them to our students?
  • Interfaces let you exchange implementations - especially if you need to build pseudo object classes (called mocking) for testing. Note: interfaces are not a .Net thing - you can apply them in Objective-C, Java and C++ to mention those I know of.
  • Persistence is a good thing but don't let that drive your design. Use Mac OS X's Core Data judiciously to handle data persistence. The section on persistence illustrates the fallacies of going nitty gritty into the depths of SQL (the M$ way) - think NSObjects and let Core Data store them for you.
  • Dependency rejection - this chapter mentions StructureMap as a means of enabling mock objects. While that's a nice add-on suite for the .Net world, think about using class inheritance and interfaces in Objective-C for example, to build mock objects. I haven't investigated if there are equivalents for Cocoa but will post an entry when I find one. One word of caution, many of these suites have been implemented to "scratch a particular itch" in software development - you have to make sure to see if the suite meets your needs or if the tweaking / customisation effort you have to put in makes it not worth your while.

In my humble opinion the book does not meet up to the title "Foundations of Programming". There is very little (if any) about the foundations such as good analysis, design and code techniques. Instead it's a .Net oriented treatise with not a lot of scope beyond that. While I know that M$ rules the roost and everyone (more or less) is obliged to toe the .Net line - there's more out there to programming than .Net.

Previous blog

Here's a link to the previous mac.com hosted blog.