Question

I’m working on an inherited system which has some design issues which “OO Buzzwords” frown upon, and some I personally dislike.

It’s a stock and sales handling program for a comic book store.

I have an Article class, which can be any item (Magic cards, toys), and a Publication class that inherits from Article, which represents books and magazines. A Publication has Authors and optionally issue number, while an Article doesn’t.

There’s an Article Editor, which is a GUI to create and modify articles. Since there’s the possibility to load a Publication with an error, and not add a volume number, the interface to work with an article is:

Article a = EntityManager.loadArticle(articleId);
ArticleEditor editor = new ArticleEditor(a);
a = e.getValue();

to allow a to be changed into a Publication, should the need arise.

One of my peeves is that this could be handled more gracefully if it used references, or ar least so it appears to me. My current version uses wraps the last 2 lines’ pattern in a static version, but it still looks ugly because it looks too state-dependent.

---

The second issue comes with Java’s (and most “enterprise” languages’) lack of multiple dispatch: the EntityManager has a save() method, overloaded for both Articles and Publications. This causes a huge issue if I say, for example:

Article a = EntityManager.loadArticle(articleId);
ArticleEditor editor = new ArticleEditor(a);
a = e.getValue();
EntityManager.save(a);

This is currently “solved” by having the ArticleEditor save changes (which seems wrong).

I’m sure there must be some way to adjust the design to eliminate these issues. (I don’t mind a whole re-write, if need be.)

How can I adjust the design to eliminate these issues?

Edit: Publication has Authors, too, not only Numbers.

Answer 1

1. What’s the problem? It seems fine to me.
2. Can’t you simulate multiple dispatch in Java using reflection?