So, Microsoft has pushed this trojan horse to every single user of Windows on the planet. It displays a Windows 10 logo on the taskbar, and it is basically telling you that not only you will get Windows 10 as soon as it comes out, but you should right now begin acting as if you are looking forward to it. Because, you know, you are their biatch.

So, I am firing up a remote desktop (RDP) connection, and the little box appears saying that it is trying to connect:

And then the box just disappears, without an error message or any other hint as to what might have gone wrong.

The interwebz abound with reports of this happening, and people asking how to fix it, and various solutions being offered that range from the complex to the hopelessly complex.

Intel advertises NUC5CPYH - (Celeron N3050) as being compatible with Windows 7. It is not. All my attempts to install Windows 7 Ultimate 64 bit on it failed. The installation would start, and when it would reach the first interactive screen (language selection) the keyboard and mouse would be dead, (not even NumLock would work on the keyboard,) even though both keyboard and mouse work fine on the BIOS screens of the NUC. On other occasions I managed to overcome this problem, (I don remember how,) and the installation would proceed to 99%, only to fail in the end with some error about not being able to update my computer’s boot configuration or something.

I once had a colleague who had a higher rank than me, and who was not only unconvinced by my rational and articulate arguments for doing a certain thing in a certain way, but he concluded the discussion by stating that –and I am not paraphrasing here, this is what he actually said– the way he wanted it done was mentioned in a book, so unless I could find a book backing up my proposal, it was to be done his way.

I did not argue with him at that time, (how can you argue with that?), but I would now like to quickly jot down my thoughts on why saying such a thing is incredibly stupid:

I have this answer on programmers.stackexchange.com which, at the time of writing these words, has 5 upvotes and 10 downvotes, and in all likelihood it will continue collecting downvotes, while I adamantly refuse to remove it, standing 100% by my ideas. I am dumbfounded, as such a thing has never happened before.

Here is the programmers.stackexchange.com question:

Is it okay to have objects that cast themselves, even if it pollutes the API of their subclasses?

I have a base class, Base. It has two subclasses, Sub1 and Sub2. Each subclass has some additional methods. For example, Sub1 has Sandwich makeASandwich(Ingredients... ingredients), and Sub2 has boolean contactAliens(Frequency onFrequency).

Since these methods take different parameters and do entirely different things, they’re completely incompatible, and I can’t just use polymorphism to solve this problem.

Base provides most of the functionality, and I have a large collection of Base objects. However, all Base objects are either a Sub1 or a Sub2, and sometimes I need to know which they are.

It seems like a bad idea to do the following:

1 2 3 4 5 6 7 8 9

for (Base base : bases) { if (base instanceof Sub1) { ((Sub1) base).makeASandwich(getRandomIngredients()); // ... etc. } else { // must be Sub2 ((Sub2) base).contactAliens(getFrequency()); // ... etc. } }

So I came up with a strategy to avoid this without casting. Base now has these methods:

1 2 3

boolean isSub1(); Sub1 asSub1(); Sub2 asSub2();

And of course, Sub1 implements these methods as

1 2 3

boolean isSub1() { return true; } Sub1 asSub1(); { return this; } Sub2 asSub2(); { throw new IllegalStateException(); }

And Sub2 implements them in the opposite way.

Unfortunately, now Sub1 and Sub2 have these methods in their own API. So I can do this, for example, on Sub1.

1 2 3 4 5 6 7 8 9

/** no need to use this if object is known to be Sub1 */ @Deprecated boolean isSub1() { return true; } /** no need to use this if object is known to be Sub1 */ @Deprecated Sub1 asSub1(); { return this; } /** no need to use this if object is known to be Sub1 */ @Deprecated Sub2 asSub2(); { throw new IllegalStateException(); }

This way, if the object is known to be only a Base, these methods are un-deprecated, and can be used to “cast” itself to a different type so I can invoke the subclass’s methods on it. This seems elegant to me in a way, but on the other hand, I’m kind of abusing Deprecated annotations as a way to “remove” methods from a class.

Since a Sub1 instance really is a Base, it does make sense to use inheritance rather than encapsulation. Is what I’m doing good? Is there a better way to solve this problem?

Tags: java, inheritance, type-casting

asked by codebreaker

This article started as a stackoverflow answer, and then I copied it over here to expand on it.

For a discussion of the same issue but in java-oriented terms, see this Stack Overflow answer of mine: Is overriding Object.finalize() really bad? http://programmers.stackexchange.com/a/288724/41811

There is this practice which is unfortunately very prevalent in the C# world, of implementing object disposal using the ugly, clunky, inelegant, ill-conceived, and error prone idiom known as IDisposable-disposing. MSDN describes it in length, and lots of people swear by it, follow it religiously, write walls of text discussing precisely how it should be done and precisely how it works, and precisely how they arrived at this particular way of doing it, etc.

(Please note that what I am calling ugly here is not the object disposal pattern itself; what I am calling ugly is the particular idiom of implementing an extra Dispose method with a bool disposing parameter.)

This idiom was invented under the assumption that the invocation of IDisposable.Dispose() is something optional, or in any case something which might be OK to forget, in combination with the fact that it is impossible to guarantee that our objects’ destructor will always be invoked by the garbage collector to clean up resources. So, people tend to make their best effort to invoke their IDisposable.Dispose() methods, and in case they forget, they also give it one more try from within the destructor. You know, just in case.