Inspired by this thread, I've updated the BabyIDE report generator that exports the code for an application in HTML form: The good, old bank example The big planning example There is a long road from a running program in BabyIDE to a Webhuset internet page with links. I hope I've got it right. The interesting part is the navigation pane on the left that displays the program structure. More comments inline below. On 22.08.2017 00:17, Matthew Browne wrote: > Hi Trygve, > What if MODEL is a use case context like PlaceOrder in the shopping > cart example? With trigger methods like these: > >     processProductSelection(desiredProductId: Int) >     getOrderDetails() >     processProductRemoval(productId: Int) >     processPayment() No problem. Any object can play a role in an Interaction, even objects with unavailable classes. > > (Side-note: I probably wouldn't call the role 'Model' in this case, > but rather the name of the Context, so 'PlaceOrder'). In my big planning example, there is the MVC Model (the plan) and the UI (MVC Controller and Views). Both are bifurcated into Data and Interaction parts: Model/frontloading, Model/resource allocation, etc. UI/Dependency diagram,  UI/Gantt chart, etc  I was very uncertain about the latter partitioning when I first did it since I hadn't done anything like it before.  I now believe it's sound since it leads to an orthogonal separation of concerns and thus readable code. See code listing above. > > The debate here is whether or not this is a good design...on the one > hand, people are arguing that there shouldn't be multiple public > entry-points to the Context, e.g. there would only be one public > method like 'startOrder()' and all UI interaction from that point > until the end of the use case would be handled within the PlaceOrder > context. This requires mixing UI concerns into the use case context. I can't judge if a fragment is a good design. I don't see a fundamental problem with many entry points to a Context.  I'm itching to implement several Interactions with separate interaction diagrams to a Context, but I have to do other things first.  I can't see any fundamental or practical problems offhand. I would also need a use case with several scenarios as an example. > And on the other hand, I am arguing that multiple public trigger > methods as above are a fine design as long as you do the appropriate > validation to ensure that the methods aren't called in the wrong > order. And it has the benefit of keeping the UI code decoupled from > the use case. Any design that reflects a mental model shared by end user and programmer is a good design? > > We might need to go through this example from the very beginning in > detail in order to get to the bottom of it, but since you weren't an > active participant in the original discussion we had about it (last > year I think), I figured I'd start with this quick summary. Complete use case, please.  I don't believe in dogma. Cope says that good design evolves through "all the people, all together, all the time." May be some  dogma will emerge after 10 years' experience, not up front today. And then they may be in the form of patterns, not simple Rules (aka Laws). What we need is more complete examples and time to discuss the merits of their design. > > > On Sat, Aug 19, 2017 at 5:32 AM, Trygve Reenskaug > wrote: > > On 18.08.2017 23:11, Matthew Browne wrote: >> On Fri, Aug 18, 2017 at 11:23 AM, Trygve Reenskaug >> > wrote: >> >> In DCI, separation of concerns means that the code is clearly >> separated into Data, Context, Interaction partitions. >> >> >> Maybe I'm being overly literal here, but...the interaction >> happens between the roles, so I think having role declarations >> with 'role' keywords or something to designate "this is the area >> for roles" is sufficient to demarcate the Interaction partition. >> As far as I'm aware there's no "interaction" keyword in the >> trygve language but it's still clear where the interactions are. >> -- > True. I use the Interaction keyword to isolate the context object > from the role scripts. The compiler enforces this bifurcation of > the Context so that the programmer can't 'smart' and cross the  > barrier in his/her head or code. The AssignRoles method is > invisible in the CONTROLLER role script so the indirect access is > required: *CONTEXT.AssignRoles()*. > BTW: There were bugs in my code. Here's an improved version, > hopefully with fewer bugs: (blue = plan views, red = elevation views). > > *Data d  {} > Context ctx { >    void AssignRoles() { >         // assign objects to roles CONTEXT, CONTROLLER, VIEW, and > MODEL >     } >     ctx.role("CONTROLLER").start();    // roles are invisible in > the context so a method call is required to find it > Interaction intr {   // the context is invisible in the role > scripts ro it has to play a role in the Interaction. >      role CONTROLLER { >         void start() { >             repeatForever { >                 void onEvent() { >                      void onUserAction3() { EXIT} >                      CONTEXT.AssignRoles(). >                      void onUserAction1() { VIEW.display() } >                      void onUserAction2() { MODEL.doABC() }  // > not MODEL.getABC() because I don't know what you want to do with > the returned value. >                 } >             } >        } >      Role VIEW { void display() {} } >      Role MODEL { void doABC() {} } >      } >  } > }* > > -- > You received this message because you are subscribed to the Google > Groups "object-composition" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to object-composition+unsubscribe@googlegroups.com > . > To post to this group, send email to > object-composition@googlegroups.com > . > Visit this group at > https://groups.google.com/group/object-composition > . > For more options, visit https://groups.google.com/d/optout > . > > > -- > You received this message because you are subscribed to the Google > Groups "object-composition" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to object-composition+unsubscribe@googlegroups.com > . > To post to this group, send email to > object-composition@googlegroups.com > . > Visit this group at https://groups.google.com/group/object-composition. > For more options, visit https://groups.google.com/d/optout. -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 22 49 57 27