Advice on consolidating thoughts.

680 views
Skip to first unread message

Mikey

unread,
Jun 8, 2012, 9:36:34 AM6/8/12
to object-co...@googlegroups.com
Hello all,

Ive done a mountain of reading and research, and id like to make sure i'm on the right track, all comments welcome.

Firstly, I started with "what makes quality" and what does quality mean. Ive come to the reasoning that Quality (in code) is Readability(~Understandability), Correctness and Maintainability.

There has been several methodologies and practices to achieve this. To name a few;
  • "Composition over Inheritance"
  • "Coupling and Cohesion"
  • SOLID (Single Responsibility, Open/Closed, Liskov substitution, Interface segregation and Dependency inversion)
  • GRASP Principles
  • and Design Patterns

Would i be correct in saying that there are heavy parallels to these practices and DCI?

  1. "Keeping the domains simple" would refer to Single Responsibility Principle. High Cohesion.
  2. Interface Segregation/Program to interfaces/Dependency Inversion is given with RolePlayer requirements.
  3. From what i can tell, the Behavioral "Design Patterns" may be redundant?
  4. GRASP speaks of a Use Case Controller. From what i understand in DCI, The "Controller" (MVC) is not a role, but the "DCI Context" object holding the que-cards.

Some questions;

From what i can tell, a Context is a "Perspective" on objects by the client wishing to use them. "Looking" upon the objects differently. The strategy pattern talks about a context, and GRASP also talks of a context. Are the means of Context the same from these to DCI? If not, what are the differences?

Thankyou,

Mike Brown

Mikey B

unread,
Jun 18, 2012, 6:52:54 AM6/18/12
to object-co...@googlegroups.com

The UseCaseController pattern discusses some interesting topics. implementing usecase inclusions and extensions. Generalizing usecases with inheritance and that the Controller can take two forms (facades and usecase scenario), which i feel confirms that there is two types, one which can be a roleplayer, and one which can not.

an link for those interested paginas.fe.up.pt/~aaguiar/as2003-2004/UseCaseCtrl-EuroPLoP2001.pdf

mike brown

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/vExY2enyDfIJ.
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.

Mikey

unread,
Jun 27, 2012, 2:54:22 PM6/27/12
to object-co...@googlegroups.com
Ive found some more references to the UseCaseController Pattern.

I am positive that a DCI Context = UseCaseController. 

One thing i did learn from GRASP is that the MVC Controller's responsibilities are not the same as the Context. They are separate objects. A Controller typically calls a use-case. 

UseCaseController's contain only one use-case, and so are named as the use-case (e.g. PlaceOrderUseCase), and have the "execute" method, and not use-case que-cards. If this is the correct definition for a DCI Context. Then it is impossible to have a Context be a RolePlayer.

This nesting business has been a bugbear for a long time for me. I hope I can convince people here that its time to let go of this idea.

Mike Brown.
To post to this group, send email to object-composition@googlegroups.com.
To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.

rune funch

unread,
Jun 28, 2012, 12:05:34 AM6/28/12
to object-co...@googlegroups.com
Den 27/06/2012 kl. 20.54 skrev Mikey <mike...@gmail.com>:

> This nesting business has been a bugbear for a long time for me. I hope I can convince people here that its time to let go of this idea

Have you written any code or at least read and understood the examples
on fullOO.info? Context CAN be nested I've written several examples of
that and it's in the heart of DCI. DCI implements OO as OO was
originally defined a system consisting of a network of connected
systems. Each system is represented by a context, so by definition
they can be nested. Saying otherwise is like saying an object can can
only have members of primitive (non object) types which is of course
not true

-Rune

Mikey B

unread,
Jun 28, 2012, 4:20:18 AM6/28/12
to object-co...@googlegroups.com

A system(/subsystem) is represented by a facade controller. A context represents a single system operation. OO definition is still upheld.

The responsibility of a facade controller is to ease/simplify interfacing a group of objects. The same as a subsystem.

The responsibility of a context(and UseCaseController) is to set up role bindings and manage the control flow of a usecase/operation.

Mike Brown.

> -Rune


>
> --
> 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.

James O Coplien

