• Solid Engineering - D is for Dependency Inversion

    Despite sounding similar, this SOLID principle is Dependency Inversion, which is not Dependency Injection. Dependency Injection is simply the design of a class such that everything it needs is passed into it, which helps with such goals as single responsibility, unit testing, and removing hidden dependencies. Dependency Inversion, however, is an inversion in the way that some might think about software development. It is two rules:

  • Solid Engineering - I is for Interface Segregation

    Keeping the hot side hot and the cold side cold may have been a marketing or ecological failure, but keeping dissimilar responsibilities apart is just good object-oriented programming, and is today’s SOLID principle: the Interface Separation principle.

  • Solid Engineering - L is for Liskov Substitution

    Halfway through SOLID we find the letter L. This stands for the Liskov Substitution Principle. Since it’s self-evident what this means, we can move on.

  • Designing an Apple Watch App

    Similar to others, I found that when the concepts of a watch app meet actual hardware, the ideas give way to reality.

  • Solid Engineering - O is for Open/Closed

    Our next stop on the SOLID tour is the Open/Closed principle. Bertrand Meyer coined this phrase, saying that classes should be “open for extension, but closed for modification”. What this means is that once defined, classes should not be edited in order to add features.

  • Solid Engineering - S is for Single Responsibility

    Suppose you were writing a server. This server needed to serve a graph of data objects. Furthermore, the data needed to be delivered in XML. So, you write a nice interface and add a simple method to each data object:

  • Solid Engineering - Introduction

    When discussing and thinking about the engineering of software, I often think in terms of solid engineering. What I mean by this is the dictionary definition of solid: something strong and stable, well made and dependable. Experience brings with it insight into patterns of construction, and an ability to recognize the wisdom that others share. Certain things in software development occur again and again, and these often have an available solution that will increase the dependability and stability of the whole codebase, proven through unit testing.

  • A Question of Competence

    Years ago, when I had a (lamentably lost) personal journal, I wrote about a number of personal topics. At the time, I was reading many technical blogs, sharpening my knowledge, but when I sat down to write, it was almost invariably non-technical. I thought occasionally about adding my voice to the programming world, but, really, what did I have to say? Anything I could think of to write about, I could easily find better examples of elsewhere online. Any challenge that I had solved recently was usually with advice found on other blogs, and didn’t seem worth talking about.