Software Engineer

I am a Software Engineer. I have a Bachelor (Honours) of Science in Information Technology from the University of Sunderland - Class of 2003. I have been developing software since 2001 when I was offered a role at CERN as part of their Technical Student Programme.

By 2016 I had grown really tired of the software industry and by the end of 2019 Apple killed whatever excitement I had left. I am not sure what the next 10 years will bring. What I do know is that my apettite to do work that is impactful has only grown bigger and stronger. Great people make me tick more than anything.

I am also tired.

Class Relationships ...Don't Lose Your Train Of Thoughts

During the introduction we established a simple way to identify objects and their respective classes via looking at nouns and verbs in a text.

Second most important thing when it comes to crafting good OO code is class relationships. Can’t really stress enough how important this is. Classes can grow pretty scary. Don’t underestimate this technique if you are trying to design software that you aren’t familiar with its problem domain. Though very basic its simplicity in identifying class relationships is powerful enough to help you write structured OO code.

Failing to identify proper class relationships can lead to unnecessary complexity, multiple responsibilities (driving you crazy), even manifesting concurrency problems.

Looking at the [Survival Kit class][1] you may have noticed that apart from its cost all its other properties are a TShirt, Mug, Wristband and 2 Sticker(s). As you can tell these are classes. (the most straight forward way to identify a class in code is because its first letter is capitalized, so know your code conventions)

In other words, each SurvivalKit has a TShirt, Mug, Wristband and 2 Sticker(s). So whenever you see a has in a text know that you have a class that is a property in another (most commonly known as composition).

The second relationship comes when a class is another. Take a look at everything a SurvivalKit has. You could say that each of them is a SurvivalKitItem(s). When a class is another class it simply inherits all its properties and methods. Now, there should be a good reason to use the is relationship (aka Inheritance) when it comes to classes so use it wisely.

Finally there is uses. Uses most of the time is related to method arguments. Therefore one class is an argument to another’s class method. Would you say that the #dispatch method (which as of now is left stranded) should expect another class as an argument?

With the above in mind, how would you design the SurvivalKitOrder class? With which classes should it have a relationship and what type? (is, has, uses)

Would you incorporate inheritance using a SurvivalKitItem type. If yes, how and why? Leave your comments below.


Things are simplified on purpose. You need to walk before you can run.