Using DCI to implement DCI BabyIDE

[Hai Quang Kim]

Hi Everyone and Happy New Year,

I am working on DCI Baby IDE for visual studio.

I just finished the 1st step (domain analysis, modelling).

Just want to share what I got:

In this case, the View is harder than then Model, so I start to work on the Model first.

The Data is pretty simple, it doesn't have a lot of methods (not so smart).

The idea here is:

1) given a context file

2) The Parser will parse the file and save Context Info (Usecase, Roles, RoleMethods, RoleInterface) into the Model

3) The View will display the Model in 4 Views (Usecase, Interaction Graph (Role connect to Role), Partial Code View (for selected Role Method), full Code View)

The 1st use case I have:

Use case: Parse Context File

1) User asks System to display Context File in Baby IDE  (select a file, right click to trigger command)

2) System parses the Context File to get Context Info (usecase, roles,...)

3) System displays Context Info in BabyIDE

The use case I have is very simple. So I have 2 options here:

I)  Implement this as a simple Context:

Parser usually implements an algorithm. For example:

1) Find all Regions in Context File

2) Find Use case region to read use case info

3) Find Role region to read role info

....

 https://github.com/wangvnn/TheDCIBabyIDE/blob/master/TheDCIBabyIDE/Domain/Operation/ContextFileParsing.cs

(in //#region TODO parser algo, start from public void LoadFromFile(string filePath))

This solution is simple and Context have no Role(s), just a composition of procedural methods.

I think I did this many times in real life project, and this is not DCI.

II) Add more details to this Use case:

Here where I usually have the problem with OOP in a Context (maybe this choice looks much harder than the 1st choice)

This is actually a Read Model (blue lines in the diagram), so I may not need to use DCI here, just simple parser class will do.

In the write model (green lines) or the View Model (read lines), it may be more interested to use DCI (more objects, more interactions)

My main concern here is: It looks like a use case, it looks like an algo, but I find it is hard to find interaction, roles here in the Context.

Is it because I still need to do deeper analysis here in the Parser Context?

Here What I have in my mind:

Use case: Parse Context File

1) Region Reader reads all region info

2) Usecase Reader reads usecase Info from Usecase Region

3) Context Reader reads ContextInfo from Context Region

4) Role Reader reads RoleInfo from Role Region

It looks more OOP than the 1st one, but Is this better than the 1st one?

I also notice that all the Role Candidates ( RegionReader) may be played by different kinds of Parser(s) (Marvin parser, injectionless parser,....)

So the we need only 1 main Context and we can inject different kind of parser(s) for different kind of Context File(s).

These Role Candidates also have no real data, just pure method code since this is the Read Model.

That makes this Context looks like template (main Context) + strategy (different parser role) pattern.

On the side note:

I think it is not always easy to do OOP except for cases that is the direct mapping from real life like: shopping cart, bank transfer..

In reality, I usually have to face fictional terms, and to work it out in OOP I have to think I were Alice who lives in the Wonder land.

Alan Kay said we need to use the biological cell metaphor for OOP, but I think it is not easy for every to think that way.

(for example: how can a Chair can a message to a Table? :) )

We are programmers, engineers, so It may be easier to think in term of computer like Trygve's term: Computer Object.

To me, it is just about someone has better imagination than others to apply OOP :)

/quang

[James O Coplien]

How do you capture your domain analysis (i.e., what formalism do you use)?

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Hai Quang Kim]

The domain is what we was discussing in this forum.

What is a DCI Context, a Role, a Role Method, a Role Interface...?

And how they are related to each other...?

And of course the inspiration from Squeak's Baby IDE.

I only redesign the UI to have the use case panel, which I think it is important to keep it in sync with the Context code.

That why I started with the Domain first, because I am more familiar with it. 

In other case I may need a domain expert and a formalism method to analyze it. 

(btw Do you have any suggestion?)

From the diagram, it is clear how the data flows from reality to the Model and to the View back and forth.

But when I start to add behaviors by using DCI, I hit the same rock again: use case -> role, and interaction.

If I just do the Algorithm (parse a file and output the Model) in Context like I did many times before I could move faster. (it just comes out naturally)

But Here is the point that I want to go slow to learn thing.

I wonder How the OOP (Roles and interaction) helps to build up the Context code fast here compared to the procedural approach in the Context ?

/quang

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[James O Coplien]

On 30 Dec 2014, at 13:50, Hai Quang Kim <wan...@gmail.com> wrote:

The domain is what we was discussing in this forum.

What is a DCI Context, a Role, a Role Method, a Role Interface...?

And how they are related to each other...?

A technique suitable to that domain is “analysis” rather than “domain analysis.” As used in the context of this forum, “domain analysis” usually means the process of formalizing understanding of some broad area that is related to software families or of recurring use under delineated points of variation.

It is, I guess, possible to do a domain analysis of DCI implementations, to delineate the different ways of binding role methods to objects (run-time injection, just-in-time association, anonymous class creation, template association) according to commonalities and points of variation. If you have done that it would indeed be valuable. However, I suspect that such a study would take a long time and a lot of people with varied experience. It’s maybe something we should do.

The reason I asked is that I find that many people (and especially the DDD people) use “domain analysis” for what the rest of the world calls “design.” If the result of your analysis is classes, you have gone far beyond the analysis into design. It is extremely useful — in complex domains — to articulate the domain analysis as a prerequisite to application engineering, which is the scope of design activities.

Your answer above indicates that you have done design, since you already have delineated artefacts called Contexts, Roles, Role Methods, and Role Interfaces. To which I will again inquire: Where is the *analysis*? And then I would inquire: Is it just an *analysis,* or is it a *domain analysis*? I am concerned that “domain analysis” could be two ways removed from what you have done, but I’m trying to understand that.

[Hai Quang Kim]

You are right. I did use a niche term for it.

Basically it is just a Model of the reality. So it should be called Modeling step. ( I am not sure if this is the same step as Domain Analysis in DDD)

For example:

In that Model:

- A Role represents the information of a DCI Role in a Context File:

+ Role Name

+ Role Interface

+ Role Methods:

   + Method Name:

   + Method Span (start position in File, and the Length of the Span)

These info will be used to display Context in the IDE.

Ex: Span info will be used for the partial code view panel.

So I guess my domain is not about DCI implementation but about displaying DCI context file (parse it, show it, and edit it).

