From mira@informatik.uni-siegen.de Tue Mar 23 06:31:26 1999 Received: from aretha.informatik.uni-siegen.de (aretha.informatik.uni-siegen.de [141.99.92.8]) by amber.ccs.neu.edu (8.9.1a/8.9.1) with ESMTP id GAA10200; Tue, 23 Mar 1999 06:31:22 -0500 (EST) Received: from doors.informatik.uni-siegen.de (doors [141.99.92.1]) by aretha.informatik.uni-siegen.de (Mailhost) with ESMTP id MAA24605; Tue, 23 Mar 1999 12:30:44 +0100 (MET) Received: (from mira@localhost) by doors.informatik.uni-siegen.de (Mailhost) id MAA27635; Tue, 23 Mar 1999 12:30:13 +0100 (MET) Message-Id: <199903231130.MAA27635@doors.informatik.uni-siegen.de> Subject: Re: inner classes To: johan@ccs.neu.edu Date: Tue, 23 Mar 1999 12:30:13 +0100 (MET) From: "Mira Mezini" Cc: lieber@ccs.neu.edu, lblando@gte.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Status: R Hi Johan: > We connect the host and view class graphs using inner classes. The > inner classes subclass the view classes. Instead of having a map > class, we defined the inner classes inside subclasses of the host > classes (I'll call these Attach classes (making the ACG), as they > attach a particular view to a host classes) . This allows the inner > classes to access methods and variables on the host classes. Each ACG > has a variable holding an instance of the inner class. > > Since APPCs want to attach the View's behavior back to the host, this > is where the ACG comes in. In order to attach a view to a host class > graph, we have to use the ACG rather than the HCG. Basically we have > to know at object instantiation time if it should be attached to a view. Yes, this is right, the attachment is not transparent. > There is difficulty (as Mira no doubt knows- she wrote her thesis on > this difficulty!) with inheritance, as the ACG should be a variation > of the HCG, but it is a subclass. Basically, only leaf classes in the > HCG can be attached to the view. in short- we cannot inherit behavior > attached from the view. I'm sorry, I don't fully get this. Do you mean the problems with inheritance in HCG that you indicate in the mail; about Sort? If so see the following mail with comments on your Sort implementation. > The key idea here is not inner classes per se, but > rather that we implement attachment by subclassing the view classes. > Subclassing of views gives us an easy way to avoid delegating abstract Well, we get subclassing of both HCG and View at the same time (kind of multiple inheritance due to inner classes. Within the inner class we have visibility for both the HCG and View. So, I don't know what you exactly mean by "is not inner classes per se". > methods, but does not side-step either of the main problems with > proxyies: you still need to translate manually from view objects to > host objects- Well, nobody said you can avoid that. If we don't have language support, we certainly have to do mapping manually. > MyTax is not a subclass of pricing component - and also I don't get this. MyTax is a subclass of one of the classes in the pricing component. > host objects have different identity than view objects. The adapter classes do in a way unify them (even if the pogrammer has to make this unification manually). An instance of MyTax contains an extended instance of the view. And I can put methods in MyTax that hide the existence of the enclosed view object. The main point about subclassing the host classes is that I can call any method that was defined in the host class on instances of ACG -- this is what I call "APPCs are transparent: they add but don't hide functionality". The problem I see is the attachment is not transparent and is static (at compie time). The dynamic version, tries to make the attachment dynamic in the sencse that existing host classes can be attached to the view. It uses delegation to the host object for this purpose and is in fact quite similar to the proxy solution. Comment on your (*): > There is one difficulty that we encounter with (A) that does not come > up wiht (B): since classes can be inside one class only, we cannot use > technique (A) to implement multiple host objects for one view object- > only (B) can do SOP. I don't agree with that. Here is how I would model multiple host objects for one view object: V -------------------+ | a(){...} | | abstract b(); | | abstract c(); | +------------------+ / \ | | H1 | H2 ------------------- | -------------------+ | bImpl(){..}; | | | cImpl() {...}; | | d() {...}; | | | e() {...}; | +------------------+ | +------------------+ / \ | / \ | | | ----------|-----------|----------------|------------- Adaptation -------------- | | | | | | MyH1 | | | ----------------------|----------------|----------------------+ | | MyH2 | | | | +------------------------+ | | V' | | V'' | | | +------------------|+ | -------------------+ | | | | a() //inherited | | | a() //inherited | | | | | b() { bImpl()}; |/ | | b() //inherited | | | | | abst c() //inh. |-------|---| c() { cImpl();} | | | | | |\ | | | | | | +-------------------+ | +------------------+ | | | +------------------------+ | |-------------------------------------------------------------+ V'' sums up everything: V'' = V + H1 + H2 Not automatically. I have to manually implement d() in V' to call the encloding d() and the same with e() in V''. Within V'' you have visibility for both methods implemented in H1 and H2. To compare (A) and (B) replace V with ChargerParty, H1 with Tax, MyH1 with MyTax, V' with RegChargerParty. The difference is that with (A) you can call bImpl to implement b() from the view even if this is a protected method. Note that I am not saying "this is THE solution". First, the current solution suggestions with the inner classes are not at all easy to understand. But, hey, finally, that was my intention in looking at it: my best hope was to find out that is is ugly so that I can justify the need for language support, i.e., for APPCs :-) Second, I am not sure that this is all you can do with inner classes. My intuition kind of says me that they have more potential, but I need to further experiment with it. Will answer your other mail soon. - Mira