As a basis for further discussion Please consider the Attached Diagram.

[Mark W]

In the process of exploring a better way to organize my code, I have looked at various solutions. I have studied some ideologies more closely than others. My quest is to discover a way to marry the user mental model and the programmer mental model (because I am both) to enable the explanation of the generated solution to a new user with no understanding of either mental model. Or perhaps more correctly, is there an organizational method I can use to reduce the need for documentation and testing that allows me to look at the code of the generated solution by myself or others 3 years later when the user changes the mental model enabling a quick understanding of the code, make the change without side effects, and verify it. Some proposed definitions of success are 1) it must able to match the real world 2) it must work at the macro level as well as the micro level. There are potentially many other definitions of success these are 2 for the moment.

I realize, I am a relative babe in the woods on this topic but in order for this to be successful I need constructive criticism. I realize Model-Context-Interaction-Presentation (MCIP) has connotations and established definitions. I am hoping the diagram is more effective at communicating my thoughts. I feel like Presentation-Interaction-Context-Model (PICM) may be more correct but I am not quite convinced yet.

I look forward to healthy discussion.

[Mark W]

Rough Draft

Model - Context – Interaction – Presentation (MCIP)

Where I am going with this?

I am going to present this with the understanding that all who have come before me in this arena are given much deserved credit right here and now for their work. As this is not a research paper and I am a poor historian with dyslexia, it would be unproductive for me to reference those folks at ever turn. The exception is Trygve Reenskaug and James O. Coplien (T&C) as it is their work I derive/fork my thoughts upon.

What is my motivation?

I have some stuff stuck in my head and while in the process of writing code for 2 applications (one is functionally a subset of the other) with the intent of using the code as a basis for the extraction of the rest of the stuff stuck in my head. I realized I had some problems.

This was not the first time I have been here. A number years ago, I had arrived at the this place and chose not to look in depth for the root cause but only muse on it. Mentally, I came up with a similar solution to MCIP but because of my inexperience I did not pursue it. This time I decided to look in depth.

The first problem was code organization. When I followed the symptoms looking for a root cause, I concluded I had a conflict between programmer me and user me. So, I needed a solution to marry these two. T&C presented DCI. This is real close to the solution I was looking for. The DCI paradigm is mostly where I want to be. I read somewhere a good paradigm should work at both the macro level and the micro or atomic level.

The user mental model starts at the Presentation layer. The Programmers mental model starts at the interaction layer.

In an interview of the user, what does the user say to communicate his mental model? We hear I want to go to a screen and enter my user name and password and hit a button to login to the application. If we do not ask what the screen looks like, we find out later; the appearance of the screen the user was thinking about during the interview was a blue background with a Google imported font for the label, a different imported font for entering the user name and a blue button with a glassy look that says Enter at your own Risk!

As a solution provider we hear and can address the first part easily, we can also hear and address the second part easily but what we failed to do was address understanding the complete user mental model.

Who knows what?

T&C presents the user knows the interaction they desire, the basic algorithm they desire, the data they have available. I consider the user knows the presentation they desire, the basic algorithm, and they data they have available. The programmer knows how to model the data for use in the algorithm, which context tools to use and how to make them viewable to the presentation.

What it does, what it is, and what the user sees.

The programmers mental model is a reflection of the user mental model. This reflection is shown in the Presentation Layer. The Presentation Layer is where the appearance is injected upon the Interaction Layer.

The Presentation layer is a reflection of the Interaction layer. The Presentation layer uses events to communicate with the interaction layer.

To be continued and edited....

[Mikey B]

Hi Mark,

Im assuming your MCI (P) are parrallel to M(vc) (d)CI.

If there is anyone your most likely to convince with your line of thinking, is me.

I had come to this forum and Trygver personally in the hope to create a unified approach to DCI and MVC.

All i can say is ive come to the conclusion that MVC and DCI are both very mature and IMOH perfect as they are. The solution for me to bring them together is education and tools.

Ill happily give you the best explanation I can of MVC and DCI, but ill let you ask questions.

All i can say about your post is that "Presentation layer is a reflection of the Interaction layer" is not correct, It is a reflection of the data objects.

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/-/2vRdBMbRUFAJ.

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.

[Mark W]

Hi Mikey,

Well, I need to finish exposing my thinking. I am working to that end in a step by step approach in a fairly public manner. Unfortunately, some of the terminology I need to use has predefined connotations and so I need audience open mindedness as I try to redefine them.