The input Context file could be any implementation (Injectionless with Roles in the Context, or Marvin....).

For each kind of Context file, I may need different Parser(s), but after the parsing step I should have my Model data (Role, RoleMethod....) to display them in the BabyIDE.

Assume that I am at the step that I already have my Model, and working on the blue lines (Parsing).

For this Parsing step, I do have the usecase and the Algo which could be implemented as composition of methods in a Context with no Role at all.

But I am trying not to do the old thing, instead trying to implement it as an interaction of Roles in the Parsing Context.

/quang

[James O Coplien]

On 30 Dec 2014, at 14:29, Hai Quang Kim <wan...@gmail.com> wrote:

So I guess my domain is not about DCI implementation but about displaying DCI context file (parse it, show it, and edit it).

This sounds like an implementation, which comes after design, which comes after the initial modeling.

Assume that I am at the step that I already have my Model,

Assumption is the mother of all… great mistakes.

I think this group could help you if you shared your model. If you don’t have one, that’s fine too, but you might find it serves you well to agree with yourself whether you actually have a Model or not.

[Hai Quang Kim]

I think I better just use DCI terms.

I am sorry that sometimes I use terms from DDD, UML....and mix them all up.

I am using DCI to implement the BabyIDE.

And I just finish the 1st pass of the Data layer (DCIContext, DCIRole, DCIRoleMethod, DCIRoleInterface)

I was thinking that working on the Data layer is working on the Model (or Domain Analysis...)

There must be something wrong with that thinking, so can you help to define the 'what is a Model' ?

Now I am working on the implementation of my 1st use case.

The use case is very simple:

Use case: Displaying Context File in BabyIDE

1) User asks System to open Context File in BabyIDE (right click on a selected Context file and trigger open command)

2) System parses Context File for Context Info (Role, Methods, Interfaces)

3) System displays Context Info in the IDE.

I would like to implement this use case as a DCI Context (with Roles and Interaction)

But I find it a bit hard to do so for now.

So to move on I decided to just implement it as simple Algorithm Class.

This will allow me to build a working skeleton (all the way from Data to UI), then I can refine them.

It may be worth to mention my current process (bottom up for this case)

1) Working on the Data layer -> DCI Data (What the System is)

2) Working on major use cases to connect View - Data: DCI Contexts  (What the system does)

3) Refine the use cases, and refine the Context, Data code.

/quang

[Hai Quang Kim]

I refined the use case, and break it into 2 use cases:

I) Parse Context File

1) READER FACTORY reads IDE SETTINGS to create suitable READER (Injectionless, Marvin,...)

2) READER reads and returns CONTEXT MODEL INFO (II)

II) Read CONTEXT FILE (Interaction oriented)

1)  REGION READER reads all the REGION INFO

2)  CONTEXT READER reads CONTEXT INFO

3)  USECASE READER reads USECASE INFO

4)  ROLE READER reads ROLE INFO

vs the Original (Algo oriented)

1) Find all the region info

2) from region info read context info

3) from region info read usecase info

4) from region info read role info 

This process help to shape a better mental model, and make the code more readable.

I think the main problem with this use case is: I don't have many Role Players, but I do have many Roles.

So the Context object has to play all these Roles. From the codewise, it feel unnatural. But from the user mental model, somehow this is better for thinking.

I am not sure this is an 'aha moment'. But After I get pass this moment, It is easier to think in term of DCI interaction now.

/quang

[Hai Quang Kim]

I also found this old thread: https://groups.google.com/forum/#!topic/object-composition/Ldn0poOMLb4

It  looks like he has similar use case (decode something)

In his case, he uses the Data Object to play the Role of the Reader (Parser).

In my case, I use the Context Object.

I am not sure if it is just the matter of personal mental model.

/quang

[James O Coplien]

Many of your roles strike me as data entities. Most of this looks like code raised up one level, rather than analysis.

Maybe you have your analysis in your head. In any case, I don’t see enough of it here for me to be able to comment on it, and I’ll cease commenting on the analysis aspect of your project.

Happy New Year!

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

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

[Hai Quang Kim]

Yep, I think it is always hard to share common understanding on a topic without face to face discussion.

Thank you very much and Happy New Year !

/quang

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[Hai Quang Kim]

Set aside the Model question, I may have it in my head but I don't know how to share it effectively yet.

What I would like to share here is the answer for my own previous 'stupid' question: 

Why do we need OOP(Roles, interaction) in a Context?

By solving a real world problem from scratch by using DCI I finally got the answer myself (even Cope and Rune, and many of you here in this forum already helped me with this answer before)

I think the key point is I need to do it myself to get it by doing very deep thinking.

In this presentation: http://www.infoq.com/presentations/programming-design-coding

Leslie Lamport shows us the tasks of programming:

3 Tasks of Programming:

1) Decide What a program should do?

2) Decide how the program should do it?

3) Implement these decision in code.

Task 1 and 2 we should think before we code. And How to think clearly?

The answer is: Write it down.

So for my case: The above diagram is kind of the answer for 1) What my program should do: read a Context File, translate it to Model (Context Info, Role Info...), and display those info into Editor, then allow user to edit them)

What is interesting is: the step 2) -> step 3).

In reality, many programmers just do it by code and fix: code it first, think, code, fix, think... and hope it gonna work.

In the end, it is not hard to make it work, but later on when we come back, it is very hard to know what was happening.

So there is a need to write it down before we code, but the question here is how much should we write down, and what kind of format, template , standard to write the Specification/Design....?

There is no one answer for those questions. In the above video, the author show use how to use Language TLA+: http://research.microsoft.com/en-us/um/people/lamport/tla/tla.html 

to write down the Spec.

So DCI is another way to do task 2) and task 3).

I use usecase as a unit of work to think: 

What the user want, how he/she trigger it?

This will help me to form my use case from the user mental model. For example:

In my BabyIDE, the first thing the user want is to right click and open a Context File in the Editor.

Use case: Open Context File in Editor

Trigger: Right Click on a selected Context File in the Solution Explorer.

Steps:

1) Read the Context File

2) Find  all regions

3) Read Context info from Context Region

...

Those are steps that the user(or the software designer or just me as the programmer) could tell me/myself what should happen.

Here is the point I get confused. At first I thought that it is easier just to keep this use case style since it is simple and it come straight from the user, no need to transform it.

