Novice design question
in [OOP]
|
Prev: SETP-10 Call for papers
Next: CFP: The 2010 International Conference on Foundations of Computer Science (FCS'10), USA, July 2010
From: Steffen Beyer on 22 Jan 2010 08:23 Hi, I'm stuck in my design of a simple GUI application. Basically, I got a two lists of objects (ListA, ListB) containing very similar items (ItemA, ItemB), let's say ItemB got an additional attribute. Because of the high similarity, lists and items have common ancestor classes (List, Item). The compiler must ensure that ListA can only be filled with ItemA instances, same for ListB, leading to concrete methods like add(ItemA) and add(ItemB) in the list classes. Now I have to edit the lists on screen. The subtle difference should make it possible to write most of the code only once, handling both lists, working with List and Item in the GUI classes. However, if I declare add(Item) in List to make this work, I would lose the compile-time safety. My understanding seems flawed in some way -- I'm sure this is a standard pattern. It would be gread if somebody could point me in the right direction. The implementation is done in Java, btw. Kind regards, -- Steffen Beyer <sbeyer(a)reactor.de> GnuPG key fingerprint: CA00 1611 242B 89D4 E643 E235 05F3 7689 DD3E EB26 Public key available upon request or at http://wwwkeys.de.pgp.net
From: Dmitry A. Kazakov on 22 Jan 2010 08:50 On Fri, 22 Jan 2010 13:23:29 +0000, Steffen Beyer wrote: > I'm stuck in my design of a simple GUI application. > > Basically, I got a two lists of objects (ListA, ListB) containing very > similar items (ItemA, ItemB), let's say ItemB got an additional > attribute. Because of the high similarity, lists and items have common > ancestor classes (List, Item). The compiler must ensure that ListA can > only be filled with ItemA instances, same for ListB, leading to > concrete methods like add(ItemA) and add(ItemB) in the list classes. > > Now I have to edit the lists on screen. The subtle difference should > make it possible to write most of the code only once, handling both > lists, working with List and Item in the GUI classes. However, if I > declare add(Item) in List to make this work, I would lose the > compile-time safety. > > My understanding seems flawed in some way -- I'm sure this is a > standard pattern. > > It would be gread if somebody could point me in the right direction. > The implementation is done in Java, btw. Assuming you have list and item the same type, which is a usual design for doubly-linked lists, Add is a multi-method operation. When these types are different, it is multiply dispatching. In any case Java cannot express that. Additionally you have a constraint that sibling types in the hierarchies cannot be mixed. This is a quite common problem, which no language really addresses in a static (=safe) manner. A typical solution of this problem (I call it parallel type hierarchies) is to have a common private implementation, but publicly unrelated interfaces. You implement, say, Add in some root type. Then privately derive A and B hierarchies from that, making them publicly unrelated types. Usually generics (aka templates) are used as vehicle for types "cloning" in public. Of course generics will sooner or later hinder the reuse anyway, but it is better than cut and paste. If the language supports delegation, that also helps, as you can route Add to its private implementation more easily. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Thomas Gagne on 22 Jan 2010 16:50 I don't see the problem. If someone tries adding aBItem to anAList throw an exception. How would compile-time type safety prevent a user from attempting to add an item to the wrong list? It can't. If compilers could prevent humans from doing something dumb I'd run all our elected officials and UN thrugh GCC.
From: Dmitry A. Kazakov on 22 Jan 2010 18:02
On Fri, 22 Jan 2010 16:50:34 -0500, Thomas Gagne wrote: > I don't see the problem. If someone tries adding aBItem to anAList > throw an exception. Yes, it is unsafe, as it is when you dereference a null pointer. > How would compile-time type safety prevent a user > from attempting to add an item to the wrong list? It can't. Since all types involved are distinct and statically known, it can be done. Add : List_A x Item_A Add : List_B x Item_B > If compilers could prevent humans from doing something dumb I'd run all > our elected officials and UN thrugh GCC. But you still wanted to verify as much as you could about the officials you elect. UN is appointed by countries most of which never had any democratic elections. You need not to run any checks to know what you get there. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |