While preparing a session on (object-oriented) object creation for my Advanced Design and Programming course, I noticed that there are at least two major ways of looking at how to decide on how to create an object. The traditional way is a (still unwritten) pattern language that utilizes the classic Gang-of-Four object creational patterns (and then some) to guide the developer in designing the object creation process.

Fortunately, object creation has a neatly defined design space with clearly independent dimensions and hence lends itself well to a structured discussion. Without further ado, here are the dimensions of this design space as I see them:

1. Delegation. Who gets to create the object? Options are: on-the-spot, this-object, separate-object
2. Selection. How is the concrete class selected? Options are: on-the-spot, by-switch-case, by-subclassing, by-colocating, by-mapping
3. Configuration. How is a class mapping configured? Options are: in-code, by-annotation, by-configuration-file
4. Instantiation. How is the concrete class instantiated? Options are: in-code, by-class-object, by-prototype, by-function-object
5. Initialization. How is the new object initialized? Options are: default, by-cloning, by-fixed-signature, by-key-value-pairs, in-second-step
6. Building. How is the object structure built? Options are: default, by-cloning, by-building

Using this design space, a developer can tailor a solution to the specific design situation at hand. Which options are chosen from the table for which dimension typically follows from the desired flexibility. As always, simpler is better, unless it is too simple.

It is also worth noting that design patterns cover a subspace of the overall design space. For example, the Factory Method pattern uses this-object delegation, by-subclassing selection, says nothing about configuration, in-code instantiation, any initialization, and says nothing about building.

The following table shows the relationship between some well-known design patterns and the choices they codify.

I think a pattern language is still warranted for some design decisions, actually most design decisions, perhaps, if the design space is sparsely populated with viable options. This is not the case with object creation: The design dimensions are almost completely orthogonal, allowing for a pick-and-choose approach. There simply aren’t too many constraints that reduce the options in this design space.

A while back I gushed about how great the Amazon Echo is. True Star Trek feeling for those who remember. I even bought an Amazon Fire tablet to go with it.

With a couple of months more using the devices, I need to point out their weaknesses.

In a nutshell, if you don’t want to be confined to a closed Amazon software ecosystem, don’t bother buying.

The devices shines with an Amazon Prime subscription, but everything beyond that is just tiresome.

For one, I own a media streamer that is not a big brand one and that does not have a microphone and does not call home to some service. I can’t get Kore, the default remote for the Kodi media streamer I’m using, from the Amazon store. I can side-load it, but why do I have to?

My media streamer is coupled with a NAS, because I like to make my own recordings and to watch at my leisure. I also ripped all my CDs so that I can stream my MP3s from that NAS. As to the Amazon Echo, it can’t stream directly from a NAS. I searched high and low, to no avail. How annoying is such a basic feature, missing? I finally found a solution in the form of a work around: I’m using a mobile app, which connects to the Echo using Bluetooth, and streams the music from my NAS. That’s an unnecessary detour, but at least it is working—most of the time, I have yet to figure out why the music stops intermittently.

The final missing feature is a connection with Skype, so that the Echo can serve both as a speaker and a microphone for telephone conferences. If the Echo could do this, each office at work would get one for conferencing. The audio is that amazing. Sadly, the Echo does not support the necessary Bluetooth profile. I guess this is deliberate, though a market opportunity ignored.

Today, I was in two places at once. I participated in the Offener IT Gipfel of Germany’s green party where I had been invited to give a talk on open source and to participate in a panel moderated by a member of the German national parliament.

Open Source senkt Markteintrittsbarrieren. So geht Innovationsförderung! #2OITG pic.twitter.com/U0LW37HiWU

— Dieter Janecek (@DJanecek) November 18, 2015

(Local copy.)

I was also present at the Hochsprung Award ceremonies by way of a video recording where we received first prize for our Startupinformatik concept for creating student startups from our computer science Master program.

Congrats: 1. Platz im Hochsprung Award 2015 an "#startup #informatik" @dirkriehle @TF_UNI_Erlangen pic.twitter.com/7mIXUS632Q

— Sebastian Engel (@seb_engel) November 18, 2015

(Local copy.)

I would usually would have chosen to be in Erlangen to receive the award in person, however, I had long been announced in the Offener IT Gipfel program and could not withdraw, after the Hochsprung-Awards had been decided. My students represented me well.

OpenSym 2016, the 12th International Symposium on Open Collaboration

August 17-19, 2016 | Berlin, Germany

opensym.org/os2016

About the Conference

The 12th International Symposium on Open Collaboration (OpenSym 2016) is the premier conference on open collaboration research and practice, including open source, open data, open education, wikis and related social media, Wikipedia, and IT-driven open innovation research.

OpenSym is the first conference series to bring together the different strands of open collaboration research and practice, seeking to create synergies and inspire new collaborations between computer scientists, social scientists, legal scholars, and everyone interested in understanding open collaboration and how it is changing the world.

OpenSym 2016 will be held in Berlin, Germany, on August 17-19, 2016.

Continue reading →

From the first review: Best application of grounded theory that I have seen in a long time!

From the second review: I have seen grounded theory; this ain’t it.

From the third review: What is grounded theory?

Conclusion: No more grounded theory.

PS: Those reviews are a synthesis of prior experiences.