Then I just implement this use case a an Algo in the Context (sea of procedures). All looks simple, well connected and easy to implement. (the effect of many years doing old OOP style)

So By doing this I answer the question: what is happening, but I did not answer the question who does that (in DCI) but instead I answer the question at which step the system/context did that?

When I tried to convert the above use case to interaction use case:

1)  Context File Parser parses Context File

2)  Context Info Reader read Context Info

.....

I realize this much better. Rune mentioned before The Role here acts like an Object with an Identity and compresses the knowledge what this object with that identity can do.

This is very important point I finally learn it in the hard way.

In the previous style I use Step 1) Step 2)... to communicate what happens. But a Step 1) in Context A and a Step 1) in Context B has no different identity hence it is very hard to communicate what it does.

The Role with a good name can carry that knowledge and allows the team to communicate more effectively. (it may need to be explained for the first few times, after that everyone should know that Role in that Context).

I think this is a big 'aha' moment for me, and it is worth to share. 

 I hope this will help other newbies like me. Thank you very much and please help to correct me if my thinking is still  somewhere.

/quang

[Andreas Söderlund]

Congratulations on a mental breakthrough, Quang. :) There's one thing I remember Cope said (in a video, don't know which one) that Use cases should convey real value, the user should practically be able to tell a story about the value it created for him/her.

I don't think a user will excitedly tell others "I opened a file in the editor today!" :) So maybe it's not a real Use case? It seems more internal, perhaps it could be made into an algorithm or Context straight away.

Apologizes if you're thinking about this already.

/Andreas

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

[James O Coplien]

On 02 Jan 2015, at 07:18, Hai Quang Kim <wan...@gmail.com> wrote:

Leslie Lamport shows us the tasks of programming:

3 Tasks of Programming:

1) Decide What a program should do?

2) Decide how the program should do it?

3) Implement these decision in code.

And Leslie would be partly wrong. When you build a house, you might consider what it “does.” However, most of what a house “does” is given and bears little reflection: it keeps us warm and dry, away from the elements, wild animals and thieves. The focus on a great house is on what it *is,* rather than on what it *does*.

What the Taj Mahal *does* is to be a tomb; what it *is* is beautiful. As Rybczynski says, a library is more than a warehouse for books: its form celebrates the intellectual legacy it represents.

If you look at a wildly new successful app here in Denmark, it’s called MobilePay. What it *does* is “pay for stuff.” What it *is* is a relationship between several interesting artefacts and people: your phone, the bank, a vendor, and the respective accounts of the vendor and consumer. Let’s say I want to sell apples (I have a nice large apple tree in my back yard and usually have extra apples). I put the apples out in front of my house, price them at 15 Dkk each, and put a sign saying, “Pay via MobilePay at 40216220.” For each bag of apples to purchase, the passerby brings up MobilePay on his or her phone and uses it to transfer 15 Dkk “to my phone number.” The apps of course talk to the banks, and the whole registration setup is designed to provide a secure money path between accounts using an already widely-available handle.

 (Extra credit question: is my phone number a Destination Account? Is this the Money Transfer example, or is it a different reality?) 

What this “does” is no different than a credit card. What’s important and novel about the system is what it *is*. DanskeBank has gone beyond modeling conventional reality. They have created a new reality.

Taking this one step further: in method and life, people are focused on what they *have done* or what they *have accomplished.* That’s what they *do.* We “do agile.” No. The focus should be on what you *are* rather than what you *do*. And as for things like agile, and happiness in life, it’s about more than doing or being, but about Becoming. To me, this is the part of DCI we need yet to explore deeply: the Becoming of a program over time. I know it is there, but so far, we don’t have the experience base to elaborate it.

[Hai Quang Kim]

I think I started to have this feeling as well. You just make it crystal clear.

Every time I finish a use case, I feel that I just achieved something  (growing my application 1 step bigger).

So step by step, one use case at a time, my application become more useful.

Thanks for that great example.

/quang

[Hai Quang Kim]

@Andreas, Thanks a lot.

I think practicing makes different.

My problem is always about a chance to use DCI in real life. (which was blocked by all kind of problems with DCI implementation of trait)

 "I opened a file in the editor today!" 

In this case, I think the user is a programmer who will use the Baby IDE to open a Context file.

So I, as a user of my own system, I think I will be happy to achieve that.

Just like the first time I used Squeak Baby IDE, I was excited.

The interaction in the Context is a graph, the best way to view a graph is the visual of it :)

/quang

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsubscribe@googlegroups.com.

To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Matthew Browne]

If the end of the use case is seeing the graph of roles/interactions in the editor, why isn't that listed as the last step in your use case? 

[James O Coplien]

On 02 Jan 2015, at 07:18, Hai Quang Kim <wan...@gmail.com> wrote:

Set aside the Model question, I may have it in my head but I don't know how to share it effectively yet.

O.K., that’s fine, and I won’t pursue this any further. I might just point out that good software architecture is usually a product of community and of communication with the stakeholders rather than the work of a single individual, and that “it’s O.K., I have it in my head,” absent socialisation and communication is probably a leading cause of software problems.

“Everybody all together — from the beginning."

[Hai Quang Kim]

the above use case is just a simplified version.

The real one is bigger. 

Use case one: Parse Context File

Precondition: Context File is valid

Post Condition: The Model with all the Info

Use case two: Display The Model in the Editor

Precondition: The Model with all the Info
Post Condition: User can see the graph of interaction

In the Prokon example, Trygve even uses  many use cases to update the View from the Model.

http://fulloo.info/Examples/SqueakExamples/BB9Planning/readableVersion.html#Controller

update: aSymbol
    aSymbol = #Model 
    ifTrue: 
        [DependencyDisplayCtx new refreshDependencyView: dependencyView.
        GanttDisplayCtx new refresh: ganttView.
        ResourceDisplayCtx new refresh: resourceView.
        activityTextView selectionChanged. 
        blurbView selectionChanged].

In my Baby IDE app, the use case Parse Context File is complicated enough to be a Context.

In Prokon, it is just a Serialization process from File to Model.

Otherwise, all the use cases are very similar.

/quang

[Hai Quang Kim]

I am doing it all alone.

That why sometimes I cannot see that benefit clearly.

I wish I could have a team who all agree to work together that way.

But that could be next step: to sell this to my team.

/quang

[Matthew Browne]

