Personally I think adding a new role just for the input pad would
be overkill, but I think Quang's suggested questions to ask are an
excellent way of thinking about it.
I have mixed feelings about the notion that roles need to have
significant behavior of their own, i.e. that it's not a role if it
doesn't have much (or any) difference in behavior from what its
role player already provides via instance methods. One of the
great things about a Context is that it allows you to see how
objects are interacting with each other, and which objects are
participating in each interaction. Some of those objects might not
have much behavior unique to the role they are playing but are
still participating in the interaction, and it would be nice to
highlight that somehow even if we agree that we want to discourage
roles without role methods.
I do agree that one could get into a bad habit of just using roles
as names for existing data interfaces, i.e.:
role myRole {}
requires {...}
(which as you know, the trygve language doesn't even allow anymore
without explicitly saying which instance methods you want to
expose as role methods.)
But I certainly don't see anything problematic with having a
scannedItems role in your example, and I strongly agree with what
Quang said. IMO, even just wanting to name a method differently to
better describe how it's fulfilling its role in an interaction is
a perfectly valid reason to create a role method. I suppose one
could go overboard with this, but most of the time better naming
results in more readable code.
Cheers,
Matt
--
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-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.
According to the use case, "Scanner asks screen to display a list of scanned items." This list of scanned items is causing me some head-scratching.
If I model it as a Role, it differs quite a bit from the other Roles (scanner, screen, card reader and other "physical" objects). The other Roles have a quite natural flow between them. They ask the others to solve a part of the problem, and everything's fine. But the list is basically just temporary state, so the flow between roles turns into something where it doesn't communicate much:...My mental model is different: A role does not model anything by itself. So it would be more precise to say that a ScannerRole identifies/names/maps to an object that represents the physical scanner. This object may play different roles in different contexts. The roles may be named differently in different contects such as BorrowedItems, ReturnedItems, or whatever.
Data. What are the objects. Some clearly represent hardware: scanner, screen, card reader and other "physical" things. I also suspect that it should include a repository object that contains the list of scanned objects. This repository object could play different roles in different contexts. (such as Cancel a transaction?)Am I on the right track, or have I missed your point altogether?
Context. One context for each use case. You say that one of them is "Scanner asks screen to display a list of scanned items." Isn't the use case "Display a list of scanned items" and the above is the implementation you have chosen with a context? Are there other use cases with roles that map to the scanned items? If not, why should you display them?
Interaction (The role scripts). Role scripts may be accessors to the state stored in the roleplayer object without adding its own behavior. (I've looked at my BabyIDE examples: BB4, a simple planning example, has 2 roles with own behavior and 3 with accessors only. BB5, the old bank example, has 2 roles with own behavior and 1 accessor (The AMOUNT). BB6, which pays many bills, has 1 role with own behavior and 1 accessor to the above BB5Bank context! And so on.) Summary: A role does not need to have its own behavior. In trygve, accessors need be explicit, in BabyIDE many roles have no role methods since they may be accessed directly from other roles.
--
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-composit...@googlegroups.com.
To post to this group, send email to object-co...@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 collaborate to achieve a
goal.
Trygve Reenskaug mailto: try...@ifi.uio.no
Morgedalsvn.
5A http://folk.uio.no/trygver/
N-0378
Oslo http://fullOO.info
Norway Tel:
(+47) 22 49 57 27
To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.
Contract fields should only be accessed from the Role's own RoleMethods. This enables the ability to trace the flow of cooperation between Roles, instead of any Role being able to call another Role's underlying object at all times. It's a helpful separation between the local reasoning of how Roles interact locally with their object, and how Roles interact with each other. This helps reading and understanding the use-case-level logic of a Context.
Thanks everyone for your feedback! Now when I have some decent code to show, I think we can get a bit deeper into the problem.Here's the context currently: https://github.com/ciscoheat/haxedci-example/blob/library/src/BorrowLibraryItems.hxQuang, good point with the validation method, it had many arguments, but the main problem is that the keypad is asynchronous, so when it's event-driven I prefer to pass the arguments along. The keypad is part of the screen actually (it's a touch screen), but I eventually ended up making that its own role anyway. And I reversed the validation, so the card scanner will wait for the pin before validating the card. That shortened the arguments as well.
Asynchronous behavior has a way of complicating things. For example, there needs to be a loop detecting if the card has been removed, which forces some safety-checks across the Context.
I would try using an event queue instead of callbacks.
--
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-composit...@googlegroups.com.
--