The reason for the redefining of the presentation layer is the redefining of the interaction layer. Consider the user at his computer with the browser and a web application open within the browser.

In what layer is the is the browser and in what layer is the web app?

I would consider the web app to be in the Presentation  layer and the browser in the Interaction layer.

In the web app what layer is the CSS and JS of the RSS feed?

I would consider the CSS and JS in the Presentation Layer and the HTML in the Interaction Layer and more specifically the View within the Interaction Layer. The RSS feed would be in the Interface portion of the Interaction layer.

Another step and clearer than mud I hope.

BTW I heard somewhere Perfection Precludes Growth but don't quote me on that.

Thanks for your feedback.

Mark

On Friday, May 25, 2012 10:33:48 AM UTC-4, Mikey wrote:

Hi Mark,

Im assuming your MCI (P) are parrallel to M(vc) (d)CI.

If there is anyone your most likely to convince with your line of thinking, is me.

I had come to this forum and Trygver personally in the hope to create a unified approach to DCI and MVC.

All i can say is ive come to the conclusion that MVC and DCI are both very mature and IMOH perfect as they are. The solution for me to bring them together is education and tools.

Ill happily give you the best explanation I can of MVC and DCI, but ill let you ask questions.

All i can say about your post is that "Presentation layer is a reflection of the Interaction layer" is not correct, It is a reflection of the data objects.

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.

[Mikey B]

hi mark,

how about a clear definition of your terms and how you think they differ. and perhaps some justification of your examples that youve used in each term/layer.

mike brown

To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/TKSkLiQa5BMJ.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.

[Mark W]

Hello Mike,

Here is my first stab at this definition.

Definition of the Presentation Layer

The Presentation layer is a static reflection of the Interaction layer where the state changes through a user interaction or through a time driven change in the Interaction layer.

It took me a while to verbalize this as I needed to insure the definition correctly allowed for a dashboard with a real time stock ticker.

I am working on the others.

Be Well

Mark

On Friday, May 25, 2012 6:32:44 PM UTC-4, Mikey wrote:

hi mark,

how about a clear definition of your terms and how you think they differ. and perhaps some justification of your examples that youve used in each term/layer.

mike brown

Mark

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

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

[James O Coplien]

On May 27, 2012, at 4:14 , Mark W wrote:

The Presentation layer is a static reflection of the Interaction layer where the state changes through a user interaction or through a time driven change in the Interaction layer.

Why are any of these even layers?

I would say that there are no layers in MVC.

[Mark W]

Linguistics can be troublesome in established fields. I did not take into account the many permutations of the term layer. So, before I go on, I am going to correct myself and implement stratum to clarify my thinking. My use of stratum is to show the communication space between individual objects and object groups. Objects reside within the named strata of the MCIP paradigm.

[Mark W]

Strata in the Model - Context – Interaction – Presentation (MCIP) Paradigm

The user mental model starts at the Presentation Stratum. The Programmers mental model starts at the interaction Stratum.

In an interview of the user, what does the user say to communicate his mental model? We hear I want to go to a screen and enter my user name and password and hit a button to login to the application. If we do not ask what the screen looks like, we find out later; the appearance of the screen the user was thinking about during the interview was a blue background with a Google imported font for the label, a different imported font for entering the user name and a blue button with a glassy look that says Enter at your own Risk!

As a solution provider we hear and can address the first part easily, we can also hear and address the second part easily but what we failed to do was address understanding the complete user mental model.

Who knows what?

T&C presents the user knows the interaction they desire, the basic algorithm they desire, the data they have available. I consider the user knows the presentation they desire, the basic algorithm, and they data they have available. The programmer knows how to model the data for use in the algorithm, which context tools to use and how to make them viewable to the presentation.

What it does, what it is, and what the user sees.

Definition of the Presentation Stratum

The Presentation Stratum is a static reflection of the Interaction Stratum whose state changes through a user interaction or a time driven change in the Interaction Stratum. The Presentation Stratum is where the appearance is injected upon the Interaction Stratum.

[James O Coplien]

They are not stratified, either. 

--

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/-/LTZStZU9aYoJ.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.

[Mikey B]

Perhaps its worth asking why MVC + DCI are not good enough for you? What are you trying to fix?

Mike Brown

[rune funch]

Den 28/05/2012 kl. 08.20 skrev Mark W <ma...@williamsburgdesign.com>:

> I want to go to a screen and enter my user name and password and hit a button to login to the application

Users generally want something in the problem domain. The above
describe a solution to a problem ie it's in the solution domain. I bet
that what the user wants is to be authenticated.