Quang, I get the sense that you would like to communicate your model to this group but aren't sure how to do that. Earlier Cope mentioned the importance of a good problem description...maybe that would be a better place to start than jumping right into the use cases?

If you were working on software intended for non-programmers, my advice would be to pretend you're not a programmer, look at the big picture, and focus on the human level when writing your initial use cases. In this case you're writing software intended to be used by programmers, so "pretending you're not a programmer" may not be the best advice, but you can still take a step back and describe the system at a higher level before talking about a "Reader Factory" and other programming concepts like that.

Even when you're the only programmer on a project, it's still important not to jump to such a detailed level of design right away...to take the house metaphor, first you'd want to decide why you're building a house in the first place, where to build it, etc. We have an idea of the purpose already in this case since BabyIDE already exists and we have seen that it has benefits for DCI programming, but it might still be helpful to pretend as if you're writing it for the first time and describe how you envision it. This corresponds to the next step of building a house - deciding what kind of house you want and playing with different ideas for its design. Then you'd want to formalize that design in a blueprint...clearly, there are a lot of steps involved before you actually start building the house. Cope is objecting to the fact that you seem to be jumping right into the middle of the process without completing the initial steps.

--
You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/IzoIo5kFv1c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.

[Hai Quang Kim]

@Matt, Thanks for the advise.

I realized that mistake also.

I was assuming it is the BabyIDE app, so everyone should more or less have the idea how it works.

But then I realized that maybe not all of us tried it out and still can remember what it is.

That why I set it aside, and focus on answering the question why we need OOP in the Context ?

Which is a clearer question?

For the Model of the BabyIDE, of course I have it in my head and the 1st diagram is the summary of what it is and what it can do.

I can spend some time to write it down with more details to communicate it better with others.

I think many times we failed the discussion in this forum due to the mis-understand of the problem.

So I am not sure I should try it again, it could be too big and too long for a meaningful discussion :)

/quang

To unsubscribe from this group and all its topics, send an email to object-composition+unsub...@googlegroups.com.

[Matthew Browne]

Another aspect of the problem is that you seem to be starting your design process by looking at the Squeak code for the existing BabyIDE. While it's true that DCI allows you to get some idea of the original programmer's mental model just by looking at the code (that's one of its big advantages), trying to extract a mental model only from code is kind of a backwards way of going about it, especially when you're rewriting a system in a different language/environment...

[Hai Quang Kim]

You seem to spot my weakness very right :)

That is very true, when I review my experience with DCI.

It is all about porting. Which was good to start with.

But I miss a lot of important points.

In this case, I am not looking at the code of squeak BabyIDE (it was not DCI and it is far complicated to read). 

But I am looking  at the user interface  BabyIDE in squeak to get the user mental model.

And use Prokon as the great example to follow when I need.

" look at the big picture, and focus on the human level when writing your initial use cases"

Some how when I write the use case at this level, the info I get is not very useful to form the Context (no Role, no interaction...)

( I do have the use case at this level)

The 2nd level of use case is more useful to code the Context. (with more details)

I think we did discuss about mixing different level of mental model before: https://groups.google.com/forum/#!topic/object-composition/A6eMbBsBgSI

This is also the point that I hate to maintain 2 different levels for just 1 use case (user mental model use case vs context friendly use case).

When I update 1 I need to update the other.

What is your suggestion in this case?

/quang

To unsubscribe from this group and all its topics, send an email to object-composition+unsub...@googlegroups.com.

[Andreas Söderlund]

The initial excitement from opening a file in a new program will probably fade soon, I think. :) And then you'll need real value to keep the user happy. Opening a file won't do much by itself, the value comes from a longer process than that. Like sending an email or making a money transfer.

/Andreas

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

[Matthew Browne]

On 1/2/15 10:45 AM, Andreas Söderlund wrote:

The initial excitement from opening a file in a new program will probably fade soon, I think. :) And then you'll need real value to keep the user happy. Opening a file won't do much by itself, the value comes from a longer process than that. Like sending an email or making a money transfer.

I think the "real value" in this case is to be able to easily visualize the roles and interactions of a system operation, and to have some of the DCI source code automatically generated.

Quang originally called the use case "Parse Context File", which isn't actually a use case at all from the user's perspective - it's a system algorithm. The real use case might be called something like "View Visual Context Overview".

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/IzoIo5kFv1c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.

[Hai Quang Kim]

You are right.

It should be View Context File or Visualize Context File or just simply Open Context File. (it is still something very important for user)

I was working on the Parse Context File use case (habit), and I didn't mention them all in one place.

Below are all of the use cases.

I) Use case: Open Context File (View Context File/Visualize Context File)

1) User wants to open a Context File in Editor  (right click to trigger a menu command)

2) System reads Context File for Context Info   (sub use case)

3) System displays Context Info in the Editor    (sub use case)

II) Habit: Read Context File   (not in user mental model any more, will be in software designer or programmer mental model)

(interaction style)

1) RegionReader reads all Region Info

2) ContextReader reads Contex Info from Context Region

3) UsecaseReader reads Usecase Info from Usecase Region

4) RoleReader reads Role Info from Role Regions

III) Habit: Display Context File  (algo style, not interaction style yet)

1) System displays Usecase Info in Editor

2) System displays Interaction Info in Editor

IV) Usecase: View Role Method

1) User wants to view the Context of a Role Method  (select a Role Method from the Interaction Graph)

2) System displays Role Method Content in the Editor (partly code view)

V) Usecase: Edit Role Method

.......

Many of them are Habits, just some of them are use case (involved a user trigger).

The way I implement them is: One Context for I) and inside it, I have 2 roles which are 2 Habits for II) and III).

class ContextFileOpeningContext

{

    Role ContextFileParsingContext Parser;

    Role ConextFileDisplayingContext Editor;

    Role DCIContext ContextFileModel;

}

class ContextFileParsingContext 

{ 

    Role RegionReader;

    Role ContextReder;

    .....

}

class ConextFileDisplayingContext 

{

    Roles

     ...

}

I am still playing with the code. One of my fear while doing the Context is: I was worrying about Which Object can play that Role, do I have it or not?. (the emptiness form feeling????)

Should I worry about that or just go forward with the Role and don't care about who gonna play that Role?

For example: I don't have any Object they can play the RegionReader logically (from mental model point of view).

I end up with using the Context Object to play the Role, then changing to use ContextFileModel.

