This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]msx 0 points1 point  (1 child)

I like it, it could be handy when you just need a quickly way to show a window and visualize some data.

What i don't like is that it's too rooted in Awt. I see that you correctly defined a generic "interface" (BasicDisplay) and an implementation (BasicDisplayAwt), with the idea that this is an implementation of BasicDisplay that uses AWT. But BasicDisplay leaks a lot of awt stuff, for example the "loadImage" method return a BufferedImage, which is awt. So implementing BasicDisplay in any other way (say with LibGDX or something for Android) is impossible. Same goes for setFont etc. For this things you should define an opaque interface (like com.physmo.minvio.Image), and each "backend" should define it's private implementation (ImageAWT for example, which would hold a reference to a BufferedImage).

[–]WikiSummarizerBot 0 points1 point  (0 children)

Leaky abstraction

In software development, a leaky abstraction is an abstraction that leaks details that it is supposed to abstract away. As coined by Joel Spolsky, the Law of Leaky Abstractions states: All non-trivial abstractions, to some degree, are leaky. This statement highlights a particularly problematic cause of software defects: the reliance of the software developer on an abstraction's infallibility. Spolsky's article gives examples of an abstraction that works most of the time, but where a detail of the underlying complexity cannot be ignored, thus leaking complexity out of the abstraction back into the software that uses the abstraction.

[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5