[James O Coplien]

There's no business value in being authenticated, either. How many of you go home and say, "Hi, Honey! I had a great day at work today—I was authenticated ten times!" ?

[Patrick Mulder]

I agree that authentication is not part of a problem domain. I
recently experienced a nice example for this: In a booking system for
hotel rooms, I could search, filter and browse a list of free rooms
without being authenticated. Once I found the best room for making a
reservation, I could signup to the system. Now, being authenticated,
the reservation included the context from my previous search as well
as the context my personal user data. All I was required to do was to
provide the payment details. So, from user point of view, I really
liked the anticipation in context changes in the room booking process.
Not sure, if this is exactly what the discussion is about, but to me,
it's most often the context that makes an interaction with the system
valuable.

[rune funch]

Don't think I ever said that :)
At least what I tried to say was that authentication is part of the
problem, filling in a login form _might_ be part of the solution.
Stating the requirements based on the solution restricts the thought
process. To me it's related to whether we watch an object from its
inside (solution) or outside (behavior, "problem")

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

On May 28, 2012, at 5:26 , rune funch wrote:

> Stating the requirements based on the solution restricts the thought
> process. To me it's related to whether we watch an object from its
> inside (solution) or outside (behavior, "problem")

+1

[Mark W]

Mike,

"The first problem was code organization. When I followed the symptoms looking for a root cause, I concluded I had a conflict between programmer me and user me. So, I needed a solution to marry these two. T&C presented DCI. This is real close to the solution I was looking for. The DCI paradigm is mostly where I want to be. I read somewhere a good paradigm should work at both the macro level and the micro or atomic level."

On Monday, May 28, 2012 6:48:39 AM UTC-4, Mikey wrote:

Perhaps its worth asking why MVC + DCI are not good enough for you? What are you trying to fix?

Mike Brown

On 28 May 2012 11:08, James O Coplien wrote:

They are not stratified, either. 

Den 28/05/2012 kl. 06.11 skrev Mark W <ma...@williamsburgdesign.com>:

On Sunday, May 27, 2012 4:51:21 AM UTC-4, Cope wrote:

On May 27, 2012, at 4:14 , Mark W wrote:

The Presentation layer is a static reflection of the Interaction layer where the state changes through a user interaction or through a time driven change in the Interaction layer.

Why are any of these even layers?

I would say that there are no layers in MVC.

Linguistics can be troublesome in established fields. I did not take into account the many permutations of the term layer. So, before I go on, I am going to correct myself and implement stratum to clarify my thinking. My use of stratum is to show the communication space between individual objects and object groups. Objects reside within the named strata of the MCIP paradigm.

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

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.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

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.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

On Monday, May 28, 2012 6:48:39 AM UTC-4, Mikey wrote:

Perhaps its worth asking why MVC + DCI are not good enough for you? What are you trying to fix?

Mike Brown

On 28 May 2012 11:08, James O Coplien <jcop...@gmail.com> wrote:

They are not stratified, either. 

Den 28/05/2012 kl. 06.11 skrev Mark W <ma...@williamsburgdesign.com>:

On Sunday, May 27, 2012 4:51:21 AM UTC-4, Cope wrote:

On May 27, 2012, at 4:14 , Mark W wrote:

The Presentation layer is a static reflection of the Interaction layer where the state changes through a user interaction or through a time driven change in the Interaction layer.

Why are any of these even layers?

I would say that there are no layers in MVC.

Linguistics can be troublesome in established fields. I did not take into account the many permutations of the term layer. So, before I go on, I am going to correct myself and implement stratum to clarify my thinking. My use of stratum is to show the communication space between individual objects and object groups. Objects reside within the named strata of the MCIP paradigm.

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

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.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

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.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

On Monday, May 28, 2012 6:48:39 AM UTC-4, Mikey wrote:

Perhaps its worth asking why MVC + DCI are not good enough for you? What are you trying to fix?

Mike Brown

On 28 May 2012 11:08, James O Coplien <jcop...@gmail.com> wrote:

They are not stratified, either. 

Den 28/05/2012 kl. 06.11 skrev Mark W <ma...@williamsburgdesign.com>:

On Sunday, May 27, 2012 4:51:21 AM UTC-4, Cope wrote:

On May 27, 2012, at 4:14 , Mark W wrote:

The Presentation layer is a static reflection of the Interaction layer where the state changes through a user interaction or through a time driven change in the Interaction layer.

Why are any of these even layers?

I would say that there are no layers in MVC.