/quang

...

[Hai Quang Kim]

Some update on my progress:

The SharpDCIIDE inspired by Squeak BabyIDE

https://github.com/wangvnn/TheDCIBabyIDE

- Current state:  phase 1 -> Read a Context file and visualize it with interaction graph, be able to zoom in each method, interface to change the code.

- To do: phase 2: be able to add new Role, methods, interface... from the graph.

hope this may help :)

/quang

some screenshots:

/quang

...

[Matthew Browne]

Hi Quang,
I have been busy lately (and I'm guessing others on this list have as well), but I wanted to pick up the earlier discussion about implementing BabyIDE...regarding the steps you listed for "Read Context File":

1) RegionReader reads all Region Info

2) ContextReader reads Contex Info from Context Region

3) UsecaseReader reads Usecase Info from Usecase Region

4) RoleReader reads Role Info from Role Regions

Given the names of these roles it seems to me that maybe they're nested contexts rather than simple data objects playing these roles. This reminds me of an earlier discussion I had with Jonah S. Here are some relevant excerpts from that thread:

On Friday, April 18, 2014 at 9:14:38 AM UTC-4, Matthew Browne wrote:

...complete opposite from the emphasis on data that is often presented as a basic tenet of OOP, e.g.:
http://objology.blogspot.com/2011/09/one-of-best-bits-of-programming-advice.html

The odd part is that the above link attributes the advice to Russ Pencin, who apparently was one of the early OO programmers at PARC. I suspect Mr. Pencin is either being misinterpreted here, or he never fully understood the original OO vision.

One thing I will say for the advice of not naming classes ending with "er" is that it would be a mostly good rule of thumb for naming data classes; names that end with "er" are more likely to be roles.

On Tuesday, April 22, 2014 at 10:58:47 PM UTC-4, Jonah S wrote:

> http://objology.blogspot.com/2011/09/one-of-best-bits-of-programming-advice.html
>
> The odd part is that the above link attributes the advice to Russ Pencin, who apparently was one of the early OO programmers at PARC. I suspect Mr. Pencin is either being misinterpreted here, or he never fully understood the original OO vision.

This was actually one of Peter Coad's principles, and, paradoxically, it's intended to ensure that behavior and not data is the focus of an object.  I really like this article on it:

http://www.carlopescio.com/2011/04/your-coding-conventions-are-hurting-you.html

And I don't see any inherent conflict between this view and the DCI dumb object view -- in DCI the -er principle would still apply to role names for the same reasons.  I could be wrong though...

What we were really talking about were "agentive nouns" - nouns based on verbs (which often end in "er" but of course there are exceptions).

I think Jonah was right that agentive nouns are a possible indication of procedural thinking rather than object thinking. This gets a bit confusing in DCI because one of DCI's major goals is to recognize the importance of behavior and the structure of that behavior, and not structure everything based only on the data structure. But still, we want to avoid the other extreme too, or to put it in Trygve's terms, focus not only on "what happens" but also "who does it".

Did you come up with any of your own answers for the role and context organization for BabyIDE? I'd be interested to hear what you've come up with.

Upon a first consideration of this, it seems to me that the roles here should be a mix of nested contexts (especially for the more complex sub-functions) and simpler data objects. An example of the latter might be what you called "RoleReader" - maybe the real role is just "RoleRegion", which could read itself. It doesn't have to always be a separate object, e.g. a "reader" object, acting from the outside to read or manipulate a target object - data objects can also play roles in order to act upon themselves. I hope that wasn't too confusing :)

BTW, a nitpick...I'm not sure your use of the word "habit" matches Cope's definition (I'm referencing Cope's definition as the primary one since I think he invented the term). If I understood his book correctly, he used it to mean a fragment of a use case that's repeated in more than one use case. In UML there's an "include" notation that can be used to include use case steps defined elsewhere. But "include" and "habit" are not synonymous...in UML, you might "include" a sub-function level use case just because it involves a lot of nitty gritty details, and not necessarily because it's something that's used in multiple different use cases -- in other words, it might only ever be used for that one specific use case. I think it would be more precise to call that sort of thing an "internal use case" or "sub-function" rather than a "habit".

P.S. Your other thread about UI frameworks is quite interesting. I don't have much experience building UI frameworks from scratch, so I don't have any comments at the moment other than to say I think you're on to something -- but remember not to make it any more complex than it needs to be :)

--

[Hai Quang Kim]

Hi Matthew,

Thanks for picking this up. 

This is not my excuse to name thing badly, but it is my limitation of knowledge to name thing better :)

Again this topic is too big for my experience, we need other experts to tell us the history and state of the art.

Below is just my humble view of the issue :)

I read Carlo Pescio's blog about the -er class name. I tend to agree with the statement but I am not so sure what I can do about it.

In the post, he mentioned a few examples which come from Microsoft .Net library,....

And we can easily find similar code from other famous library in Java, .Net, Ruby.... almost everywhere.

Naming a class/object is one of the most difficult thing in the OOP. ( I read this somewhere...)

In the water fall process, design and requirement was captured way before the implementation with domain expert, user, architecture...

So I guess people had more time to name things properly.

Nowadays, everyone follows Agile (not sure which one, just Agile in general). That means everything you see may be just the 1st vertical slice (or just 2nd vertical slice...)

And you may never see the final vertical slice :)

My concern is if it is too hard to name class/object right from the beginning, then either the issue is very hard to master, or people don't want to master it. (no real value in some one's perspective like PM)

For example: in sprint 1 I name class/object badly and make it work, in sprint 2 I want to refactor and rename them but I may not be able to convince the team to give me that task.

So yes, in idea world I would like to code, name thing properly but in reality that what we get until we have a better way to name it properly since the beginning.

So for now I just focus on learning the process to do DCI rather than focusing on the its artifacts (even though good name, or elegant code will helps).

After this exercise what I learn is:

1) working with user/designer to write use case in procedural way

2) turning procedural use case into object oriented use case

3) code use case in context class (Role, Role Methods, Nested Context...)

4) code data class

At each steps, good software engineering is required including good domain analysis, good naming.... 

All of these are very hard to master, and to be honest I am still far from good at those skills and I am still learning :)

For example: Step 1 is a good chance to have good name if the team have the 'will' to analyze and name thing together.

From my bad experience, users don't care too much about internal name, so programmer just follow convention and name thing like parser, reader....