unread,
Jun 28, 2012, 4:43:48 AM6/28/12
to object-co...@googlegroups.com
UseCaseController (http://www.cs.sjsu.edu/~pearce/modules/courses/cs251a/reading/Aguiar_al_2001_ART_Use_Case_Controller.pdf) has almost nothing to do with DCI.

The pattern encapsulates the objects of a use case. Those objects variably use different interface components: different views and controllers. As far as I can see, the pattern is a very minor tweak on MVC — not DCI.

The control in UseCaseController is usually distributed across a number of functions global to the Use Case class. The normal strategy is exactly the opposite of DCI: that "control is placed separately from both interface and entity objects". The Use Case is described as a set of procedural steps from which actor association has been dissociated:

public class PlaceOrderUseCase extends UseCaseController {
   …
   public void start() { displayForm(); }
   public void finish() { … }
   public void displayForm() { … }
   public void setCustomerInfo(String name, String address) { … }
   public void newItem() { … }
   public void saveItem(String item) { … }
   public void deleteItem() { … }
   public void setPaymentInfo(String paymentType) { … }
   public void submitOrder() { … }
   public void cancelOrder() { … }
}

I see absolutely no notion of roles here, let alone role binding.



On Jun 28, 2012, at 10:20 , Mikey B wrote:

A system(/subsystem) is represented by a facade controller. A context represents a single system operation. OO definition is still upheld.

The responsibility of a facade controller is to ease/simplify interfacing a group of objects. The same as a subsystem.

What is a "facade controller"? The pattern mentions view facades and model facades.

The responsibility of a context(and UseCaseController) is to set up role bindings and manage the control flow of a usecase/operation.

No.

I see no roles or role bindings in UseCaseController.

A Context does not manage control flow of a use case. The role methods do.

rune funch

unread,
Jun 28, 2012, 8:30:37 AM6/28/12
to object-co...@googlegroups.com
Den 28/06/2012 kl. 10.20 skrev Mikey B <mike...@gmail.com>:
So the answer is no? You didn't write code nor investigate the Examples?
A context (which is an object) represents the (execution) of a system
operation. The life time of that object is the same as the time it
takes to complete the operation. The type of the context object might
be used for contexts that execute different system operations (it
might have more 'execute' methods)

Mikey B

unread,
Jun 29, 2012, 6:43:56 AM6/29/12
to object-co...@googlegroups.com
Hi James,

On 28 June 2012 09:43, James O Coplien <jcop...@gmail.com> wrote:
UseCaseController (http://www.cs.sjsu.edu/~pearce/modules/courses/cs251a/reading/Aguiar_al_2001_ART_Use_Case_Controller.pdf) has almost nothing to do with DCI.

The pattern encapsulates the objects of a use case. Those objects variably use different interface components: different views and controllers. As far as I can see, the pattern is a very minor tweak on MVC — not DCI.

"The Use-Case Controller pattern deals with the problem of mapping
use case specifications to an implementation"

"... Use case maps are another alternative that combines behaviour and structure
in one view and shows the allocation of scenario responsibilities to system components"

"When a use case is started, one instance of the corresponding use-case controller is created to control the flow of the interactions involved."


The control in UseCaseController is usually distributed across a number of functions global to the Use Case class. The normal strategy is exactly the opposite of DCI: that "control is placed separately from both interface and entity objects". The Use Case is described as a set of procedural steps from which actor association has been dissociated:

public class PlaceOrderUseCase extends UseCaseController {
   …
   public void start() { displayForm(); }
   public void finish() { … }
   public void displayForm() { … }
   public void setCustomerInfo(String name, String address) { … }
   public void newItem() { … }
   public void saveItem(String item) { … }
   public void deleteItem() { … }
   public void setPaymentInfo(String paymentType) { … }
   public void submitOrder() { … }
   public void cancelOrder() { … }
}


Above the code is; "The following guidelines are suggested to implement this pattern."

"behaviour must then be distributed to the interacting objects."

"Different strategies can be used to allocate the functionality to entity
objects, interface objects and control objects [7][8]. The strategy to
choose must be decided from application to application. In most
cases, the balanced strategy, where control is placed separately from
both interface and entity objects, is the one that reaches higher 
locality in changes of the functionality."

 
I see absolutely no notion of roles here, let alone role binding.



On Jun 28, 2012, at 10:20 , Mikey B wrote:

A system(/subsystem) is represented by a facade controller. A context represents a single system operation. OO definition is still upheld.

The responsibility of a facade controller is to ease/simplify interfacing a group of objects. The same as a subsystem.

What is a "facade controller"? The pattern mentions view facades and model facades.


"The Use-Case Controller pattern defines five types of participants: UseCaseController, View, Model, Extension and Inclusion."

"All participating classes can be divided at least in two groups: a model,
aggregating all entity objects; and views, which aggregate interface
objects"

Views and Models are considered categories of types of "facades". view facades and model facades are interfaces to Entity objects and Interface Objects, and only exist for the lifetime of the use-case.
 

The responsibility of a context(and UseCaseController) is to set up role bindings and manage the control flow of a usecase/operation.

No. 

I see no roles or role bindings in UseCaseController.

A Context does not manage control flow of a use case. The role methods do.

"The Use-Case Controller pattern provides the following benefits:
• Localization of business rules and policies.
• Easy replacement of user interfaces and system components. 
• Visibility of the originating use case model in the implementation code."
 

All of the quotes above are from the document in your reply. Here is an updated version: http://paginas.fe.up.pt/~aaguiar/as2003-2004/UseCaseCtrl-EuroPLoP2001.pdf

Mike Brown

Mikey B

unread,
Jun 29, 2012, 6:55:14 AM6/29/12
to object-co...@googlegroups.com
Hi Rune,

On 28 June 2012 13:30, rune funch <funchs...@gmail.com> wrote:
Den 28/06/2012 kl. 10.20 skrev Mikey B <mike...@gmail.com>:
So the answer is no? You didn't write code nor investigate the Examples?
A context (which is an object) represents the (execution) of a system
operation. The life time of that object is the same as the time it
takes to complete the operation.

Agreed, But the context will never represent a Domain Object. Domain Objects play roles within a Context. 
 
The type of the context object might
be used for contexts that execute different system operations (it
might have more 'execute' methods)

Quote from Artima:
"Nested Contexts

One can imagine building rich Context objects that define whole subgraphs of self-contained role relationships: relationships so stable that they constitute a kind of domain in their own right. If these Context objects have a small number of public methods they can behave like domain objects."

Context Nesting hinges on this definition which I disagree with. It is an exception, not the rule, to have more than one "execute" methods. A context represents one (execution) of a system operation. Domain Objects are always represented by a class, which in turn calls the Use-Case.

The UseCaseController document in this thread discusses inclusions (another use-case is called), extensions (hooks are provided by the use-case), and generalisations (inheritance).

Mike Brown

James O Coplien

unread,
Jun 29, 2012, 7:25:06 AM6/29/12
to object-co...@googlegroups.com
On Jun 29, 2012, at 12:43 , Mikey B wrote:

Hi James,

On 28 June 2012 09:43, James O Coplien <jcop...@gmail.com> wrote:
UseCaseController (http://www.cs.sjsu.edu/~pearce/modules/courses/cs251a/reading/Aguiar_al_2001_ART_Use_Case_Controller.pdf) has almost nothing to do with DCI.

The pattern encapsulates the objects of a use case. Those objects variably use different interface components: different views and controllers. As far as I can see, the pattern is a very minor tweak on MVC — not DCI.

"The Use-Case Controller pattern deals with the problem of mapping
use case specifications to an implementation"

"... Use case maps are another alternative that combines behaviour and structure
in one view and shows the allocation of scenario responsibilities to system components"

"When a use case is started, one instance of the corresponding use-case controller is created to control the flow of the interactions involved."

Yes, so what? Patterns are about form. If you look at the form described by the pattern, the Use Case is one big, undifferentiated lump. There is no structure inside of it. (DCI is about the structure *inside* the use case). The form of the pattern is about its connection to the MVC constituent parts. Yes: there are use cases in there, but they don't figure in any serious way in the overall form of the pattern.



The control in UseCaseController is usually distributed across a number of functions global to the Use Case class. The normal strategy is exactly the opposite of DCI: that "control is placed separately from both interface and entity objects". The Use Case is described as a set of procedural steps from which actor association has been dissociated:

public class PlaceOrderUseCase extends UseCaseController {
   …
   public void start() { displayForm(); }
   public void finish() { … }
   public void displayForm() { … }
   public void setCustomerInfo(String name, String address) { … }
   public void newItem() { … }
   public void saveItem(String item) { … }
   public void deleteItem() { … }
   public void setPaymentInfo(String paymentType) { … }
   public void submitOrder() { … }
   public void cancelOrder() { … }
}


Above the code is; "The following guidelines are suggested to implement this pattern."

"behaviour must then be distributed to the interacting objects."

Right: through the classes that implement them. There is no discussion of roles or anything like it.


"Different strategies can be used to allocate the functionality to entity
objects, interface objects and control objects [7][8]. The strategy to
choose must be decided from application to application. In most
cases, the balanced strategy, where control is placed separately from
both interface and entity objects, is the one that reaches higher 
locality in changes of the functionality."

Read: "In most cases", functionality goes into domain classes.

James O Coplien

unread,
Jun 29, 2012, 7:29:10 AM6/29/12
to object-co...@googlegroups.com

On Jun 29, 2012, at 12:55 , Mikey B wrote:

But the context will never represent a Domain Object


Sure it does, all the time (for some strange definition of "domain object" — I'm not sure what you mean). A SavingsAccount can, for example, be represented as a Context: a collection of scenarios. Can't its instance be a domain object that in fact can play the role of, say, a SourceAccount, in another Context like MoneyTransfer?

James O Coplien

unread,
Jun 29, 2012, 7:30:30 AM6/29/12
to object-co...@googlegroups.com
On Jun 29, 2012, at 12:55 , Mikey B wrote:

The UseCaseController document in this thread discusses inclusions (another use-case is called), extensions (hooks are provided by the use-case), and generalisations (inheritance).

Both DCI and UseCaseController chain use cases. That both a cat and a horse have four legs doesn't make a cat a horse.

rune funch

unread,
Jun 29, 2012, 7:40:13 AM6/29/12
to object-co...@googlegroups.com
Den 29/06/2012 kl. 12.55 skrev Mikey B <mike...@gmail.com>:

> context will never represent a Domain Object

To be able to even discus that we would have to agree on a definition
of "Domain object" or are we talking a data object?

my definition is:
either a simple type or a collection of simple types.
The domain object is responsible for ensuring it's own invariants and
have no behaviour aside from this

Where 'simple type' is defined a primitive for the chosen platform. Ie
usually numbers, strings and booleans.

If that's the definition the I surely agree that by definition a
context can't represent such an object and that such an object would
by definition always be represented by data.

Accepting that definition you will see nested contexts in a lot more
places than you might expect because then you will see a context
anywhere two objects interact and you will end up with a system that
is the perfect realisation of Kay's recursive definition of OO systems

Mikey B

unread,
Jun 30, 2012, 5:52:55 AM6/30/12
to object-co...@googlegroups.com
Hi James and Rune,

Ive put your replies together;

Domain object is the term used in the Artima article, and is in the quote in the previous message. I believe it means Data Object.

No, I do not believe a SavingsAccount is a Context. 

On 29 June 2012 12:40, rune funch <funchs...@gmail.com> wrote:
Den 29/06/2012 kl. 12.55 skrev Mikey B <mike...@gmail.com>:

> context will never represent a Domain Object

To be able to even discus that we would have to agree on a definition
of "Domain object" or are we talking a data object?

my definition is:
either a simple type or a collection of simple types.
The domain object is responsible for ensuring it's own invariants and
have no behaviour aside from this

Where 'simple type' is defined a primitive for the chosen platform. Ie
usually numbers, strings and booleans.

If that's the definition the I surely agree that by definition a
context can't represent such an object and that such an object would
by definition always be represented by data.


The underline reason for this thread is to point out that there is value to be had from GRASP and the UseCaseController Pattern.

The term 'Data Object' maybe too vague;

The UseCaseController Pattern describes 3 categories of Objects that can interact in a Use Case. Beside them is the Use Case stereotype name.

Interface Objects - «boundary» - Communication with Actors
Entity Objects -  «entity» - Persistent Data
Control Objects - «control»

These are all defined as classes. They are able to play roles within a use-case. There are only three categories of roles in a use-case; Model Role, View Role and Controller Role.

I suspect a Control Object represents a System / Subsystem in your design. 
 
Accepting that definition you will see nested contexts in a lot more
places than you might expect because then you will see a context
anywhere two objects interact and you will end up with a system that
is the perfect realisation of Kay's recursive definition of OO systems

The devil is in the detail, and I can only reference the definition of a Nested Context as quoted from Artima.

If a Control Object represents a subsystem, and a Nested Context represents a "subgraph", It should be clear that in order for Nesting to be possible, The Context object is taking on responsibilities of the Control Object.

The whole point of DCI is clearer and understandable code.

Having multiple Use-Cases in one Context produces code smells; My code begins to differ from its design, producing a barrier to reviewers. It stops (or inheritance has been substituted by "multiple use-case contexts") the possibility of Context Inheritance which represents a Use-Case Generalisation. 

Another quote from Artima, "The Controller creates Views and coordinates Views and Models".

If the Context is taking on the responsibilities of the Control Object. There is an issue here. How do you create a View? Who looks after its address/pointer? A context only lives until the end of its execution. A context should not take on the responsibilities of a Control Object. It therefore can not play a "Controller Role" (or "Model" or "View" role). It therefore can not be a Role Player.

The definition(by the artima article) of a "Nested Context" is that a Context can be a Role Player. 

Lets use the terms that use-case's use, and model them accurately in our code. Naming of a Context becomes trivial, its just the name of the Use-Case.

(Use-Case) Generalisations - via Inheritance.
(Use-Case) Extensions and (Use-Case) Inclusions - via hooks.

Thankyou for your time,
Mike Brown

James O Coplien

unread,
Jun 30, 2012, 6:30:28 AM6/30/12
to object-co...@googlegroups.com

On Jun 30, 2012, at 11:52 , Mikey B wrote:

No, I do not believe a SavingsAccount is a Context.

It certainly is. The common misperception, promulgated by undergraduate CS professors everywhere, that SavingsAccount is a class that encapsulates a data item called a "balance," is at odds with most real banking systems. A SavingsAccount balance is a computation over a series of transaction log items — a use case. Doing a Deposit is a database transaction with an elaborate set of steps — a different trigger function on the account.

Context-ness is in the eyes of the beholder. If you are a simple CS Professor, then it's not. If you program for a living, then it is.

Mikey B

unread,
Jun 30, 2012, 7:22:34 AM6/30/12
to object-co...@googlegroups.com
Hi James,

On 30 June 2012 11:30, James O Coplien <jcop...@gmail.com> wrote:

On Jun 30, 2012, at 11:52 , Mikey B wrote:

No, I do not believe a SavingsAccount is a Context.

It certainly is. The common misperception, promulgated by undergraduate CS professors everywhere, that SavingsAccount is a class that encapsulates a data item called a "balance," is at odds with most real banking systems. A SavingsAccount balance is a computation over a series of transaction log items — a use case. Doing a Deposit is a database transaction with an elaborate set of steps — a different trigger function on the account.


A SavingsAccount is not a Context, The reasons why are listed in the previous post.

A SavingsAccount is a Control Object, created by a class.

For your example of a balance, The SavingsAccount would execute the context (CalculateBalance), 

class SavingsAccount
  balance: () ->
    tmp = new CalculateBalance(..roleplayers..)
    Result = tmp.execute(...params...)
    delete tmp
    return Result

context CalculateBalance
   ... Contents of CalculateBalance use-case.

Your mixing the responsibilities of a Controller with a Context.

Mike Brown.

 
Context-ness is in the eyes of the beholder. If you are a simple CS Professor, then it's not. If you program for a living, then it is.

--

James O Coplien

unread,
Jun 30, 2012, 8:09:19 AM6/30/12
to object-co...@googlegroups.com
On Jun 30, 2012, at 1:22 , Mikey B wrote:

A SavingsAccount is not a Context, The reasons why are listed in the previous post.

I found your reasons ill-grounded.

A SavingsAccount is a Control Object, created by a class.

Huh?

There is no notion of Model View Controller here so I'm not sure why you're bringing up Control Object.

Classes do not create objects.

For your example of a balance, The SavingsAccount would execute the context (CalculateBalance), 

class SavingsAccount
  balance: () ->
    tmp = new CalculateBalance(..roleplayers..)
    Result = tmp.execute(...params...)
    delete tmp
    return Result

context CalculateBalance
   ... Contents of CalculateBalance use-case.

All that does is to add another level of function nesting. There is no advantage for encapsulating change. There is no advantage to this abstraction layer. It is merely a blind, pro-forma walk along the path of old-style object-orientation — off a cliff.

What are the roles of CalculateBalance? And what objects play those roles? List them. Sounds like a SavingsAccount to me.

Your mixing the responsibilities of a Controller with a Context.

First, I'm not. There are no Contexts in the UseCasePattern.

Second, the job of a Controller is to create an coordinate Views and, together with the View, handle selection. None of my description of a SavingsAccount had anything to do with selection of MVC.

Third, even if I were, why shouldn't I? These are two different spaces.

Mikey B

unread,
Jun 30, 2012, 8:54:59 AM6/30/12
to object-co...@googlegroups.com
Hi James,

On 30 June 2012 13:09, James O Coplien <jcop...@gmail.com> wrote:

On Jun 30, 2012, at 1:22 , Mikey B wrote:

A SavingsAccount is not a Context, The reasons why are listed in the previous post.

I found your reasons ill-grounded.

A SavingsAccount is a Control Object, created by a class.

Huh?

There is no notion of Model View Controller here so I'm not sure why you're bringing up Control Object.

A "Control" object is a Use-Case Stereotype, classifying the object.
 

Classes do not create objects.

For your example of a balance, The SavingsAccount would execute the context (CalculateBalance), 

class SavingsAccount
  balance: () ->
    tmp = new CalculateBalance(..roleplayers..)
    Result = tmp.execute(...params...)
    delete tmp
    return Result

context CalculateBalance
   ... Contents of CalculateBalance use-case.

All that does is to add another level of function nesting. There is no advantage for encapsulating change. There is no advantage to this abstraction layer. It is merely a blind, pro-forma walk along the path of old-style object-orientation — off a cliff.

The advantage is that the code now mirrors my design, System operations are not entangled together, both promoting clarity.

The only relevance with MVC is understanding that the (use-case stereotype)Control object is the keeper of the Interface objects(Objects which communicate with an Actor). (MVC)"Controller" is a role, and can not have state, The (Use-case stereotype)Control object holds this state.


What are the roles of CalculateBalance? And what objects play those roles? List them. Sounds like a SavingsAccount to me.

Your mixing the responsibilities of a Controller with a Context.

First, I'm not. There are no Contexts in the UseCasePattern.

Second, the job of a Controller is to create an coordinate Views and, together with the View, handle selection. None of my description of a SavingsAccount had anything to do with selection of MVC. 

Third, even if I were, why shouldn't I? These are two different spaces.

You said in the previous section of this post that im just "adding another level". This is the layer that you are combining into your Contexts, Combining the responsibilities of your (use-case stereotype)Control object with your Context.

While a SavingsAccount does not require Interface objects and "View" roles, separation of the responsibilities is always worth upholding.

A (Use-Case Stereotype)Control object represents the System(/subsystem). A Context represents a system operation. They should not be mixed.

Mike Brown

rune funch

unread,
Jun 30, 2012, 10:34:24 AM6/30/12
to object-co...@googlegroups.com
> The advantage is that the code now mirrors my design, System operations are not entangled together, both promoting clarity
it's not the goal to mirror the design but to mirror the users mental
model of the _problem_ domain which your design does not. Therefor
it's implicitly the goal not to mirror the design because the design
it self fails to meet the stated goal of mirroring the users mental
model

rune funch

unread,
Jun 30, 2012, 10:36:42 AM6/30/12
to object-co...@googlegroups.com
Den 30/06/2012 kl. 11.52 skrev Mikey B <mike...@gmail.com>:

> Domain object is the term used in the Artima article

The term is however not defined in said article so for us to be able
to debate we'd still need to agree on a definition if we do not
already agree on the one I proposed

James O Coplien

unread,
Jun 30, 2012, 11:37:37 AM6/30/12
to object-co...@googlegroups.com
On Jun 30, 2012, at 2:54 , Mikey B wrote:

A "Control" object is a Use-Case Stereotype, classifying the object.


Classes do not create objects.

For your example of a balance, The SavingsAccount would execute the context (CalculateBalance), 

class SavingsAccount
  balance: () ->
    tmp = new CalculateBalance(..roleplayers..)
    Result = tmp.execute(...params...)
    delete tmp
    return Result

context CalculateBalance
   ... Contents of CalculateBalance use-case.

All that does is to add another level of function nesting. There is no advantage for encapsulating change. There is no advantage to this abstraction layer. It is merely a blind, pro-forma walk along the path of old-style object-orientation — off a cliff.

The advantage is that the code now mirrors my design, System operations are not entangled together, both promoting clarity.

You would have the same by removing one level of calling. Furthermore, you'd have all the stuff for one use case in one place. You risk splitting it across SavingsAccounts and a Context.

The only relevance with MVC is understanding that the (use-case stereotype)Control object is the keeper of the Interface objects(Objects which communicate with an Actor). (MVC)"Controller" is a role, and can not have state, The (Use-case stereotype)Control object holds this state.


What are the roles of CalculateBalance? And what objects play those roles? List them. Sounds like a SavingsAccount to me.

Your mixing the responsibilities of a Controller with a Context.

First, I'm not. There are no Contexts in the UseCasePattern.

Second, the job of a Controller is to create an coordinate Views and, together with the View, handle selection. None of my description of a SavingsAccount had anything to do with selection of MVC. 

Third, even if I were, why shouldn't I? These are two different spaces.

You said in the previous section of this post that im just "adding another level". This is the layer that you are combining into your Contexts, Combining the responsibilities of your (use-case stereotype)Control object with your Context.

No, your example clarifies nothing about any interaction with a View or other MVC entity. It is just a superfluous instantiation, assignment, invocation and deallocation that add no clarity to the semantics. They obfuscate functionality by burying it in unnecessary boilerplate. I can't see that the code accomplishes no constructive separation of concerns.

Can you point concretely to the code and tell me what concerns you separate between the class and the Context? It seems that instead of separating them you have made them hopelessly coupled.
 

While a SavingsAccount does not require Interface objects and "View" roles, separation of the responsibilities is always worth upholding.

Why didn't you mention the file system, the keyboard, the hardware diagnostics and the RS232 driver? You're dragging stuff into this that is way out of scope and then patting yourself on the back for separating it back out again.


A (Use-Case Stereotype)Control object represents the System(/subsystem). A Context represents a system operation. They should not be mixed.

And why not?

They need not be the same but I see no reason that they could not be the same.

Mike Brown

Mikey B

unread,
Jun 30, 2012, 12:46:15 PM6/30/12
to object-co...@googlegroups.com
Hi rune,

It maybe the goal of DCI to mirror users mental model, but it is an advantage if I provide a model that mirrors my use-cases.

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

Mikey B

unread,
Jun 30, 2012, 1:04:57 PM6/30/12
to object-co...@googlegroups.com
Hi Rune,

Im happy to debate; - Your definition is close, but I feel it should note that there exists two other types of objects. The terms Control, Entity, and Interface are part of the UML definitions and are Jacobsons terms.

James O Coplien

unread,
Jun 30, 2012, 1:03:59 PM6/30/12
to object-co...@googlegroups.com
On Jun 30, 2012, at 6:46 , Mikey B wrote:

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

No. No. Those are not part of the end user mental model. They are administrative formalisms designed to force-fit mental models of procedural behavior into an class-based subtyping model. It kind of goes against everything that DCI stands for.

These original provisions of use cases, from Ivar Jacobsson, tried to create a formal object model for scenarios. In the end no one really understood it (except maybe the students of Jacobsson who invented it) and I haven't seen anyone use it. Almost everyone who uses use cases uses either the Cockburn variant or the Wirfs-Brock variant.

This stuff with generalizations, inclusions, extensions and so forth just doesn't work, and I've never heard it brought up in any discussion of DCI — until now.

The omission is with good reason.

Mikey B

unread,
Jun 30, 2012, 1:35:21 PM6/30/12
to object-co...@googlegroups.com
Hi james,

On 30 June 2012 18:03, James O Coplien <jcop...@gmail.com> wrote:
On Jun 30, 2012, at 6:46 , Mikey B wrote:

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

No.

If you would like to debate with Me and Rune on the definition of Domain object, then by all means. You did write after all.
 
No. Those are not part of the end user mental model. They are administrative formalisms designed to force-fit mental models of procedural behavior into an class-based subtyping model. It kind of goes against everything that DCI stands for.

These original provisions of use cases, from Ivar Jacobsson, tried to create a formal object model for scenarios. In the end no one really understood it (except maybe the students of Jacobsson who invented it) and I haven't seen anyone use it. Almost everyone who uses use cases uses either the Cockburn variant or the Wirfs-Brock variant.

This stuff with generalizations, inclusions, extensions and so forth just doesn't work, and I've never heard it brought up in any discussion of DCI — until now.


That's not true, Im certainly not the first to bring up the possibility of inheritance with Contexts.

If your personal experience of generalizations, inclusions, and extensions is poor then so be it. You are free to code in what ever way you want, but you are teaching people. These things are discussed in Use-Case books, People learn and use these things, you can not assume they wont from your personal preference.
 
The omission is with good reason.

--

James O Coplien

unread,
Jun 30, 2012, 1:41:08 PM6/30/12
to object-co...@googlegroups.com
On Jun 30, 2012, at 7:35 , Mikey B wrote:

Hi james,

On 30 June 2012 18:03, James O Coplien <jcop...@gmail.com> wrote:
On Jun 30, 2012, at 6:46 , Mikey B wrote:

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

No.

If you would like to debate with Me and Rune on the definition of Domain object, then by all means. You did write after all.

I'm with Rune here. Can you clarify why you disagree with him?


No. Those are not part of the end user mental model. They are administrative formalisms designed to force-fit mental models of procedural behavior into an class-based subtyping model. It kind of goes against everything that DCI stands for.

These original provisions of use cases, from Ivar Jacobsson, tried to create a formal object model for scenarios. In the end no one really understood it (except maybe the students of Jacobsson who invented it) and I haven't seen anyone use it. Almost everyone who uses use cases uses either the Cockburn variant or the Wirfs-Brock variant.

This stuff with generalizations, inclusions, extensions and so forth just doesn't work, and I've never heard it brought up in any discussion of DCI — until now.


That's not true, Im certainly not the first to bring up the possibility of inheritance with Contexts.

Inheritance of Contexts (probably a bad idea) is neither sufficient nor necessary for any of the Jacobsson use case relationships.

None of the Jacobsson use case relationships are either sufficient nor necessary to use case inheritance.


If your personal experience of generalizations, inclusions, and extensions is poor then so be it. You are free to code in what ever way you want, but you are teaching people. These things are discussed in Use-Case books, People learn and use these things, you can not assume they wont from your personal preference.

Show me one use case book other than Jacobsson that discusses them. I can show you two that don't (Wirfs-Brock's and Alistair's).

I work with dozens of organizations and can tell you that I have yet to see anyone using the Jacobsson variant. One organization claimed to, but they were so lost that they actually weren't.

My wife Gertrud is an expert on use cases and has worked in that area for more than ten years, and she is of the same mind.

Again: The omission is with good reason.

Mikey B

unread,
Jun 30, 2012, 2:50:34 PM6/30/12
to object-co...@googlegroups.com
On 30 June 2012 18:41, James O Coplien <jcop...@gmail.com> wrote:

On Jun 30, 2012, at 7:35 , Mikey B wrote:

Hi james,

On 30 June 2012 18:03, James O Coplien <jcop...@gmail.com> wrote:
On Jun 30, 2012, at 6:46 , Mikey B wrote:

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

No.

If you would like to debate with Me and Rune on the definition of Domain object, then by all means. You did write after all.

I'm with Rune here. Can you clarify why you disagree with him?
 

No. Those are not part of the end user mental model. They are administrative formalisms designed to force-fit mental models of procedural behavior into an class-based subtyping model. It kind of goes against everything that DCI stands for.

These original provisions of use cases, from Ivar Jacobsson, tried to create a formal object model for scenarios. In the end no one really understood it (except maybe the students of Jacobsson who invented it) and I haven't seen anyone use it. Almost everyone who uses use cases uses either the Cockburn variant or the Wirfs-Brock variant.

This stuff with generalizations, inclusions, extensions and so forth just doesn't work, and I've never heard it brought up in any discussion of DCI — until now.


That's not true, Im certainly not the first to bring up the possibility of inheritance with Contexts.

Inheritance of Contexts (probably a bad idea) is neither sufficient nor necessary for any of the Jacobsson use case relationships.

None of the Jacobsson use case relationships are either sufficient nor necessary to use case inheritance.


You do know that inheritance represents the "Generalisation Relationship" right? Which, yes, is one of the relationships use-cases can have.
 

If your personal experience of generalizations, inclusions, and extensions is poor then so be it. You are free to code in what ever way you want, but you are teaching people. These things are discussed in Use-Case books, People learn and use these things, you can not assume they wont from your personal preference.

Show me one use case book other than Jacobsson that discusses them. I can show you two that don't (Wirfs-Brock's and Alistair's).


Writing Effective Use Cases - Alistair Cockburn, (Page 233-241) has a whole section on Includes, Extends, and Generalisations.

I suspect you can't even have the Extends relationship when placing Use-Cases together in one Context. The hook bindings must be set up by the Control object.
 
I work with dozens of organizations and can tell you that I have yet to see anyone using the Jacobsson variant. One organization claimed to, but they were so lost that they actually weren't.

My wife Gertrud is an expert on use cases and has worked in that area for more than ten years, and she is of the same mind.

Again: The omission is with good reason.


Your experience of never using "Extends" or "Generalisation" relationships between Use-Cases does not mean no-one uses them.

James O Coplien

unread,
Jun 30, 2012, 3:59:58 PM6/30/12
to object-co...@googlegroups.com
On Jun 30, 2012, at 8:50 , Mikey B wrote:

You do know that inheritance represents the "Generalisation Relationship" right? Which, yes, is one of the relationships use-cases can have.

No, again. Inheritance is neither sufficient nor necessary for generalization. Generalization is neither sufficient nor necessary for inheritance.

See Meyer ("Object-Oriented Software Construction," Second Edition 1997), Sec. 24.5, p 822, where he lists 10 different semantics of inheritance: Subtyping, view, restriction (the flip side of generalization), extension, functional variation, type variation, reification, structure, implementation, and facility. That one uses inheritance does not imply generalization.

On the other hand consider the generalized C++ is_less_than function:

template <class T>
void *is_less_than(const T&a, const T&b) {
       return a < b;
}

Thus one expresses generalization of function in C++. Note that there is no inheritance.

Generalization can also be achieved through reflection. DCI generalizes use cases through a weak form of reflection based on deferred binding of objects to roles. There is no inheritance there.

Generalization can also be implemented through delegation, with the delegate representing the specialization. Jim Gay writes elegantly about the use of delegation in his Clean Ruby book.

And here is an interesting use of inheritance in C++:

template <class T>
class List {
public:
void push_tail(const T& element);
void push_head(const T& element);
void *has(const T& element);
void remove(const T& element);
. . . .
};

template <class T>
class Set: private List<T> {
public:
void add(const T&element) {
if (!has(element)) push_tail(element);
}
using List<T>::has;
using List<T>::remove;
};

Would you deduce, on the basis of your claim above, that Lists are a generalization of Sets?

Mike, I think you are missing a much larger context here and I'm not sure how to get it to you through Email. Most of these concepts are familiar to CS undergraduates. Perhaps you're an autodidact programmer who can code and who has picked up some concepts but who never had the grounding in the underlying theory. I don't know. But I am concerned that many of the stake-in-the-ground claims you make here can't be substantiated in the basic OO canon. And I don't think we can do a full undergraduate course in Computer Science through this group.

I have been trying to help you in a Socratic way, posing clarifying questions, but you seem to avoid answering them rather than rising to the challenge. Let's start with these:

On Jun 30, 2012, at 7:41 , James O Coplien wrote:

If you would like to debate with Me and Rune on the definition of Domain object, then by all means. You did write after all.

I'm with Rune here. Can you clarify why you disagree with him?

On Jun 30, 2012, at 5:37 , James O Coplien wrote:

Can you point concretely to the code and tell me what concerns you separate between the class and the Context? It seems that instead of separating them you have made them hopelessly coupled.

On Jun 30, 2012, at 5:37 , James O Coplien wrote:

While a SavingsAccount does not require Interface objects and "View" roles, separation of the responsibilities is always worth upholding.

Why didn't you mention the file system, the keyboard, the hardware diagnostics and the RS232 driver? You're dragging stuff into this that is way out of scope and then patting yourself on the back for separating it back out again.
On Jun 30, 2012, at 5:37 , James O Coplien wrote:

A (Use-Case Stereotype)Control object represents the System(/subsystem). A Context represents a system operation. They should not be mixed.

And why not?

On Jun 30, 2012, at 2:09 , James O Coplien wrote:

What are the roles of CalculateBalance? And what objects play those roles? List them. Sounds like a SavingsAccount to me.

If you would like a "discussion" about definitions or anything else, it would help me if you did the courtesy of engaging in dialog instead of taking the conversation in the direction of some new point on every exchange. You have not addressed yourself to any of the following questions but have, at each turn, made another stake-in-the-ground claim of truth — each one of which has been easy to deconstruct.

I appreciate that you used at least one code example and that you are starting to cite references. But I find most of the argumentation to be based not in these citations but in the unsubstantiated claims — the citations tend to substantiate issues peripheral to the discussion. Let me suggest that you try to either back your core arguments from the literature or at least develop a strong argument for your points. Just saying that "inheritance represents the Generalization Relationship" isn't going to do it for me. Please use crisp words ("system" and "subsystem" can mean anything) or use some other rhetorical device to precisely contextualize your expression.

And — focus. Stick with the thread and please try to thoughtfully respond. There are a lot of people here taking a lot of their time to help you understand. Please honor their contribution and effort by thoughtfully engaging in the dialog. Too often it feels like I'm in a parallel monologue, in spite of best efforts to precisely address your points.

rune funch

unread,
Jul 1, 2012, 2:06:35 AM7/1/12
to object-co...@googlegroups.com
Den 30/06/2012 kl. 19.04 skrev Mikey B <mike...@gmail.com>:

> Your definition is close, but I feel it should note that there exists two other types of objects.

There's a plethora of other types of objects but I don't see how they
are relevant to the definition of a specific type of objects

rune funch

unread,
Jul 1, 2012, 2:18:14 AM7/1/12
to object-co...@googlegroups.com
Den 30/06/2012 kl. 18.46 skrev Mikey B <mike...@gmail.com>:

> It maybe the goal of DCI to mirror users mental model, but it is an advantage if I provide a model that mirrors my use-cases.

If your USE cases do not mirror your users mental model you have a
sever requirement specification issue. Use cases belong in the problem
domain. They are not a design tool but input to the design phase.
Making the common error of mixing the solution domain and problem
domain when writing use cases will constrain the design process to a
point where it can impact the quality of the product let alone lead to
expensive errors and rework when the assumption the solution was based
on fall a part.
I do workshops on this for my customers so it could easily turn into a
use case discussion instead but that's not what this list is for so
let's stick with the DCI aspects. DCI tries to mirror the users mental
model in the code and an underlying assumption is that the
documentation of the users mental model (eg requirements and more) is
present and that this information is carried through from requirements
to code and not altered nor permutated in the design phase.

rune funch

unread,
Jul 1, 2012, 2:21:31 AM7/1/12
to object-co...@googlegroups.com
Den 30/06/2012 kl. 14.55 skrev Mikey B <mike...@gmail.com>:

> A Context represents a system operation

More than that it represents the network of objects and how they
interact to perform a system operation. And as such it represents a
system and performs the operation for said system

rune funch

unread,
Jul 1, 2012, 2:26:42 AM7/1/12
to object-co...@googlegroups.com
Den 30/06/2012 kl. 11.52 skrev Mikey B <mike...@gmail.com>:

> No, I do not believe a SavingsAccount is a Context.

Then please look at the Marvin version of the MoneyTransfer example,
specifically look at the Account class and tell me what principles
that class violates so that objects of that type do not represent a
network of connected objects (ledger entries) and the interactions
they are part of so that they can perform a system operation
(withdrawal, deposit or balance).

-Rune

david Rozenberg

unread,
Jul 1, 2012, 7:25:51 AM7/1/12
to object-co...@googlegroups.com
I think that we need to stop using the MoneyTransfer example as the means of illustrating DCI principles. I am personally not comfortable with it from the very first time it was brought to life in the posting at www.artima.com. And the reason is now obvious for me. It does not fit into my mental model for this specific interaction.
My mental model is to some extent service oriented (as for most people). Yes, it uses the context to select a role player (i.e. a bank for money transfer), but as soon as the role player is selected, why should I really care how the service is implemented? I believe it is the common way most people deal with their everyday needs. So, why do we need a different approach? Why do we need to sneak into how the service is implemented by the service provider we choose?
I think that all debates and strong words in them over the past couple weeks or so are exactly the result of the differences in what the actual mental model is and what is suggested as the one.
It seems to me that we may need to find a better example to make sure that it fits not in what we claim is the user mental model, but what it is for most of people.
Thanks,


From: rune funch <funchs...@gmail.com>
To: "object-co...@googlegroups.com" <object-co...@googlegroups.com>
Sent: Sunday, July 1, 2012 2:26 AM
Subject: Re: Advice on consolidating thoughts.
--
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-composition+unsub...@googlegroups.com.

James O Coplien

unread,
Jul 1, 2012, 7:37:18 AM7/1/12
to object-co...@googlegroups.com

On Jul 1, 2012, at 1:25 , david Rozenberg wrote:

It seems to me that we may need to find a better example to make sure that it fits not in what we claim is the user mental model, but what it is for most of people.


We await your example and its code.

rune funch

unread,
Jul 1, 2012, 8:05:57 AM7/1/12
to object-co...@googlegroups.com
I'd love to have an even better example but have yet not stumbled upon one.

An application is in general nothing but a promise of performing a service for the user, does that then mean we should only implement services and force the user to think of services?

I think most people they have a model of banking involving accounts and operations in relation to those accounts. I like at least one aspect of the money transfer example which is it's ability to show how to service multiple user mental model. Towards average Joe I can talk about accounts and operations in relation to accounts but since that's just one view on the data I can at the same time, with no additional work talk about ledger entries when I'm dealing with the audit side of the business.
What I've gotten from this and other discussion of examples and especially when talking about nested contexts is a lack of realisation. Going from class oriented to DCI requires two mental leaps each of which are rather challenging. Firstly we need to realise that the earth is a sphere and not a pancake and then realise what that implies on how we have been perceiving everything around us. When learning DCI we at some point have to leap into object oriented from class oriented and once we accept the earth is a sphere we need to realise that everything we thought we knew might have suddenly and inadvertently changed. 
An object is a model and as every model it's an abstraction of the real thing. No model is perfect and the best suited model changes depending upon the context in which we need the model.
In class oriented and DDD we try to create the perfect model and then apply magic on top to match the current situation.
In DCI we start with what does not change depending on the context of usage, namely the data and we model the "real thing" based on the context. So if the use case is auditing the transactions within a bank we model ledger entries where as if the use case is showing the balance we model the account. The data is the same in both but the object we talk about are different objects. A third model upon the same data is used for the trading floor guys. They need to know how much they can invested which is in part determine by the balance of every account in the bank.
Each of these models might serve as a building block for another model and the second leap from object oriented to DCI is realising that each model in a user model does not need to be on the same level of abstraction

-Rune
To unsubscribe from this group, send email to object-composit...@googlegroups.com.

James O Coplien

unread,
Jul 1, 2012, 8:27:32 AM7/1/12
to object-co...@googlegroups.com
Right. There is no "single right example" for bank accounts. You need to look at it from the perspective of the end user and the psychometric studies or analyses that support the model — not from CS taxonomies.

It is even possible that the model for transfer will differ when interacting with a live teller than with an ATM. I don't know — I haven't done the research. But such research is important, as HCI people know — and, unfortunately, most of us OO people don't know.

Mikey B

unread,
Jul 2, 2012, 5:22:15 AM7/2/12
to object-co...@googlegroups.com

Hi david, rune, james and anyone else interested.

I think the bank account example is good enough to illustrate my point, so lets take the mental model given of the interactions from artima as a common starting point and lets do a small thought exercise;

You, the programmer will seperate the concerns using MVC. This provides you with three types of roles; Model Roles, View Roles, and Controller roles. (and also states how each role is wired to eachother).

Your bank account is represented as a Context; Which type of role can a bank account play? State which you think and why.

--

Model - the object playing a model role requires persistance, it must atleast hold the pointers to other objects with state. A context only exists for the duration of its execution.

Controller - Also requires state, to hold pointers to Views

View - a bank account does not represent communications with actors.

Mike Brown

rune funch

unread,
Jul 2, 2012, 5:38:26 AM7/2/12
to object-co...@googlegroups.com
Let's start with answering the questions already part of this thread I have posted several questions to you (as have James) one recent one was :

"Then please look at the Marvin version of the MoneyTransfer example,
specifically look at the Account class and tell me what principles
that class violates so that objects of that type do not represent a
network of connected objects (ledger entries) and the interactions
they are part of so that they can perform a system operation
(withdrawal, deposit or balance)."

You've stated that class like the mentioned is an obvious violation of DCI so it should be a small task to ask of you and it will help me understand your line of thinking. If you can't find any violations you have already answered your own question at which point we can conclude the discussion.

-Rune

2012/7/2 Mikey B <mike...@gmail.com>

--

Mikey B

unread,
Jul 2, 2012, 5:41:23 AM7/2/12
to object-co...@googlegroups.com

alright rune, ill post the exercise in another thread and will continue later with answering outstanding questions.

James O Coplien

unread,
Jul 2, 2012, 5:50:36 AM7/2/12
to object-co...@googlegroups.com
On Jul 2, 2012, at 11:22 , Mikey B wrote:

Your bank account is represented as a Context; Which type of role can a bank account play? State which you think and why.

A Model — it represents the state of the system with respect to the end user's interest.


Model - the object playing a model role requires persistance,

Absolutely not. It only needs to report a value on demand. It can make it up. It can calculate it. It can go to other objects to get the information. Or (and this is the most likely) it goes to another API which has state and interacts with that object to manage the representation of the account state.


it must atleast hold the pointers to other objects with state.


Pointers are a very low-level implementation of name binding. There are other ways to represent bindings: database associations, named references, and a host of others.


A context only exists for the duration of its execution.

But this is tautologically absurd. If we take the simpleton's view that objects mirror nature, and that nature persists forever and that a Windows machine can't run more than a month without re-booting, then your argument suggests that OO is impossible.

--

Controller - Also requires state, to hold pointers to Views

View - a bank account does not represent communications with actors.

The interactions go in the controller.

Greg Young

unread,
Jul 2, 2012, 5:55:45 AM7/2/12
to object-co...@googlegroups.com
+1 to killing it. It's ridiculous for people that have actually implemented a banking system. The use case is a long running fsm.
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.


--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

Mikey B

unread,
Jul 2, 2012, 6:01:10 AM7/2/12
to object-co...@googlegroups.com

hi james,

On Jul 2, 2012 10:50 AM, "James O Coplien" <jcop...@gmail.com> wrote:
>
> On Jul 2, 2012, at 11:22 , Mikey B wrote:
>
>> Your bank account is represented as a Context; Which type of role can a bank account play? State which you think and why.
>
> A Model — it represents the state of the system with respect to the end user's interest.
>
>
>> Model - the object playing a model role requires persistance,
>
>
> Absolutely not. It only needs to report a value on demand. It can make it up. It can calculate it. It can go to other objects to get the information. Or (and this is the most likely) it goes to another API which has state and interacts with that object to manage the representation of the account state.
>
>
>> it must atleast hold the pointers to other objects with state.
>
>
>
> Pointers are a very low-level implementation of name binding. There are other ways to represent bindings: database associations, named references, and a host of others.
>
>
>> A context only exists for the duration of its execution.
>
>
> But this is tautologically absurd. If we take the simpleton's view that objects mirror nature, and that nature persists forever and that a Windows machine can't run more than a month without re-booting, then your argument suggests that OO is impossible.

im sorry james, a context only exists for the duration of its execution;

You picked model, if the context can not hold its name bindings, something else does.

The correct answer is 'none', a context can not play any role.


>
>> --
>>
>> Controller - Also requires state, to hold pointers to Views
>>
>> View - a bank account does not represent communications with actors.
>
> The interactions go in the controller.
>

rune funch

unread,
Jul 2, 2012, 6:40:17 AM7/2/12
to object-co...@googlegroups.com
The use case can't be a fsm, since a use case is in the problem domain and the fsm is in the solution domain :)
Would it be so that the account model actually holds for most users? Most regular users concern them self with something they call an account. The operations I as average Joe can perform in relation to my account are important to me and I associate them to this thing I call an account. That my accountant, the banker or someone else aren't that worried about what I call an account is irrelevant to how I use the system.
That I worry about something I call an account is irrelevant to those concern with internal audits at a bank and their way of using the system is irrelevant to me. Neither are irrelevant to implementation of the system.
If the system can't cater for both it will be incomplete and we would have to have a system for each group of users.
Which simply bring us back to the definition of OO as a network of connected systems.

That the simplistic implementation of an account doesn't meet reality is to me simply an example of the strength of nested contexts. What to some might seem like simple data is in fact an entire system of it's own right. Sure we could extend the implementation of MT so that the Account wouldn't be so simplistic but implement the full context and include all the nitty gritty parts that actually make up the system the account represents, thereby showing the complex system it abstracts upon. Would that help the example in conveying what DCI is? I don't know but if the answer is yes I wouldn't mind to help DCI'ify the code

-Rune

2012/7/2 Greg Young <gregor...@gmail.com>

rune funch

unread,
Jul 2, 2012, 6:46:18 AM7/2/12
to object-co...@googlegroups.com


2012/7/2 Mikey B <mike...@gmail.com>


sorry james, a context only exists for the duration of its execution;

You picked model, if the context can not hold its name bindings, something else does.

The correct answer is 'none', a context can not play any role.


All objects only exist in the duration of the execution (of the program) are you trying to suggest that programming is impossible?

James O Coplien

unread,
Jul 2, 2012, 6:57:54 AM7/2/12
to object-co...@googlegroups.com
On Jul 2, 2012, at 11:55 , Greg Young wrote:

+1 to killing it. It's ridiculous for people that have actually implemented a banking system.

I don't think you can speak for all of them, and I can connect you with some who would disagree.

That said, we badly need a better example. The way you vote for killing an old example is by creating a new one.

The use case is a long running fsm.

As I recall, there are quite a few other computer programs that are also reducible to FSMs...

James O Coplien

unread,
Jul 2, 2012, 7:00:03 AM7/2/12
to object-co...@googlegroups.com

On Jul 2, 2012, at 12:01 , Mikey B wrote:

The correct answer is 'none', a context can not play any role.

We have concrete counter-examples, and you have yet to give any evidence of having dutifully considered them.

I would usually say, "I disagree" but in this case can stand my ground and say "You are wrong."

I had hoped that you came to learn. I for one will refrain from further interaction with you in this forum. It leads nowhere.

I leave you with your theories.

Greg Young

unread,
Jul 2, 2012, 7:15:25 AM7/2/12
to object-co...@googlegroups.com
You can connect me with people who view the processing of an account transfer as a single step atomic operation? 
--
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.

Mikey B

unread,
Jul 2, 2012, 7:17:53 AM7/2/12
to object-co...@googlegroups.com

hi rune,

some good thoughts; ill try and answer some.

On Jul 2, 2012 11:40 AM, "rune funch" <funchs...@gmail.com> wrote:
>
> The use case can't be a fsm, since a use case is in the problem domain and the fsm is in the solution domain :)

Would calling a context a 'system operation' bring it into the solution domain for you?

> Would it be so that the account model actually holds for most users? Most regular users concern them self with something they call an account. The operations I as average Joe can perform in relation to my account are important to me and I associate them to this thing I call an account. That my accountant, the banker or someone else aren't that worried about what I call an account is irrelevant to how I use the system.

'Joe' (the customer) and the Accountant are Actors (uml 2 definition).

There are objects which play the View role which comunicate to these actors.

These two actors use different systems, systems which share data objects.

> That I worry about something I call an account is irrelevant to those concern with internal audits at a bank and their way of using the system is irrelevant to me. Neither are irrelevant to implementation of the system.
> If the system can't cater for both it will be incomplete and we would have to have a system for each group of users.

why do you feel it would be incomplete if they are seperate?

Take the three systems, ATM, Website, and TellerPOS.

Why would an accountant actor use the atm? or website? and similarly, why would a customer use the POS system? they simply share data objects :)

The view roleplaying objects and controller playing objects would be very different in each system.

James O Coplien

unread,
Jul 2, 2012, 7:20:08 AM7/2/12
to object-co...@googlegroups.com
I think that equating a DCI system operation with atomicity exhibits a serious misunderstanding of DCI.

rune funch

unread,
Jul 2, 2012, 7:27:38 AM7/2/12
to object-co...@googlegroups.com
I once again to answer the difficult questions then we can see if any of the below is still worth exploring. I think they stem from the same misconceptions

-Rune

2012/7/2 Mikey B <mike...@gmail.com>

hi rune,

Greg Young

unread,
Jul 2, 2012, 7:38:09 AM7/2/12
to object-co...@googlegroups.com
I am equating the example to that assumption not dci. 

James O Coplien

unread,
Jul 2, 2012, 7:39:02 AM7/2/12
to object-co...@googlegroups.com

On Jul 2, 2012, at 1:38 , Greg Young wrote:

I am equating the example to that assumption not dci. 

O.K. Show me the transaction in the code for the example.

Mikey B

unread,
Jul 2, 2012, 7:45:04 AM7/2/12
to object-co...@googlegroups.com


On Jul 2, 2012 12:27 PM, "rune funch" <funchs...@gmail.com> wrote:
>
> I once again to answer the difficult questions then we can see if any of the below is still worth exploring. I think they stem from the same misconceptions
>

i think your right rune, the biggest one is How long does a context exist for?

The documents say it exists on the stack and exists only for the duration of its execution. I guess only trygver can clarify this question.

Mike Brown

Greg Young

unread,
Jul 2, 2012, 7:45:31 AM7/2/12