About

Me Danny van Heumen Gelderland, The Netherlands GPG key: 0xb41cd1aa911958d0 Software engineer github Programming languages Go (golang) Java Python PHP C# C, C++ Projects Significant refactoring and improvement of otr4j. Looking into optional IRCv3 3.1 extension tls. IRCv3 support merged into irc-api on 9th of June 2015. IRCv3 support consists of all base extensions and the optional extension away-notify. IRCv3 support in irc-api IRC client library and Jitsi IRC protocol support.


Read more ...

Refactoring otr4j

A while back I published the Object Oriented Programming series articles. As a use case to support this series, I’ve looked into the code base of the Java implementation of otr (off-the-record), called otr4j, and used it for verifying and validating ideas described in this series. This article describes the findings while refactoring and eventually improving otr4j. The work discussed here can be found at https://github.com/cobratbq/otr4j. (Most recent commit at time of writing c607f0d50b6e791a23be30ca7f123504a5bd4cf2)


Read more ...

Object Oriented Programming: Evolving code

This article was started more than a year ago and was intended to be a close follow up in the series. I never did find the time to release it in that time frame, so now I decided to finish it more than a year later. In the previous articles we discussed different aspects of Object Oriented Programming. Most of these articles leverage the notions of expectations vs.


Read more ...

Object Oriented Programming: Evaluation of design patterns

This article was started more than a year ago and was intended to be a close follow up in the series. I never did find the time to release it in that time frame, so now I decided to finish it more than a year later. Given the definitions of usage logic and implementation logic and the distinction between internal state and expectations, we evaluate the well-known Gang of Four design patterns and some other design patterns.


Read more ...

TODO-supported development

When programming, the problem you are solving may quickly become more complicated. Even if the problem itself remains as simple as you expected at first, you may find other aspects that need your attention. Furthermore, it is not unthinkable that there is an occasional interruption of your work. Therefore it is very beneficial if you can adopt a way of working that allows you to reliably defer secondary curiosities for later and mitigate the “damage” done by unexpected and untimely interruptions.


Read more ...

Object Oriented Programming: Objects as utilities

In the article on Utilities we discussed how utilities, and more specifically, utility methods help to reuse common usage patterns. In this article we explore some of the more elaborate constructions for utilities. Utility methods are lacking portability, persistence, flexibility Utility methods as described in an earlier article are very much like functions. In the paradigm of object oriented programming, they are somewhat limited, though: No portability of logic


Read more ...

Object Oriented Programming: Utilities - Next Generation

In the previous article we discussed how utility methods create reusable usage patterns. These patterns are accessible from everywhere as is required. The patterns are accessible through the use of static methods, which means that they can be used even without needing to instantiate an object of some type. In short, these methods are convenient ways of sharing common usage patterns between otherwise unrelated objects. We also discussed how utilities are (generalized) usage patterns which means that they do not rely on the implementation details that are specific to each concrete type.


Read more ...

Object Oriented Programming: Utilities

In a previous article we discussed how we should design objects, or rather what restrictions we should impose when designing an object. The proposed guideline is strict and will leave a lot of methods “homeless” as these do not qualify for the given restrictions. Utility methods and other utilities are locations for these methods, the usage logic. ‘Utilities’ First, let’s quickly define what I consider ‘utilities’. In the article Implementation and usage we distinguish between two types of logic.


Read more ...

Object Oriented Programming: Designing objects

This is a much discussed topic. This article is not intended as “the solution”, nor does it pretend to know better. This is my attempt to define a number of strict rules that naturally follow from OOP principles, instead of the numerous attempts to define soft rules that mostly cause interpretation problems and result only in more discussions. This article relies on a previous article: Implementation and usage. Furthermore, we will strive for the quite commonly accepted goal of having only a “single responsibility” for an object.


Read more ...

Object Oriented Programming: Concrete types in implementation logic

We have looked quite extensively at the difference between implementation logic and usage logic. There is a similar difference using concrete types versus using interfaces. When do you use the concrete type and when do you generalize to the interface? With this article, I will go into the specific use case of concrete types in implementation logic. Let’s start with a few questions. When you create a new local ArrayList instance, do you declare the variable as the generic List type, or do you use its concrete type ArrayList?


Read more ...