the Context object
Jim Gay
this is my understanding. I'll try to keep it focused only on Context.
In a Rails application, a controller action is the Context. When no
logic aside from the use case needs to be described that seems to be
true.
When we need to run an "if" block to check for some environment or
object attribute, then we could either look at the entire action as a
Context, or look at the executed block of the "if/else" as a Context.
I've seen sample code on this list refer to instantiating some type of
Context object and executing the algorithm defined in it, but as far
as I can tell in my world, I have no need for that.
I can only see a need to create a type of Context object if the use
case could be performed outside of the controller action, for example,
from a command line interface, but even then this is hypothetical and
might still warrant it being treated separately.
When a method from a Role is performed we could be initializing a
separate Context within some method block but doing so defeats the
purpose of DCI in making readable code.
I've been thinking about the DCI approach as OOOP (Obvious Object
Oriented Programming)
--
Jim Gay
Saturn Flyer LLC
http://www.saturnflyer.com
571-403-0338
Ant Kutschera
Think of a Context object as a component which contains roles.
Sure, you could do without it, and program your logic in the action,
but that is like putting SQL into PHP pages. The SQL does not belong
there.
Generally speaking, you only need to create a context, if it contains
roles. With that, I mean that if you have a collaboration (ie objects
which need to work together), then you may need a context. If those
objects need extra behaviour that what they already have, then its
probably that you need a context, and that extra behaviour can be
implemented in roles.
Here is an example where sometimes you use a context, and other times
you don't. This is code that I have copied out of my controller
} else if (input.equalsIgnoreCase("D")) {
discountLastProductInBasket();
} else if (input.equalsIgnoreCase("C")) {
completeSale();
"discounting" requires no context (because I already have all the
behaviour, and in my collaboration diagram I only have one object,
namely the basket) - its a simple model update
private void discountLastProductInBasket() {
if (model.getBasket().isEmpty()) {
getLog().info("basket empty.");
} else {
model.getBasket().discountLastProduct(new BigDecimal("5.00"));
getLog().info("discount applied.");
}
}
completing the sale is much more complex, and requires more
behaviour. additionally, my collaboration diagram contains things
like a sales log, printer, etc. Those objects don't exist like they
would in OO - but rather the behaviour they would have if they did
exist is temporarily added to the basket object, so that the basket,
playing the respective role, can do the work which the use case
requires to be done.
private void completeSale() {
new SalesContext(till, basket).execute();
}
Does that help?
Ant
James O. Coplien
On Sep 13, 2011, at 2:49 , Ant Kutschera wrote:
> Think of a Context object as a component which contains roles.
That's hard for me to do, because objects exist at run time and roles exist at compile time.
Jim Gay
> Hi Jim,
>
> Think of a Context object as a component which contains roles.
>
> Sure, you could do without it, and program your logic in the action,
> but that is like putting SQL into PHP pages. The SQL does not belong
> there.
>
> Generally speaking, you only need to create a context, if it contains
> roles. With that, I mean that if you have a collaboration (ie objects
> which need to work together), then you may need a context. If those
> objects need extra behaviour that what they already have, then its
> probably that you need a context, and that extra behaviour can be
> implemented in roles.
Thanks for the feedback, Ant.
But your argument doesn't convince me that I'm incorrect in my understanding.
A Rails controller initializes and calls a method to respond to some
request. That method block, or instance of the controller if you
prefer, serves as the Context; it has knowledge of the
request/response (the environment) and does the job of gathering the
necessary data objects and the roles required for those objects to
perform whatever tasks are necessary.
As far as I can tell, your completeSale method is just a way to hide
your algorithm somewhere else. But isn't that the opposite of what we
intend to do with DCI? And are you using this method elsewhere in your
application?
A Context should only be created explicitly as an object if it can be
reused somewhere. When a user interacts with a web application, each
controller action and response is unique. If there are reusable parts,
only then would I expect to create another object to handle it.
Even so, and as far as I can tell, the Context is a conceptual
structure so a method can and should serve as the Context where
necessary. It seems to me that the DCI paradigm encourages us to make
code reusable from the perspective of clarity of use and to avoid
burying functionality like that.
In the Rails world there's a lot of encouragement for "skinny
controllers and fat models" meaning you move all that you can down
into the model layer.
As I understand DCI, it says that these should not be in the model
layer (which is really just the class) but should be very obviously
applied to the object layer (the forgotten layer in most applications
without DCI). The place that makes the most sense to do this, and the
place that seems to be the Context, is the individual controller
action.
Ant Kutschera
Ant Kutschera
> As far as I can tell, your completeSale method is just a way to hide
> your algorithm somewhere else. But isn't that the opposite of what we
> intend to do with DCI? And are you using this method elsewhere in your
> application?
other cases I don't. The context then contains the code which casts
the objects into roles (adds behaviour to them) and starts/implements
the use-case/collaboration.
> A Context should only be created explicitly as an object if it can be
> reused somewhere. When a user interacts with a web application, each
> controller action and response is unique. If there are reusable parts,
> only then would I expect to create another object to handle it.
explicitly as an object if it can be reused somewhere"? That's news
to me. The context is simply a place where objects are cast into
roles and the interaction is started. Everytime the user does
something so that the same interaction is required, the context is
normally re-instantitated, but doesn't have to be.
> Even so, and as far as I can tell, the Context is a conceptual
> structure so a method can and should serve as the Context where
> necessary. It seems to me that the DCI paradigm encourages us to make
> code reusable from the perspective of clarity of use and to avoid
> burying functionality like that.
the right place - and that place is not in a class, rather in a "role"
- which is a set of methods which are added to an object for just as
long as it needs their behaviour, i.e. during the life of the context.
> In the Rails world there's a lot of encouragement for "skinny
> controllers and fat models" meaning you move all that you can down
> into the model layer.
>
> As I understand DCI, it says that these should not be in the model
> layer (which is really just the class) but should be very obviously
> applied to the object layer (the forgotten layer in most applications
> without DCI). The place that makes the most sense to do this, and the
> place that seems to be the Context, is the individual controller
> action.
are being encouraged to move into the model, should be moved into the
model if you do DCI. They should be moved into rolemethods - methods
belonging to roles. The context then injects (or some other way) the
role methods into the relevant objects so that they can do their
stuff.
If you just move all the behaviour into the model, then its plain OO.
And the problem is, its not really clear which methods are used when -
you just have a heap of attributes and methods and it is hard to see
what is useful for a specific use case or collaboration.
The Sales Context could look something like this:
public class SellItemsInBasketContext {
private final Till till;
private final Basket basket;
public SellItemsInBasketContext(Till till, Basket basket) {
this.till = till;
this.basket = basket;
}
protected interface SalesLog {
void createRecords(String authID, String salesRef, PaymentType
paymentType, Date timestamp);
}
protected interface SalesOrderDatabase {
SalesOrder createSalesOrder(String authID, String tillNumber, String
paymentType);
}
protected interface Printer {
/** prepares the receipt */
PrintJob prepareReceipt(String authID, UUID salesRef, Basket basket,
PaymentType paymentType);
/** call to self */
boolean hasEnoughPaper();
}
protected interface PaymentPartner {
/** retrieves the payment authorization ID from the payment device.
null if unsuccessful. */
String getEPaymentAuthID();
}
Those interfaces are simply a Java specific thing. They are just
saying that those are the methods in each role. The context also has
a method (sometimes people create several methods) for starting or
implementing the interaction. In this example, it is "execute":
public Result execute() {
// ***********
// ROLE ASSIGNMENT
// ***********
SalesOrderDatabase salesOrderDatabase = new
SalesOrderDatabaseImpl(basket);
SalesLog salesLog = new SalesLogImpl(basket);
Printer printer = new PrinterImpl(till);
PaymentPartner paymentPartner = new PaymentPartnerImpl(basket);
// ***********
// USE CASE STEPS
// ***********
PrintJob printJob = null;
if(basket.isEmpty()){ // STEP 1
till.getErrorInformation().setError("Nothing to sell!");
}else{
if(!printer.hasEnoughPaper()){ // STEP 2
till.getErrorInformation().setError("Not enough paper!");
}else{
String authID = null;
if(PaymentType.electronic.equals(till.getPaymentType())){ // STEP
3
authID = paymentPartner.getEPaymentAuthID(); // STEP 3.1
if(authID == null){
// STEP 3.2
till.getErrorInformation().setError("E-payment failed. See card
reader.");
}
}
SalesOrder so = salesOrderDatabase.createSalesOrder(authID,
till.getTillNumber(), till.getPaymentType().toString()); // STEP 4
salesLog.createRecords(authID, so.getSalesRef().toString(),
till.getPaymentType(), so.getTimestamp()); // STEP 5
printJob = printer.prepareReceipt(authID, so.getSalesRef(),
basket, till.getPaymentType()); // STEP 6
updateTillsBalance(); // STEP 7
till.reset(); // STEP 8
basket.reset(); // STEP 8
getLog().info("Sale completed.");
}
}
return new Result(till, basket, printJob);
}
As an example of what a role looks like, here is the sales order
role. Notice how it is pure behaviour, and operates on "self" - which
is the object playing the role, in this case the "basket", which is a
list or products being sold.
class SalesOrderDatabaseImpl extends Role<Basket> implements
SalesOrderDatabase {
SalesOrderDatabaseImpl(Basket basket) {
super(basket);
}
/** {@inheritDoc} */
@Override
public SalesOrder createSalesOrder(String authID, String tillNumber,
String paymentType) {
EntityManagerFactory factory =
Persistence.createEntityManagerFactory("dci2");
EntityManager em = factory.createEntityManager();
em.getTransaction().begin();
Long customerNumber = null;
BigDecimal customerDiscount = null;
if(self.getCustomer() != null){
customerNumber = self.getCustomer().getNumber();
customerDiscount = self.getCustomer().getLoyaltyDiscount();
}
SalesOrder so = new SalesOrder();
so.setAuthID(authID);
so.setCustomerNumber(customerNumber);
so.setCustomerDiscount(customerDiscount);
so.setTillNumber(tillNumber);
so.setPaymentType(paymentType);
for(Product b : self.getProducts()){
SalesOrderItem soi = new SalesOrderItem();
so.getItems().add(soi);
soi.setSalesOrder(so);
soi.setDiscountPercent(b.getDiscountPercent());
soi.setPrice(b.getPrice());
soi.setProductCode(b.getProductCode());
soi.setTitle(b.getTitle());
}
em.persist(so);
for(SalesOrderItem soi : so.getItems()){
em.persist(soi);
}
em.getTransaction().commit();
return so;
}
}
Stephan Herrmann
today, I suggest to see it as an investment for the future: as long as
the controller can be encoded within a single method of < 10 lines,
things are fine. If the behavior can be pushed into the model and
everything remains crisp and clear, you seem to be fine with OOP. If
either of these premises breaks over time, either the model is getting
too fat and you want to partition it into s.t. like use cases, or, if
the controller method is getting fat and you want to break it up into
pieces sharing the same state, or, if s.t. should be reused, e.g.,
over time, or, if anything happens during evolution of your
application that will not nicely fit into the original design, then
having a context object is a very convenient thing to have.
Compare to writing a standalone application: you can do a lot of
things in the static main procedure, maybe you don't see the need to
do OOP at this level, so you don't need a main instance and do a lot
of coding in - say - Pascal style. Still it's probably good practice
to leave the procedural level and create instances and delegate
execution to these instances as soon as possible, just to consistently
leverage the OO paradigm.
Sure, a controller method can already be used as a grouping mechanism
holding some variables and initiating interaction among the referenced
objects. A context object is basically a more powerful grouping
mechanism. How much more power depends on what church you go to. OT/J
tries not to limit your freedom so in that language a context can be
used for grouping all of these: role classes, role instances, role
assignment, role state, context state, and contexts can be aggregated
from smaller contexts and can be refined using inheritance. Nobody
forces you to use all of these right away (some may say, some of these
concepts are evil), but as a system grows and evolves my experience
tells me that you'll appreciate all of these sooner or later.
cheers,
Stephan
Jim Gay
> On Sep 14, 5:41 am, Jim Gay <j...@saturnflyer.com> wrote:
>> A Context should only be created explicitly as an object if it can be
>> reused somewhere. When a user interacts with a web application, each
>> controller action and response is unique. If there are reusable parts,
>> only then would I expect to create another object to handle it.
>
> Where do you get the idea that "a context should only be created
> explicitly as an object if it can be reused somewhere"? That's news
> to me. The context is simply a place where objects are cast into
> roles and the interaction is started. Everytime the user does
> something so that the same interaction is required, the context is
> normally re-instantitated, but doesn't have to be.
For what other reason (besides reuse) would I need an explicite
context object? If an instance of my controller performing an action
serves as the context, why obfuscate into another object?
>> Even so, and as far as I can tell, the Context is a conceptual
>> structure so a method can and should serve as the Context where
>> necessary. It seems to me that the DCI paradigm encourages us to make
>> code reusable from the perspective of clarity of use and to avoid
>> burying functionality like that.
>
> While DCI is about clarity, it is more about putting the algorithms in
> the right place - and that place is not in a class, rather in a "role"
> - which is a set of methods which are added to an object for just as
> long as it needs their behaviour, i.e. during the life of the context.
The "role" is not the place for the algorithm. The Role is something
an object plays. The context is the place for the algorithm and it
coordinates the objects, roles, and the interaction among objects.
>> In the Rails world there's a lot of encouragement for "skinny
>> controllers and fat models" meaning you move all that you can down
>> into the model layer.
>>
>> As I understand DCI, it says that these should not be in the model
>> layer (which is really just the class) but should be very obviously
>> applied to the object layer (the forgotten layer in most applications
>> without DCI). The place that makes the most sense to do this, and the
>> place that seems to be the Context, is the individual controller
>> action.
>
> The behaviour which is in fat controllers, i.e. algorithms, which you
> are being encouraged to move into the model, should be moved into the
> model if you do DCI. They should be moved into rolemethods - methods
> belonging to roles. The context then injects (or some other way) the
> role methods into the relevant objects so that they can do their
> stuff.
>
> If you just move all the behaviour into the model, then its plain OO.
> And the problem is, its not really clear which methods are used when -
> you just have a heap of attributes and methods and it is hard to see
> what is useful for a specific use case or collaboration.
This is exactly what I am saying here. But I'm raising the question
about whether the instance of the controller performs the task of the
Context.
I see no explicit reason that an instance of a controller could not
perform this function, nor why it doesn't make sense to do so.
Jim Gay
<stephan....@onlinehome.de> wrote:
> If you're not convinced that context objects add value to your design
> today, I suggest to see it as an investment for the future: as long as
> the controller can be encoded within a single method of < 10 lines,
> things are fine. If the behavior can be pushed into the model and
> everything remains crisp and clear, you seem to be fine with OOP. If
> either of these premises breaks over time, either the model is getting
> too fat and you want to partition it into s.t. like use cases, or, if
> the controller method is getting fat and you want to break it up into
> pieces sharing the same state, or, if s.t. should be reused, e.g.,
> over time, or, if anything happens during evolution of your
> application that will not nicely fit into the original design, then
> having a context object is a very convenient thing to have.
I agree completely with this. In a web framework, a separate object
would make unit testing simpler too, but I see that as an artifact of
testing in the relationship to a request and response (which
complicates the setup).
>
> Compare to writing a standalone application: you can do a lot of
> things in the static main procedure, maybe you don't see the need to
> do OOP at this level, so you don't need a main instance and do a lot
> of coding in - say - Pascal style. Still it's probably good practice
> to leave the procedural level and create instances and delegate
> execution to these instances as soon as possible, just to consistently
> leverage the OO paradigm.
>
> Sure, a controller method can already be used as a grouping mechanism
> holding some variables and initiating interaction among the referenced
> objects. A context object is basically a more powerful grouping
> mechanism. How much more power depends on what church you go to. OT/J
> tries not to limit your freedom so in that language a context can be
> used for grouping all of these: role classes, role instances, role
> assignment, role state, context state, and contexts can be aggregated
> from smaller contexts and can be refined using inheritance. Nobody
> forces you to use all of these right away (some may say, some of these
> concepts are evil), but as a system grows and evolves my experience
> tells me that you'll appreciate all of these sooner or later.
>
> cheers,
> Stephan
I can see that. I've been doing a lot of thinking about this and
working with 2 projects to test out the ideas to see how they feel.
When first approaching this, however, I can see a controller action
that just initializes some type of context object and moves all the
decisions there. Looking at that, I step back and wonder, "for what
concrete reasons would I need that other object assuming that my
controller action is only run in a certain situation (the context) and
not reused with varying parameters?"
As I'm thinking through this I'm also trying to find conventions. What
will I name my context objects in a way that makes sense with the use
case?
In Rails, for example, the models and controllers are often tightly
mapped. Creating a Product goes through the ProductsController.
Perhaps needs will be different, but that makes a lot of sense when
getting started.
The value I see in having an explicit Context object (not the
controller) is that I can write my program without respect to how it
is performed.
For example if I create a CustomerBuysTacos object, I can develop a
completely functioning application and where that context gets the
data that it needs, assigns the roles, and performs the actions
*without hooking it into an implementation*.
I could create this program and later decide that instead of a web
application, it is a desktop application, or mobile phone application.
By starting with the context object separately, I can worry about web
API endpoints later and layer on my integration tests to ensure that
the implementation matches the use cases.
rune funch
For what other reason (besides reuse) would I need an explicite
context object? If an instance of my controller performing an action
serves as the context, why obfuscate into another object?
Risto Välimäki
--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.
Jim Gay
> 2011/9/28 Jim Gay <j...@saturnflyer.com>
>>
>>
>> For what other reason (besides reuse) would I need an explicite
>> context object? If an instance of my controller performing an action
>> serves as the context, why obfuscate into another object?
>
> I believe that trying to learn DCI by looking at MVC is like trying to build
> a plane by looking at a car. They are similar in some respects that you
> might actually be convinced you could just mount wings on the car at it fly.
> (not accepting that Harry Potter could just wish it to do so)
>
> There's an overlap between MVC and DCI but firstly MVC does not segregate
> what the system is and what it does.
Well, to be fair: DCI is a complement to MVC, is it not? I'm not
convoluting the two, I'm trying to discern how one complements the
other.
> Several controllers usually take part in one use case.
I'm very curious about this comment. Is this necessarily true? Why?
If we're talking about HTTP requests, then we're working with a
stateless environment, but I imagine that by involving multiple
controllers I'd need to be keeping track of state. If that's true,
then either you're implying that it should track state, or I'm
misunderstanding something.
I recognize that my comments here map a 1 to 1 relationship with HTTP
requests and controller functions. Perhaps you're thinking
otherwise...?
> The context is not part of the controller action or even the controller,
> rather more controllers take part of the execution of one interaction
> The context therefor comes before the controller.
> So another way of phrasing your own question would be If you already have a
> context what's the action doing?
> -Rune
>
--
James O. Coplien
On Sep 28, 2011, at 6:03 , Jim Gay wrote:
>>
>> Several controllers usually take part in one use case.
>
> I'm very curious about this comment. Is this necessarily true? Why?
I am curious, too, and would be very surprised to find it so.
rune funch
2011/9/28 rune funch <funchs...@gmail.com>
2011/9/28 Jim Gay <j...@saturnflyer.com>For what other reason (besides reuse) would I need an explicite
context object? If an instance of my controller performing an action
serves as the context, why obfuscate into another object?I believe that trying to learn DCI by looking at MVC is like trying to build a plane by looking at a car. They are similar in some respects that you might actually be convinced you could just mount wings on the car at it fly. (not accepting that Harry Potter could just wish it to do so)There's an overlap between MVC and DCI but firstly MVC does not segregate what the system is and what it does. It doesn't help you keep the algorithm in one place either. Several controllers usually take part in one use case.The context is not part of the controller action or even the controller, rather more controllers take part of the execution of one interactionThe context therefor comes before the controller.So another way of phrasing your own question would be If you already have a context what's the action doing?-RuneI like to reason the connection between MVC and DCI so that in DCI you simply take that M away, and replace it with DCI. So DCI + MVC becomes DCI + VC.
rune funch
A use case doesn't map 1:1 to http request. Thick of booking one
return flight say from Copenhagen to Berlin how many round trip do you
have to the server before you're done? It's one use case none the less
>> The context is not part of the controller action or even the controller,
>> rather more controllers take part of the execution of one interaction
>> The context therefor comes before the controller.
>> So another way of phrasing your own question would be If you already have a
>> context what's the action doing?
>> -Rune
>>
>
>
>
> --
> Jim Gay
> Saturn Flyer LLC
> http://www.saturnflyer.com
> 571-403-0338
>
rune funch
My assumption is the usual MVC framework not MVC.
Jim Gay
<risto.v...@gmail.com> wrote:
> I like to reason the connection between MVC and DCI so that in DCI you
> simply take that M away, and replace it with DCI. So DCI + MVC becomes DCI +
> VC.
I haven't seen anything that suggests this. In fact, in the article
"The DCI Architecture: A New Vision of Object-Oriented Programming"
(http://www.artima.com/articles/dci_vision.html) Figure 5 clearly
shows that DCI is not a replacement of the model. It is a coordination
of concerns in the use case where DCI takes into account the needs of
the objects and how they act and what is displayed.
Jim Gay
> Thick of booking one
> return flight say from Copenhagen to Berlin how many round trip do you
> have to the server before you're done? It's one use case none the less
This assumes that you'll implement it in a way that requires multiple
round-trips. Perhaps there's only 1 flight to select, or perhaps all
the information you need can be presented in a single resource. Your
example implies a use case, but we don't actually have any of the
constraints about it here.
Regardless of that, a single instance of a controller performing an
action still could act as the Context.
rune funch
> On Wed, Sep 28, 2011 at 12:11 PM, rune funch <funchs...@gmail.com> wrote:
>> Thick of booking one
>> return flight say from Copenhagen to Berlin how many round trip do you
>> have to the server before you're done? It's one use case none the less
>
> This assumes that you'll implement it in a way that requires multiple
> round-trips. Perhaps there's only 1 flight to select, or perhaps all
> the information you need can be presented in a single resource. Your
> example implies a use case, but we don't actually have any of the
> constraints about it here.
Interesting. How will you find possible flights before you know when I
want to fly? How will you know what the the price is before I've
picked the flights? Do I want insurance? Check in bagages?
> Regardless of that, a single instance of a controller performing an
> action still could act as the Context.
Sure the interaction on a context could serve the purpose of an action
>
> --
> Jim Gay
> Saturn Flyer LLC
> http://www.saturnflyer.com
> 571-403-0338
>
Jim Gay
> Den 28/09/2011 kl. 18.20 skrev Jim Gay <j...@saturnflyer.com>:
>
>> On Wed, Sep 28, 2011 at 12:11 PM, rune funch <funchs...@gmail.com> wrote:
>>> Thick of booking one
>>> return flight say from Copenhagen to Berlin how many round trip do you
>>> have to the server before you're done? It's one use case none the less
>>
>> This assumes that you'll implement it in a way that requires multiple
>> round-trips. Perhaps there's only 1 flight to select, or perhaps all
>> the information you need can be presented in a single resource. Your
>> example implies a use case, but we don't actually have any of the
>> constraints about it here.
> Interesting. How will you find possible flights before you know when I
> want to fly? How will you know what the the price is before I've
> picked the flights? Do I want insurance? Check in bagages?
These questions assume that the answers are relevant.
We could have a service that flies daily at the same time from
Copenhagen to Berlin with everything included.
Here's a simple use case:
Customer selects the flight date and purchases the seat.
In the case of a more complicated example, what would be your use
case, and how would the Context object fit in?
>> Regardless of that, a single instance of a controller performing an
>> action still could act as the Context.
> Sure the interaction on a context could serve the purpose of an action
That reads like you reluctantly accept it. If that's so, why be reluctant?
Why should I *not* think of the controller action in this way?
rune funch
Rune
Den 28/09/2011 kl. 18.36 skrev Jim Gay <j...@saturnflyer.com>:
> On Wed, Sep 28, 2011 at 12:26 PM, rune funch <funchs...@gmail.com> wrote:
>> Den 28/09/2011 kl. 18.20 skrev Jim Gay <j...@saturnflyer.com>:
>>
>>> On Wed, Sep 28, 2011 at 12:11 PM, rune funch <funchs...@gmail.com> wrote:
>>>> Thick of booking one
>>>> return flight say from Copenhagen to Berlin how many round trip do you
>>>> have to the server before you're done? It's one use case none the less
>>>
>>> This assumes that you'll implement it in a way that requires multiple
>>> round-trips. Perhaps there's only 1 flight to select, or perhaps all
>>> the information you need can be presented in a single resource. Your
>>> example implies a use case, but we don't actually have any of the
>>> constraints about it here.
>> Interesting. How will you find possible flights before you know when I
>> want to fly? How will you know what the the price is before I've
>> picked the flights? Do I want insurance? Check in bagages?
>
> These questions assume that the answers are relevant.
> We could have a service that flies daily at the same time from
> Copenhagen to Berlin with everything included.
> Here's a simple use case:
> Customer selects the flight date and purchases the seat.
But it's not any giving use case but your average use case for a low
fare flight. Easy jet ryanair or similar.
> In the case of a more complicated example, what would be your use
> case, and how would the Context object fit in?
>
>>> Regardless of that, a single instance of a controller performing an
>>> action still could act as the Context.
>> Sure the interaction on a context could serve the purpose of an action
>
> That reads like you reluctantly accept it. If that's so, why be reluctant?
> Why should I *not* think of the controller action in this way?
I'm not reluctant at all I just think you have it upside down. The
interaction of the context replaces the action. You don't have roles
in a controller and hence it's no context.
>
> --
> Jim Gay
> Saturn Flyer LLC
> http://www.saturnflyer.com
> 571-403-0338
>
James O. Coplien
On Sep 28, 2011, at 6:20 , Jim Gay wrote:
> Regardless of that, a single instance of a controller performing an
> action still could act as the Context.
That makes for a pretty fat controller, which is bad design.
rune funch
> Customer selects the flight date and purchases the seat.
Never said you could create a simple UC that only requires one round
trip. We don't have any in the project I'm on but that doesn't mean
that I could come up with one
-Rune
>
> In the case of a more complicated example, what would be your use
> case, and how would the Context object fit in?
>
>>> Regardless of that, a single instance of a controller performing an
>>> action still could act as the Context.
>> Sure the interaction on a context could serve the purpose of an action
>
> That reads like you reluctantly accept it. If that's so, why be reluctant?
> Why should I *not* think of the controller action in this way?
>
> --
> Jim Gay
> Saturn Flyer LLC
> http://www.saturnflyer.com
> 571-403-0338
>
James O. Coplien
On Sep 28, 2011, at 6:35 , Jim Gay wrote:
> Why should I *not* think of the controller action in this way?
One reason is separation of architectural concerns. MVC separates the presentation from the code that feeds it; DCI separates data from use case. There is no use case line in MVC: indeed, MVC is built more around reactive events than anything with long-term temporal structure. Aligning the structures of DCI with MVC can artificially constrain evolution by arbitrarily aligning two independent shear lines.
Second, this makes for a fat Controller — which is another way of saying that it is poor separation of concerns.
People keep bringing up web interfaces here. Many web interfaces — especially airline reservation systems — are much less modal than the examples here suggest, so I can argue that they function as atomic event architectures. And you give the user more flexibility if you design them that way. I can jump around from screen to screen at will. I might start with a selection of class of seats — e.g., business class — before selecting an origin and destination. Or I might select a flight that infers an origin and destination, and then select a flight class. After doing either of these I might back up and edit my selections and do another search. Most real-world web interfaces don't lend themselves well to use cases — only in kiddie text books, and college course examples... A few web interfaces that were built to simulate old forms-based interfaces from the IBM green-screen world do have use-case nature, and those are great for DCI.
James O. Coplien
On Sep 28, 2011, at 6:43 , rune funch wrote:
> Never said you could create a simple UC that only requires one round
> trip. We don't have any in the project I'm on but that doesn't mean
> that I could come up with one
However, few use case experts (Cockburn, Wirfs-Brock) would think of that case as being their primary target for a use-case approach. An atomic event architecture is more suitable to single-round-trip interactions. A use case is a sequence of interactions (by definition): not an interaction.
Jim Gay
That's helpful. I have more research to do.
This makes me think of the need for nested or related contexts where a
front end DCI layer in JavaScript (for example) would in some way
execute another context on the server side.
Jim Gay
If this is true, then how does DCI fit into this multi-interaction web
implementation?
In my initial thinking, I've been throwing away the context with the
request (it's done when the request is done), but this seems to
suggest otherwise.
Earlier you commented that on this (the last line being Cope):
>>> Several controllers usually take part in one use case.
>>
>> I'm very curious about this comment. Is this necessarily true? Why?
>I am curious, too, and would be very surprised to find it so.
But doesn't your above comment about web interfaces imply that several
controllers would or could take part in one use case?
Risto Välimäki
James O. Coplien
On Sep 28, 2011, at 6:59 , Jim Gay wrote:
> If this is true, then how does DCI fit into this multi-interaction web
> implementation?
Whereever there are use cases that one can describe in terms of role interactions.
> In my initial thinking, I've been throwing away the context with the
> request (it's done when the request is done), but this seems to
> suggest otherwise.
The lifetime of a Context is the lifetime of a use case.
> Earlier you commented that on this (the last line being Cope):
>
>>>> Several controllers usually take part in one use case.
>>>
>>> I'm very curious about this comment. Is this necessarily true? Why?
>> I am curious, too, and would be very surprised to find it so.
>
> But doesn't your above comment about web interfaces imply that several
> controllers would or could take part in one use case?
No. In my view the Controller is most tightly bound to the input devices and the domain objects. It is just MVC 101 that views come and go under the oversight of the Controller, and that the objects whose state is displayed by the views themselves outlive the views. Those objects map vary closely to DCI objects.
The lifetime of a Controller therefore tends to be the life of a session, which may bracket several use cases and other user inputs. Not all user inputs are well-characterized as use cases.
It is likely that the Controller instantiates Context objects. There is a unique Context class for each use case. The identify of that class in turn derives from the Controller's "parsing" of the end-user input.
There is a many-to-many-to-many... association between these objects. The only alignment between MVC and DCI that I see is that what DCI calls objects maps onto the objects whose states are observed by MVC views. Other than that, I don't see much more association that between any other two frameworks. It is probably common that the Controller instantiates Contexts, but it is equally likely that the Controller directly invokes methods on the more general (domain) objects. The latter is the atomic event architecture; the former is the DCI architecture.
James O. Coplien
What if we had Context that acted also as a form-input-checking-controller called "Controller" in typical web-MVC-frameworks?
Risto Välimäki
On Sep 28, 2011, at 6:59 , Jim Gay wrote:
> If this is true, then how does DCI fit into this multi-interaction web
> implementation?
Whereever there are use cases that one can describe in terms of role interactions.
James O. Coplien
DCI is too good hammer to be used only to Use Case nails, methinks.
Jim Gay
My understanding is that the Context should describe the Use Case in code.
I don't think it's DCI but is focusing on extending the behavior of
objects is the hammer that you like.
Risto Välimäki
Jim Gay
The way I envision the Context, in light of this, is that web requests
should be able to, in some way, resume the operation of a context.
My Context describes the code necessary for the use case, but in a web
framework each user action (and web request) would be some part of the
algorithm in the overarching context. Is that on the right track?
Or does this mean, essentially, that the web MVC that I'm used to is
inherently not DCI compatible?
Risto Välimäki
Risto Välimäki
And later also that he even sees many-to-many relationships between Use Cases and Contexts.
James O. Coplien
On Sep 28, 2011, at 9:21 , Jim Gay wrote:
> My understanding is that the Context should describe the Use Case in code. I don't think it's DCI but is focusing on extending the behavior of objects is the hammer that you like.
I don't understand your response. Can you expand or add a conceptual example?
James O. Coplien
Habit, for example. That's UC, but without business value.
And also non-interactive, non-human related actions that clearly involve communication between objects with different Roles fits Context perfectly, I think.
I had also an example of a broader Context in my mind, but I'm just now too tired to express myself meaningfully.
I guess Trygve could tell us some examples of Context that doesn't have anything to do with Use Cases.
James O. Coplien
> The way I envision the Context, in light of this, is that web requests should be able to, in some way, resume the operation of a context.
They can if they're stateful. That something is a use case doesn't say where the state is stored. It could be in a cookie, inferred from a cookie, or in the client or in the server. Use cases have nothing to do with the implementation technology. They are business behavior.
> My Context describes the code necessary for the use case, but in a web framework each user action (and web request) would be some part of the algorithm in the overarching context. Is that on the right track?
If it truly is an algorithm that can be defined in terms of a succession of states, then it can be DCI. I envision all of that happening under a single Controller unless I'm switching heads (keyboard and screen, or other HCI) in the middle of the use case.
> Or does this mean, essentially, that the web MVC that I'm used to is inherently not DCI compatible?
Not enough information to know.
Ant Kutschera
> And btw, that DCI hammer -thing was of course sarcasm, but not completely
> without a grain of truth. Whenever there is network of interacting objects
> involved, I could at least consider using Context for that.
think "use-case" and "collaboration" can be interchanged when one is
talking about what a context and its roles implement. UML2 seems to
support this too.
Ant Kutschera
"controller action" and not "controller".
Is it possible that a controller action is an instance of a class
(i.e. an object), which the framework calls when a web request comes
in, and is responsible for handling the request?
In that case, if all it would do, is pass the request to a context, I
could imagine it also being the request.
However, a context isn't normally responsible for things like parsing
parameters out of web requests. A context normally deals with
objects, not strings in a web request. So the controller action takes
the request, parses it, and puts together the relevant parts of the
object model, and passes that to a context to do the work.
Same goes fora servlet calling a service, in Java EE, if that helps.
I particularly like James discussion on separating concerns,
architecture, etc.
I would also like to turn the original question up side down: why
shouldn't a controller action and context be two objects? What is so
painful about having two objects?
I have also wondered, that if a context handles a use case, and the
use case involves several web requests coming in from the user, that
means I will need to keep the context alive and continually give it
more data, as that data is supplied to me by the user. Alternatively,
I create contexts which are lower level, based on the individual
collaborations that occur with each web request. To me, thikning in
terms of collaborations makes much more sense than big fat chunky use
cases.
James O. Coplien
On Sep 29, 2011, at 9:14 , Ant Kutschera wrote:
> I would also like to turn the original question up side down: why
> shouldn't a controller action and context be two objects? What is so
> painful about having two objects?
There is no need to reify actions, certainly not at the analysis / use case level. If you need to turn an action into a message at the low level (for the sake of a client / server architecture) that, to me, seems below the DCI abstraction layer. It's just a matter of programming using patterns like HOPP.
Cevat Serkan Balek
Use cases are crucial and user narratives are essential -to start- to have a good grasp of what the system is doing for the user. However, although the user is the king, he is only one of the stakeholders. In order for the software system function properly and adapt to new settings, the parts of the system should also be considered in the design of the object system. Extending the meaning of the user/actor and use cases is one possible solution. In fact, in order to consider the domain expert's deep knowledge, there should be deeper objects in consideration.
Let me try to clarify my point in an example application, design of secure smart card personalization system.
Let's the requirements be roughly like this:
"There are various card issuing systems, batch or instant. Although these machines differ in technology and working style (batch/instant), the very same personalization steps (i.e. algorithm) to authenticate the issuer, to use and store the customer data in the chip as the relevant standart specifies, and finally print the specified card design.
The issuer uses the system either by using a GUI for instant issuing or provide a list of cards to a batch issuing system and wait for the instant or batch issuing results. The system should isolate any kind of technical complexity related with machines from the domain expert who is proficient only in preparing card personalization specifications which conform to international standards, i.e. the same algorithm should work in a rich variety of contexts and the exceptions should be meaningful to domain experts. Technical details of machine problems should only be an illustration."
And here is the design attempt I usually take on problems like this:
Here, the user is expected only to prepare the empty cards to be personalized, use the GUI or file to choose the design to be applied and command script to be sent to smart card section of the card, start the personalization process, and waits for any kind of results. Although, the use cases for the user should be enriched to include many alternative paths for the user; for this kind of system, it is apparent that there are many system level contexts and considerations that should be taken into account in order to have a good software systems. Examples:
1. The design of the customer information and the visual part can be modeled as entity/data.
2. The script for various smart card personalisations can be modeled as RoleMethods.
3. Various smart card printer brands can be represented as various roles, each may execute the steps in the specific RoleMethod using their own capabilities. That is, a specific secure personalization steps is emboided as a high level script in a RoleMethod which is unchanging between roles. Each role (smart card printers) may have the specific means to execute each script command in the context generated by them.
Therefore, in this system, it is apparent that, in addition to use cases for only the users, we need to specify at least:
1. The role method for the algorithm for the smart card personaliztion. (with domain experts in the financial instutions)
2. The roles as the various smart card printers and capabilities of them (with domain expoers in each of the printers to be supported)
3. The various contexts which pick up the related data and roles together to perform the specific action: ie, choosen script for the choosen printer in a choosen manner (batch/instant).
Only until then, the smart card personalization system is considered of being designed laterally in systems view. IMO, this is the DCI way.
Cheers,
Cevat Balek
Trygve Reenskaug
But is this it is an example of Context that doesn't have anything to do with Use Cases? It is a question of definition. If anything can be a use case, then I am hard put to suggest a DCI example that is not a use case.
More seriously. At its heart, DCI is a programming paradigm for coding how objects interact to achieve some common purpose. In the glossary, there is this schema for system behavior:
Use Case
...Scenario
......Command
.........System Operation
There is no requirement that system operations can only be called from a use case. Whenever a programmer needs to specify the interaction between two or more objects, DCI is a candidate for the design.
Cheers
--Trygve
--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.
Trygve Reenskaug mailto: try...@ifi.uio.no
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo Tel: (+47) 22 49 57 27
Norway
James O. Coplien
I guess Trygve could tell us some examples of Context that doesn't have anything to do with Use Cases.That's a challenge. He'd probably say that it's a matter of definition.
But is this it is an example of Context that doesn't have anything to do with Use Cases? It is a question of definition.
James O. Coplien
On Sep 29, 2011, at 9:14 , Ant Kutschera wrote:
> I would also like to turn the original question up side down: why
> shouldn't a controller action and context be two objects? What is so
> painful about having two objects?
Bingo. Avoid fat controllers. You don't want 90% of your system's logic in one class.