until later on programmers have a better name but no time to change (picking new tasks)

Back to your question:

Below is what I have for Context Reading Use case:

Use case 1: View CONTEXT FILE

1) USER selects CONTEXT FILE to view

2) SOLUTION EXPLORER finds SELECTED CONTEXT FILE

3) CONTEXT FILE PARSER parses CONTEXT FILE to get CONTEXT MODEL (nested context 2))

4) CONTEXT FILE EDITOR displays CONTEXT MODEL

Use case 2: Parse CONTEXT FILE

1) READER FACTORY reads IDE SETTINGS to create suitable READER

2) READER reads and returns CONTEXT MODEL (nested context 3))

This context allow user to change settings to read different kind of context file (injectionless, marvin...)

Use case 3: Read INJECTIONLESS CONTEXT FILE

1) REGION READER reads all REGIONS

2) CONTEXT READER reads CONTEXT INFO

3) USECASE READER reads USECASE INFO

4) ROLE READER reads ROLE INFO

5) INTERRACTION READER read INTERACTION

So i guess I can improve the naming for those Reader Role. I will re-read those posts and think again :)

If you have time to play with it, the code is here for visual studio community 2013. 

https://github.com/wangvnn/TheDCIBabyIDE

Some screenshots:

usecase 2:

usecase 3:

usecase 1

/quang

...

[Rune Funch Søltoft]

I have often found that the -er roles are good role method candidates. That was the basis for a few of my rewrites of the maroon gem

Mvh

Rune

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

[Hai Quang Kim]

that is interesting, can you help to give an example?

in the old OOP, we usually extract big function of a class into smaller class.

this is a typical example of parser: https://github.com/Instagram/ig-json-parser/blob/master/processor/src/main/java/com/instagram/common/json/annotation/processor/JsonAnnotationProcessor.java

my Context Parser is quite close to the above code. I just break the big Role into many smaller Roles: RegionReader, RoleReader....

/quang

...

[James O Coplien]

On 23 Feb 2015, at 15:36, Hai Quang Kim <wan...@gmail.com> wrote:

that is interesting, can you help to give an example?

in the old OOP, we usually extract big function of a class into smaller class.

this is a typical example of parser:

Why is a parser an object?

It seems to me like it has one operation: parse.

If it flies like a procedure, walks like a procedure, and quacks like a procedure — use a procedure. There are lots of good paradigms. When God created the world, she didn't use just objects, and there's no reason for us to do so, either.

[Hai Quang Kim]

https://lh4.googleusercontent.com/-ctrcN3AdIUQ/VOrFyN4VUvI/AAAAAAAAAHA/RLz6wmaQ-ZU/s1600/contextreading1.JPG

In this picture, I have ContextFileOpeningContext with  Roles:

- ContextFileParser, ContextFileEditor, SolutionExplorer, a lot of -er Role(s) :)

In that Context, I have ContextFileParser which is a Role with method Parse.

The Context File Parser is a nested Context (ContextFileParsingContext)

https://lh5.googleusercontent.com/-6Su9taE-t3A/VOrF10hnkJI/AAAAAAAAAHI/BkxQw8dh9aQ/s1600/contextparsing.JPG

This context has Roles:

- IDESettings, ReaderFactory, DCIContextReader (can be InjectionlessReader, or MarvinReader)

The InjectionlessReaderContext is another nested Context: InjectionlessContextReadingContext

https://lh5.googleusercontent.com/-uEg27X1-ahc/VOrF4o-oyeI/AAAAAAAAAHQ/3Pc4kQz0_2o/s1600/injectionlesscontext.JPG

Which has Roles:

RegionReader, RoleReader, InteractionReader, a lot of -er also :)

My 1st version of this parser is procedural programming with public function Parse and a lot of sub functions.

That was the time I was asking why we need interaction of Role objects in Context while procedural programming is good enough.

After a few times refactoring the code to have those Roles, I got the 'ah ha' moment why we need Role object.

Those Roles compress the info, I just need to look at name of the Role in the diagram I can remember what it does :)

Any way this is my mental model. I understand that I name a few things badly due to convention I learnt around.

I just read the blog and all the comments:

http://objology.blogspot.sg/2011/09/one-of-best-bits-of-programming-advice.html

This comment is interesting defense: ( I should have ContextFileParser not simple Parser according to this comment :) )

"AnonymousSeptember 26, 2011 at 10:53 AM

This is a correlation-causation problem. The fact that you have a high correlation of words that create poor OOP concepts does not imply that they are the cause of such a poor name. Perhaps you should take a step back and look at what you're saying *without* the emphasis on the last two letters of each word.

The 'er' suffix is not the problem with a term like Loader or Manager. It's the vagueness that is the problem. What kind of Loader? What kind of Manager? Some words are inherently vague, like "Component", which, by the way, does not end in '-er', but should also be avoided. Some other words (ending in '-er' and not) might be vague but are integral because they represent well known concepts in computer science and engineering. Parser and Compiler are obvious ones-- tacking them on the end of a class should immediately let us know what the class is for. The same goes for Controller, because it is a well known pattern. These "-er" terms convey meaning that improves the understanding of your domain model. I couldn't imagine a replacement for Controller that would convey the use of a controller pattern so obviously. Why would we throw out 20+ years of design patterns? If you cannot accept the idea that names also act as cues for the patterns we use, then you are missing an integral part of building maintainable code.

You also made no argument about qualifying these names. Yes, "Loader" itself might be vague, but is "DiskFileLoader" all that vague? If I just called a class "Factory" (doesn't end in '-er'), just /^Factory$/, I would be chastised for improperly naming the class. Yet if I qualified it, PersonFactory, this is considered almost unanimously acceptable (unless you just hate the Factory pattern), even by you in this article, it seems. What is the difference? Qualification in both cases makes an otherwise vague word into an understandable concept. This shows that '-er' has nothing to do with understandability of the name.

In short, what you've basically said is: "Don't name things vaguely". We've known this rule for a long time."

While learning DCI, I have chance to relearn a lot of basic things from this forum.

Especially a lot of good things from Cope (even though sometimes it took me a long time to understand what you try to teach :) )

 

So please help to give suggestion on this very hard topic: how to name thing in the Context (Role, Role Method.....)

In this example I have code, diagram and a well-known problem (DCI Baby IDE porting)

