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 With static methods, the only dynamic aspects of its execution are the input parameters.


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 ...

Object Oriented Programming: Accessor methods

In a follow up post to Object Oriented Programming: Curiosity of access modifiers we look at the purpose of accessor methods and how these should be used. We will point out some common mistakes in the use of accessor methods that need not happen. In correcting these mistakes, it is sometimes possible to get more support from the compiler or type system for the rest of your implementation. The reason for accessors As discussed earlier, there exists the notion of Encapsulation.


Read more ...

Object Oriented Programming: Curiosity of access modifiers

In object oriented programming languages there are a number of different access levels available. These access levels can be applied to fields and methods. Access levels are there to ensure the features of an object are called only by those parts of the logic that are allowed to access them. They enforce encapsulation, separation of implementation logic. In a class hierarchy-based OOP language there are typically 4 levels of access modifiers: private Access is provided only to other methods within the same class.


Read more ...

Object Oriented Programming: Implementation and usage - Generalized code

In the previous article we defined the notions of implementation and usage (logic). We noted how implementation logic is allowed access to internal state, while any other logic can only use the object, i.e. access its public fields and methods. This article extends on the previous article by looking at the way we can reuse logic, either usage or implementation logic. In this article we focus on internal state only. Expectations, which may be stored with the internal state inside the object, are there only for use and are not managed by the implementation logic.


Read more ...

Object Oriented Programming: Implementation and usage

One of the first things to do, is to define clear notions of implementation logic and usage logic. The notions of ‘implementation’ and ‘usage’ will be used on multiple occasions in order to define a clear distinction. This definition is, of course, made in the context of object oriented design/programming. In no way is this post intended as a post on new information. It is simply meant to emphasize the notions as these are referenced in upcoming articles and I rely on these notions to make clear and strict distinctions and boundaries.


Read more ...

Object Oriented Programming series introduction

Object oriented programming is a well known term. Well, … literally, the term “object oriented programming” is well known. What object oriented programming exactly is, or how you do this thing, is less clear. There is confusion about the exact meaning of the term Object Oriented Programming, as well as the semantics and even into specific details. Take, for example, this email conversation with Dr. Alan Kay, who is believed to have coined the term originally.


Read more ...