Linguistics can be troublesome in established fields. I did not take into account the many permutations of the term layer. So, before I go on, I am going to correct myself and implement stratum to clarify my thinking. My use of stratum is to show the communication space between individual objects and object groups. Objects reside within the named strata of the MCIP paradigm.

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

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.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

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.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

On Monday, May 28, 2012 6:48:39 AM UTC-4, Mikey wrote:

Perhaps its worth asking why MVC + DCI are not good enough for you? What are you trying to fix?

Mike Brown

On 28 May 2012 11:08, James O Coplien <jcop...@gmail.com> wrote:

They are not stratified, either. 

Den 28/05/2012 kl. 06.11 skrev Mark W <ma...@williamsburgdesign.com>:

On Sunday, May 27, 2012 4:51:21 AM UTC-4, Cope wrote:

On May 27, 2012, at 4:14 , Mark W wrote:

The Presentation layer is a static reflection of the Interaction layer where the state changes through a user interaction or through a time driven change in the Interaction layer.

Why are any of these even layers?

I would say that there are no layers in MVC.

Linguistics can be troublesome in established fields. I did not take into account the many permutations of the term layer. So, before I go on, I am going to correct myself and implement stratum to clarify my thinking. My use of stratum is to show the communication space between individual objects and object groups. Objects reside within the named strata of the MCIP paradigm.

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

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.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

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.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

On Monday, May 28, 2012 6:48:39 AM UTC-4, Mikey wrote:

Perhaps its worth asking why MVC + DCI are not good enough for you? What are you trying to fix?

Mike Brown

On 28 May 2012 11:08, James O Coplien <jcop...@gmail.com> wrote:

They are not stratified, either. 

Den 28/05/2012 kl. 06.11 skrev Mark W <ma...@williamsburgdesign.com>:

On Sunday, May 27, 2012 4:51:21 AM UTC-4, Cope wrote:

On May 27, 2012, at 4:14 , Mark W wrote:

The Presentation layer is a static reflection of the Interaction layer where the state changes through a user interaction or through a time driven change in the Interaction layer.

Why are any of these even layers?

I would say that there are no layers in MVC.

Linguistics can be troublesome in established fields. I did not take into account the many permutations of the term layer. So, before I go on, I am going to correct myself and implement stratum to clarify my thinking. My use of stratum is to show the communication space between individual objects and object groups. Objects reside within the named strata of the MCIP paradigm.

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

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.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

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.

[Mark W]

Where did I reference business value or authentication yet? I did use the log in screen example as an illustration of the potential difference between the user mental model and the programmer mental model. I wanted to emphasize the communication being fully aware of Cope's comment to his wife about the lack of object and business value.

 

T&C stated there were phases of acceptance and I appreciate the help in enjoying this phase.

[rune funch]

Den 29/05/2012 kl. 02.59 skrev Mark W <ma...@williamsburgdesign.com>:

> Where did I reference business value or authentication yet? I did use the log in screen example as an illustration of the potential difference between the user mental model and the programmer mental model

The users mental model (usually) has to do with the problem and since
the authentication mechanism is not part of the problem I don't
believe it's part of the users mental model as you claim. This
difference will affect how we design our contexts. My context might
have a user role with a RoleMethod 'authenticate'.
However if I state the requirements based on possible solutions I'm
more likely to model the described possible solution than I am likely
to model the actual problem and it's the problem that's the basis of
the users mental model.
I find that a lot of the artificial classes I have when I fall into
the trap of confusing the solution domain with the problem domain tend
to disappear if I keep my focus. Managers, AbstractFactories and other
kinds of "glue" that doesn't exist in the users mental model of the
problem they tend not to be part of the solutions I end up with when
focusing on modeling the problem domain

[James O Coplien]

Den 28/05/2012 kl. 23.04 skrev Mark W <ma...@williamsburgdesign.com>:

> The first problem was code organization. When I followed the symptoms looking for a root cause, I concluded I had a conflict between programmer me and user me. So, I needed a solution to marry these two. T&C presented DCI. This is real close to the solution I was looking for. The DCI paradigm is mostly where I want to be. I read somewhere a good paradigm should work at both the macro level and the micro or atomic level.

Perhaps it is worth asking why MVC + DCI are not good enough for you. What problem are you trying to solve?

[Mark W]

Cope,

I appreciate your interest and time. 

Background Perspective: For eight years I was immersed in the Japanese Manufacturing Environment, my colleagues educated me in how and why they do what they do. My education proceeded beyond the manufacturing environment to the corporate board room. One of the ideologies I took away from this experience is, they do not confuse complex problems with complex solutions.