So I hope it is easier to discuss.

/quang

[Rune Funch Søltoft]

Two questions. Why isn't your contextfile playing the role with a parse role method?

I dont agree to the comment that it's the varieres that's the problem. -er classes very seldom model some actual object but almost always are an OO-fications of a procedure. It's a verb turned into a noun so that we can speak of it as it was an object but it isn't ContextFileParser isn't vague but it's not a thing/object either. It's an OO encapsulation of a procedure related to an object ie the context file. As I commented earlier I find that many -er classes are role method candidates

--

[Hai Quang Kim]

To make the discussion more interesting I quote some rules I got from the blog:

http://objology.blogspot.sg/2011/09/one-of-best-bits-of-programming-advice.html

1) Procedural programming focus on Verb (function) then Noun (Data)

2) OOP focus on Noun (Class/Object) then Verb (behavior in Class/Object)

http://steve-yegge.blogspot.sg/2006/03/execution-in-kingdom-of-nouns.html

- here the author is crying for too many nouns in Java OOP

I remember DDD try to get back the Verb(s) which was lost by TransactionScript or Table Module...

http://martinfowler.com/eaaCatalog/

Yep that is the current state of OOP, too many rules :)

I think it is interesting to discuss these rules for DCI.

/quang

On Tuesday, February 24, 2015 at 4:27:02 PM UTC+8, Cope wrote:

[Hai Quang Kim]

interesting question:

1) Why isn't your contextfile playing the role with a parse role method?

- my context file is just a file path. I remember there was example that we injected method into a List of Activities (Role Activities)

so I guess we can inject parse method into file path string object.

in my case the ContextFile Parser is a nested Context which has Role Method: ParseContextFile

- maybe this is the one you are looking for: I have ContextFileModel which is the Data Object of a Context File.

- in the ContextFileReadingContext I actually use ContextFileModel to play the Role of Reader(RegionReader, InteractionReader) and inject Read method into the Data Object.

In short, I was almost there, just need to change those Reader(s) into the Object(s) it tries to read: Region, Interaction, Role (DCI Role)

And the inject method Read (or Parse) into ContextFileModel so that it can play those Role(s).

So instead of using ContextFile (file path) I am using ContextFileModel to play those Role(s).

Is that better?

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[James O Coplien]

On 24 Feb 2015, at 15:46, Hai Quang Kim <wan...@gmail.com> wrote:

so I guess we can inject parse method into file path string object.

It's a curious Domain Analysis that would conclude that string should have  parse as a method.

[Hai Quang Kim]

with DCI I see a few unusual things like this:

- inject Role Method(s) into string object or list object. (Data Object that will play the Role in a Context)

maybe this is the hard point for paradigm shift.

I definitely need to rethink about this.

/quang

[Matthew Browne]

On 2/24/15 9:32 AM, Rune Funch Søltoft wrote:

I dont agree to the comment that it's the varieres that's the problem. -er classes very seldom model some actual object but almost always are an OO-fications of a procedure. It's a verb turned into a noun so that we can speak of it as it was an object but it isn't ContextFileParser isn't vague but it's not a thing/object either. It's an OO encapsulation of a procedure related to an object ie the context file. As I commented earlier I find that many -er classes are role method candidates

I think the key here is that Rune is talking about role methods, not necessarily the name of the role itself. When I read his previous post I glossed over that too, but now it makes more sense to me.

As has been discussed, if you're trying to turn a procedure into an object, you might end up with a name like "parser". Let's suppose the data object is "ContextFile". The simplest solution might be to just use "ContextFile" as the name of the role, and give it a role method called "parse":

role ContextFile {
  parse() {...}
}

This is what I was referring to earlier when I talked about a role enabling an object to do something to itself.

But I can also see the scenario of a second object acting upon the ContextFile object. This might be helpful if there are a lot of sub-functions involved in parsing and it makes sense to have that as a nested context. So you could have a nested context called "ContextParser" or "ParseContext". Let's say the main use case is "Load and Visualize DCI Context File". "ContextParser" could then be a role within the context for that use case, e.g.:

parser = new ContextParser(ContextFile); //instantiate the nested context
parser.parse();

So in summary I would say that if a role name ends in "er", it's most likely more of a procedure than an object, which means that instead of being played by a data object, it should either be a role method (rather than a role itself), or nested context (which is essentially just a bigger procedure that happens to have multiple role players involved in order to do its work). Of course there are exceptions to every rule, especially when it comes to the English language...

[Hai Quang Kim]

thanks Matthew, I agree with your conclusion.

That is exactly what I have:

- ContextParser is a nested Context.

- RegionReader should just be Region Role with Read method and played by Context File Model data object.

so the rule from this: http://www.carlopescio.com/2011/04/your-coding-conventions-are-hurting-you.html

actually works.

"However, it's quite simple to fix, basically like Peter Coad said: remove the -er, look for the "managed" object and put the responsibilities there."

So I removed Reader and just use Region as a Role with Read method :)

/quang

[Egon Elbre]

But why not have a function with roles (i.e. context function)?

context = parseContext(ContextFile)

If an object has a single method, it probably should be a function.

I would think that the same applies to context objects.

+ Egon

[Matthew Browne]

On 2/24/15 10:31 AM, Egon Elbre wrote:

Let's say the main use case is "Load and Visualize DCI Context File". "ContextParser" could then be a role within the context for that use case, e.g.:

parser = new ContextParser(ContextFile); //instantiate the nested context
parser.parse(); 

 

So in summary I would say that if a role name ends in "er", it's most likely more of a procedure than an object, which means that instead of being played by a data object, it should either be a role method (rather than a role itself), or nested context (which is essentially just a bigger procedure that happens to have multiple role players involved in order to do its work). Of course there are exceptions to every rule, especially when it comes to the English language...

But why not have a function with roles (i.e. context function)?

context = parseContext(ContextFile)

If an object has a single method, it probably should be a function.

I would think that the same applies to context objects.

+ Egon

Yes, that could work too. I think it just depends on the language...in some languages it might not be as easy to do a DCI implementation where functions can be contexts. Also in some situations you might want multiple instances of a context class, or you might have a stateful context with multiple trigger methods, so the context would be an object rather than a function. But many use cases just have one trigger method and in those cases implementing the context as a function is more straightforward.

[Matthew Browne]

