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

[rune funch]

I believe we should continue this discussion on DCI-evolution. Jim if you agree could you add mark please?

I find thed line of thought being compatible with the still open discussion (D)CI.

FYI I've taking the push from you Trygve to try and formulate my thoughts as a proper article but have been slowed down by butter-on bread work unfortunately.

@Mark: DCI is a paradigm MVC is a way to structure your application that can be used with in the DCI paradigm. So saying that we shouldn't need both is like saying that we should be able to use letters or words but shouldn't have the need for both

-Rune

2012/5/30 Mark W <ma...@williamsburgdesign.com>

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:

Den 28/05/2012 kl. 23.04 skrev Mark W :

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

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

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.