It is my belief the majority of programming methodologies create complex solutions for simple problems. If my understanding of the reasoning behind MVC is correct and my understanding of the reasoning behind DCI is correct, one of their purposes is to reduce solution complexity.

My problem is what is the next step for OOP? Why do we need two+ paradigms or perspectives? Are we not trying to solve one problem? Should one of the objectives of OOP be the ability to draw a proverbial straight line from the most outward facing code to the most inward facing code and strive to extend it? Even with language differences and features, does the definition of a properly coded solution include having the ability to be reused from one data set to a similar data on different systems? For example: the use case of an ATM is the same from Banking System A to Banking System B therefore, a properly coded solution for Banking System A should work for Banking System B by only changing the minimal amount of code. What paradigm provides a target container making this possible?

Lastly, isn't Scratch (scratch.mit.edu) brilliant?

Mark

On Tuesday, May 29, 2012 10:55:51 AM UTC-4, Cope wrote:

[James O Coplien]

On May 30, 2012, at 5:58 , Mark W wrote:

What paradigm provides a target container making this possible?

I thought it was DCI, and that the container is the Context. But reuse has little to do with technology anyhow; it's a sociological phenomenon, and is best taken up on some ICSE lists somewhere.

I would take this discussion to DCI-evolution if I see some kind of premise of a concrete critique of where DCI falls short (the above plaint obviously doesn't make it) or a concrete proposal, with at least a vision of the code, of how to evolve DCI.

Mark, I am still puzzled by what the vision may or may not be behind your mails. I know you had been looking at the same problem and that you were inspired by the prospects of the DCI solution. Your perspectives on where to go form here would seem to have made sense 10 years ago before any concrete notion of DCI, but I think we've rolled through most of the musings you've posed here and the destination was ultimately DCI.

I think a lot of people here feel that the next step for OOP—as you ask about it in your mail—is DCI. I think it's a well-articulated vision. OOPSLA thinks about it enough that way that they've invited me to give a keynote on it, as has my favorite Japanese drinking buddy Nagase-san for the SA conference in Japan next January. If you're interested in discussing what comes beyond DCI, I'd suggest that you'd have a better arguing position if we grounded the discussions in a body of DCI code you would develop to illustrate your positions. But, even better, I feel we need to be working to make DCI the best it can be first before jumping to the next idea. So I'd suggest immersing yourself in DCI and seeing if your vision is compatible with it. Maybe it's incompatible in which case it doesn't belong here. Maybe DCI has solved it all in which case there is no agenda to evolve it. Or maybe you can add something—in which case we can take it up on DCI-evolution. But I don't want to presume the third option without validating which option is relevant.

[Mark W]

Cope,

The six questions posted are a subset of the questions I intend to answer and show how I got to the solution derived/forked from DCI and MVC.

I am puzzled by your answer to "What paradigm provides a target container making this possible?". As defined by MCIP as a design pattern, my choice would be to only change the database connection and convert the data format and structure in the model layer producing "micro databases" as defined in Tryger's commonsense.pdf while leaving the Context-Interaction-Presentation portion of the system unchanged. In practice, we would have to change some of the presentation layer because I pretty sure Bank B would be unhappy with Bank A's Logo.

My original post was a diagram and the intent was to develop my thought process publicly over time. I have apparently chosen the wrong methodology to do so. So, I will wait untill I have the fully developed the text and code samples to post again. 

Be well

Mark

[Mikey]

Did you manage to get any more understanding?

Mike Brown

[James O Coplien]

I'm not sure if this is addressed to Mark or to me, but as for me, I'm awaiting the code.

--
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/-/YiWfs5rN0fgJ.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.

[Kris Leech]

On Wednesday, 30 May 2012 06:58:58 UTC+1, Mark W wrote:

It is my belief the majority of programming methodologies create complex solutions for simple problems. If my understanding of the reasoning behind MVC is correct and my understanding of the reasoning behind DCI is correct, one of their purposes is to reduce solution complexity.

My problem is what is the next step for OOP? Why do we need two+ paradigms or perspectives? Are we not trying to solve one problem?

You might be interested to look at the Raptor framework [1], from its README: "Raptor is not MVC; at least, not in the way that frameworks like Rails are".  Raptor has no controller layer, instead it has a powerful router with autherisation. I've not played with it much but routing directly to use cases/contexts sounds like a neat idea.

[1] https://github.com/garybernhardt/raptor