I forgot to mention the most significant language barrier to using a
function as a context: some languages don't have top-level functions at
all, they only have classes and methods. Quang is working in C# so I
think he is limited to using classes for Contexts.

[Hai Quang Kim]

it has a single public method with a tons of private methods :)

- Parse()

  - ParseRegion()

  - ParseRole()

  - ParseContext()

  - ReadSettings()

  - CreateReader()

  ....
That how Parser class become big and complex. I try to convert a procedural class into interaction of Roles in a Context:

- SolutionExplorer  (real one from Visual studio :) )

- IDESettings

- ContextFile

- ContextFileModel

- ContextFileParser (or just ContextFile)

- RegionReader (or just Region)

- Editor

......

They form a list of vocabularies in my Domain and interact with each other to achieve a goal: Display/Visualize a selected DCI Context file in Editor.

/quang

[James O Coplien]

I think you should conceptualise this in a different way.

These are not methods; they are procedures that are vulgar implementations of parse rules.

I, too, am working on a parser right now. It's a proper parser in Bison. It has over 200 productions in its grammar. I write the grammar in a design paradigm for writing compilers. It compiles automatically to a procedure called yyparse, which is the only exported symbol from the parser. (I need to limit the number of external symbols, and particularly of data, because the parser needs to be re-entrant. But, indeed, it is one procedural API.)

I think you are doing the same. You are manually the rules of the grammar to the action rules, and then you are trying to fit the compiled entities (the APIs you list below, which are procedural) into an object framework called DCI. So you've taken a good design paradigm (rule-based design using language productions), reduced it to its assembly language (the procedural action routines) and are trying to fit the object code into yet another high-level design paradigm (objects) which is poor at expressing both the original rule-based grammar and its manually compiled procedural reduction.

I guess I'd ask: Why?

[Hai Quang Kim]

That is true.

My first feeling for that ContextParser is simple:

Usage:

Parser.Parse(filePath, out ContextFileModel)

Implementation:

static class Parser

{

public:

     void Parse(string path, out ContextFileModel)

private:

     all of the sub-methods are here.

}

You are right that I am trying to learn DCI and try to see if  I can break that procedural class (1 API) into something interesting like interaction of Role(s)

So I made them up :). I understand that I am trying to shoot everything with DCI gun now :)

Actually if you look at Prokon example from Trygve, he was trying to use DCI at different levels, so I just try to follow that path and see how it goes.

But I am not sure if that a bad thing or a good thing?

Actually everyone will have different approaches/mental models to solve a problem.

One can use multi-paradigms, one just uses procedural programming only or DCI only.

For now I am just playing with DCI, and try to use it for everything :)

/quang

[James O Coplien]

On 25 Feb 2015, at 11:13, Hai Quang Kim <wan...@gmail.com> wrote:

That is true.

My first feeling for that ContextParser is simple:

Usage:

Parser.Parse(filePath, out ContextFileModel)

Implementation:

static class Parser

{

public:

     void Parse(string path, out ContextFileModel)

private:

     all of the sub-methods are here.

}

Mine is an order of magnitude shorter.

Usage:

yyparse(scanner_token);

implementation:

void yyparse(yyscan_t scanner);

You are right that I am trying to learn DCI and try to see if  I can break that procedural class (1 API) into something interesting like interaction of Role(s)

I don't think that's what we designed DCI to do. I am not sure you will learn anything on this road. If you do learn something I fear it will be to learn something bad.

To learn DCI I suggest starting with more straightforward examples.

[Hai Quang Kim]

yep, I will revisit all of the examples after trying different things.

especially the Dijkstra algorithm example.

as far as I remember procedural programming was doing good for it.

I will redo it with DCI and compare the 2 versions to see what is the difference.

/quang

[Matthew Browne]

On 2/25/15 6:04 AM, James O Coplien wrote:

To learn DCI I suggest starting with more straightforward examples.

+1

On 2/25/15 6:13 AM, Hai Quang Kim wrote:

yep, I will revisit all of the examples after trying different things.
especially the Dijkstra algorithm example.
as far as I remember procedural programming was doing good for it.
I will redo it with DCI and compare the 2 versions to see what is the difference.

This is a step in the right direction, but after that it would probably be good to do your own simple project in DCI. If you want to continue tackling BabyIDE in DCI that's up to you, but having seen all your questions about that I agree with Cope that it might not be the best learning experience...and you'll probably end up rewriting the whole thing later. Analogy: better to run some short races before trying to run a marathon...

[Hai Quang Kim]

I did try most of them. (most of them are too simple anyway)

The biggest (most complete) example is Prokon.

I just wonder have any one tried to read Prokon in details?

I even port it to C# for the sake of learning.

That why now I am trying to apply it somewhere else it real work example.

Of course with a new tool I will try something wierd and will make some mistakes.

And I hope I will learn something from those mistakes.

I know DCI works best with high level use case not low level.

But I would like to explore this path.

Like what I said in the UI framework thread. I try to think everything as an MVC.

M will be Data Object.

The C will be a state machine with a decision table and will trigger a Context for each event (changes in the M)

The View is just derived data of the M.

I don't know how far It will go, but so far I like the idea :)

/quang

[Matthew Browne]

I meant creating your own example or alternatively applying DCI to a relatively simple real-world project. Studying the available examples is a great place to start, but now I think you're ready to do the whole design process rather than starting with code that someone else has already written and working backwards from there. You can learn much more doing the whole process on your own.

As to the rest of what you said: yes, I wholeheartedly agree that DCI can be useful beyond the outermost use case layer. Your idea of using DCI for a UI framework is promising. But business use cases are best for learning DCI principles - I think applying it elsewhere successfully requires already having solid experience with simpler cases. Also there are some places where DCI simply isn't a good fit. Based on Cope's comment about your BabyIDE design, maybe pure procedural programming would be fine for the parser portion but the rest of it could use DCI...just remember to be open-minded and allow for the possibility of mixed paradigms or not using DCI at all in some cases.

--
You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/IzoIo5kFv1c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.

[Hai Quang Kim]

yep that is a good conclusion. thanks for reminding me to not go to far.

my 1st version was procedural code for the parser.

I like that version at first.

Then I tried the DCI version and a like it.

So it just the matter of taste at some point of time :)

But In general, I agree with your suggestion.

/quang

To unsubscribe from this group and all its topics, send an email to object-composition+unsub...@googlegroups.com.