Would i be correct in saying that there are heavy parallels to these practices and DCI?
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
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.
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.
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.
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.
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.What is a "facade controller"? The pattern mentions view facades and model facades.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.
No.The responsibility of a context(and UseCaseController) is to set up role bindings and manage the control flow of a usecase/operation.
I see no roles or role bindings in UseCaseController.A Context does not manage control flow of a use case. The role methods do.
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)
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 mappinguse case specifications to an implementation""... Use case maps are another alternative that combines behaviour and structurein 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 entityobjects, interface objects and control objects [7][8]. The strategy tochoose must be decided from application to application. In mostcases, the balanced strategy, where control is placed separately fromboth interface and entity objects, is the one that reaches higherlocality in changes of the functionality."
But the context will never represent a Domain Object
The UseCaseController document in this thread discusses inclusions (another use-case is called), extensions (hooks are provided by the use-case), and generalisations (inheritance).
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
No, I do not believe a SavingsAccount is a Context.
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.
--
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 SavingsAccountbalance: () ->tmp = new CalculateBalance(..roleplayers..)Result = tmp.execute(...params...)delete tmpreturn Resultcontext CalculateBalance... Contents of CalculateBalance use-case.
Your mixing the responsibilities of a Controller with a Context.
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 SavingsAccountbalance: () ->tmp = new CalculateBalance(..roleplayers..)Result = tmp.execute(...params...)delete tmpreturn Resultcontext 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.
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 SavingsAccountbalance: () ->tmp = new CalculateBalance(..roleplayers..)Result = tmp.execute(...params...)delete tmpreturn Resultcontext 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
Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.
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.
--
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.
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.
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).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.
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.
You do know that inheritance represents the "Generalisation Relationship" right? Which, yes, is one of the relationships use-cases can have.
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?
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?
What are the roles of CalculateBalance? And what objects play those roles? List them. Sounds like a SavingsAccount to me.
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.
To unsubscribe from this group, send email to object-composit...@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
--
alright rune, ill post the exercise in another thread and will continue later with answering outstanding questions.
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.
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.
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.
>
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.
+1 to killing it. It's ridiculous for people that have actually implemented a banking system.
The use case is a long running fsm.
The correct answer is 'none', a context can not play any role.
--
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.
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.
I am equating the example to that assumption not dci.
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
--
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.
Even though it seemed that the money transfer is a good example to illustrate the DCI concepts and approach, it did not serve well this purpose because of the above.
hi david, james
i can have a good guess as to why its hard for people to understand the notion of an "end user mental model". The term 'User' from trygve's original papers has dated.
He speaks of software as a service, and i guess at the time of writing the 'User' was the customer paying for the project, The person using the services provided by the software.. and they also happened to also be the domain expert.
User in todays world is similar, someone who uses a service. but with the internet and public services, it no longer means domain expert. (my mum is a user of facebook, but is no domain expert)
also in todays world, the 'customer' purchasing the software, may not necessarily be the domain expert any more.
The information from usecases having to satisfy many stakeholders may not have been clear during writing of the original documents. But we now know that the person with the clearest image of what happens in a system operation comes from the domain expert.
it should read "Domain experts mental model".
hi david, james
i can have a good guess as to why its hard for people to understand the notion of an "end user mental model". The term 'User' from trygvers original papers has dated.
He speaks of software as a service, and i guess at the time of writing the 'User' was the customer paying for the project, The person using the services provided by the software.. and they also happened to also be the domain expert.
User in todays world is similar, someone who uses a service. but with the internet and public services, it no longer means domain expert. (my mum is a user of facebook, but is no domain expert)
also in todays world, the 'customer' purchasing the software, may not necessarily be the domain expert any more.
The information from usecases having to satisfy many stakeholders may not have been clear during writing of the original documents. But we now know that the person with the clearest image of what happens in a system operation comes from the domain expert.
it should read "Domain experts mental model".
it should read "Domain experts mental model".
hi rune,
The user in the sense of your girlfriend, and 'users' of facebook are Actors, their needs are dealt with by MVC. The artima article is pretty good at describing MVC and the barrier of understanding the information.
Mike Brown
hi rune,
The user in the sense of your girlfriend, and 'users' of facebook are Actors, their needs are dealt with by MVC. The artima article is pretty good at describing MVC and the barrier of understanding the information.
On Jul 3, 2012 11:05 AM, "rune funch" <funchs...@gmail.com> wrote:
>
> I'm generally a very patient teacher, something that most of people I've ever taught will attest to. They can all also attest to the fact that I require one thing from them The will to learn and progress.
>
> Reluctant as I generally my be to throw the towl into the ring, this is the breaking point. You will either have to face the demons of change or I see no reason to spent time trying to teach someone that do not want to learn.
>
i dont want you and james to give up. your both important driving forces here.
> I've tried to give to the "ah ha experience" through questions, but you have avoided them
> I've tried to show you examples of why your arguments are incorrect but you shove them aside with misconceptions
>
> To your latest misconception (quoted below): How on earth can MVC give the user a pleasant experience if the Model is based on a view of the world that the user does not understand. In the weather example the data the user is looking for is not even a part of how the domain expert views the world. How can a view present something to the user when it's not even there?
>
I understand my comments are met with skeptisism; And im sure the only person that can help you is trygve. I will be deeply surprised if he agrees with your thoughts of MVC stated above.
Mike Brown
>
> 2012/7/3 Mikey B <mike...@gmail.com>
>>
>> hi rune,
>>
>> The user in the sense of your girlfriend, and 'users' of facebook are Actors, their needs are dealt with by MVC. The artima article is pretty good at describing MVC and the barrier of understanding the information.
>
> James, Trygve and I might not all agree on the details of DCI. DCI is after all evolving but rest assured the disagreements you are having in this discussion with Jim and myself on DCI and MVC iare not founded in the disagreements I've had with Trygve or Jim, nor because we haven't read/understood the artima article (or other articles on the subjects).
>
> -Rune
>
>
i dont want you and james to give up. your both important driving forces here.
> I've tried to give to the "ah ha experience" through questions, but you have avoided them
> I've tried to show you examples of why your arguments are incorrect but you shove them aside with misconceptions
>
> To your latest misconception (quoted below): How on earth can MVC give the user a pleasant experience if the Model is based on a view of the world that the user does not understand. In the weather example the data the user is looking for is not even a part of how the domain expert views the world. How can a view present something to the user when it's not even there?
>
I understand my comments are met with skeptisism; And im sure the only person that can help you is trygve. I will be deeply surprised if he agrees with your thoughts of MVC stated above.
James, im not after some kind of moral victory here.
Contexts can only live for the duration of its execution - This is something fundamental to DCI.
This means if a context is to play a model role, all of the addresses to the state objects are stored elsewhere (ive no idea where you suggest?) because the bindings to these objects are lost when the execution stops.
All i want is the lesson of a context object playing a role to be omitted, as it confuses/contradicts a DCI fundamental.
Mike Brown
Trygve Reenskaug mailto: try...@ifi.uio.no
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo Tel: (+47) 22 49 57 27
Norway
Hello Trygve,
On Jul 3, 2012 3:55 PM, "Trygve Reenskaug" <try...@ifi.uio.no> wrote:
>
> Mikey,
> I have been following the discussions on this thread and am amazed at the patience with which several people have been trying to explain important concepts to you and the stubbornness with which you have resisted being taught. Your ability to change the subject whenever somebody tries to make you actually use your brain, is truly amazing.
>
> Example: Rune: "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 :-----"
> Your answer: "alright rune, ill post the exercise in another thread and will continue later with answering outstanding questions."
> My comment: Why later?
>
james asked for references to back up my thoughts, something i was unable to do at the time. Would it be pointless in answering these outstanding questions now or still answer them?
> I gave up communicating with you very long ago since communication requires active participation from all parties. Your comments are not met with skepticism. Your comments are uniformly based on misconceptions and you appear to refuse to learn. I agree with James Coplien: Please cease being a disruption to this group and do us the service of taking your discussions elsewhere.
>
I respect your opinion, and will leave. I would be grateful to know which points im miss understanding, but will understand if you dont reply.
Thankyou for your time,
Mike Brown.
I made the a first implementation and wrote the original MVC reports while I was a visiting scientist at Xerox Palo Alto Research Center (PARC) inI think you are wrong. The user existed in Trygve's original works on MVC. There it was called the thing if I am not mistaken----
I'll give a short story
to clarify the meaning of the MVC terms.
Thing.
Consider my dog 'Fido'. Fido exists in the real world and eats and
plays and grows old and does whatever dogs do. Fido is a thing in
the meaning of my first PARC report. Not considered worth its own
letter since there is always a real world outside the program. (TMVC?
The 'T' is surely superfluous.)
Model.
I've opened the hood of my computer and can assure you that there are
no dogs there. What is there is a description of Fido
represented as bits within the components of my computer. All of Fido
can never be represented, but the description can cover all interesting
aspects: A video clip of Fido as a puppy, a snapshot of Fido as a
5-year old dog, his name and sex, his age, color, and weight, etc. I'm
not the only person interested in Fido; the vet is interested in his
illnesses, his medication history, his x-rays, etc. All these data
items are representations of the real things; they make up the Model.
View.
We could imagine that I had a special probe that permitted me to
inspect and toggle the individual bits that make up the data of the
Model. Not very user friendly, IMO. So we have a program that
transforms the model data into a form that I can see with my eyes,
understand, and manipulate with my hands. This program is a View.
It displays a field that holds Fido's weight, 15kg. I realize that I
have given Fido too much food lately, so I select the '16' and type
'19' over it to signify that Fido is getting fat. The model is changed.
A View is both input and output. I'm not interested in everything
about Fido; the View is also a filter showing the interesting parts
only. The vet's view will be different because his interests are
different.
Controller.
May be the vet wants to see two views at the same time; one showing
name, sex, age, weight, etc. Another showing his specialties such as
illnesses, medication, etc. He needs two views on the screen. They are
tightly related since they describe the same dog. The Controller sets
up and coordinates one or more Views.
User.
The ultimate master of it all is the user. I did not consider it worth
its own letter since there is always a user at the top of the
importance hierarchy. MVCU? I considered the 'U' as superfluous as the
'T'. Jim thought otherwise. Apparently, there are people who are so
fascinated by programming that the programs are their whole world. They
don't remember that a program is without value before it is used by an
end user for something valuable. So, regrettably, the 'U' is needed and
Jim's MVC-U is the better name.
My understanding is that an account is not any context, but data.
Please show me where you see any context in an account.Thanks,
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
What are the attributes of said data?My understanding is that an account is not any context, but data.
Please show me where you see any context in an account.Thanks,
The first is that knowledge, particularly in the young child, is retained as a series of operational models, each of which is somewhat ad hoc and need not be logically consistent with the others. (They are essentially algorithms and strategies rather than logical axioms, predicates and theorems.)
We feel that a child is a "verb" rather than a "noun", an actor rather than an object; he is not a scaled-up pigeon or rat; he is trying to acquire a model of his surrounding environment in order to deal with it; his theories are "practical" notions of how to get from idea A to idea B rather than "consistent" branches of formal logic, etc. We would like to hook into his current modes of thought in order to influence him rather than just trying to replace his model with one of our own.
given that the BDD mindset fits DCI very well.
So, the use case for adding (and for subtracting, etc.) those should have several variations or deviations (in your book terms) taking into account that those can be represented differently.
where the end user mental model ends, if it does, or how it reflects the way computing or use cases map to the cloud.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
I think your schema at the end is not correct: the Thing and the User are the same one actor (in the original Trygve's report or article).
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.