The Artima Developer Community
Sponsored Link

Articles Forum
The DCI Architecture: A New Vision of Object-Oriented Programming

119 replies on 120 pages. Most recent reply: Jan 7, 2012 3:19 AM by Thorin Potjes

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 119 replies on 120 pages [ « | 1 ... 117 118 119 120 ]
Thorin Potjes

Posts: 1
Nickname: thorinp
Registered: Jan, 2012

Re: The DCI Architecture: A New Vision of Object-Oriented Programming Posted: Jan 7, 2012 3:19 AM
Reply to this message Reply
Advertisement
> I read the article with great interest and I salute the
> authors for taking the time to write it. However, from the
> article:
>
> "Object-oriented programming languages traditionally
> afford no way to capture collaborations between objects"
>
> to which I respond that a bad workman blames his tools!
>
> It is your choice to create and use objects for whatever
> you want to, including capturing the collaborations
> between objects. In fact, this is the heart of OO. When
> you model an object and have it interact with another you
> can choose to model that interaction as another object
> with a simply method invocation to carry out the
> interaction, or you can create no object and call a series
> of methods. A lot of this is captured in the OO principle
> Tell Don't Ask but most people just Ask, ignoring the
> benefits of Tell all together.
>
> For example:
>
> address.to_string() <- simplistic - why do you need a
> string?
> address.printOn(medium) <- OO, capturing the interaction.
> You can also take this further with an object that
> represents the process of taking an address and putting it
> onto medium.
>
> I wrote a lot about this in several posts on my blog about
> a technique I call East Oriented -
> http://jamesladdcode.com/?p=12
>
> We have failed OO, it has not failed us.
>
> - James.

Totally agree with this post.

The assumption in the article seems to be that an 'object' has to represent something that can be stored in a database (> object boundaries already mean something else: they are loci of encapsulated domain knowledge, of the data <), which is a too narrow view of what objects are.

If you have a high level action you want the application to perform, why not just use the Command Pattern, which encapsulates an action as an object? To prevent strong coupling between this Command object and the objects on which it operates, you can implement the Commmand object as a Composite Pattern, where a high level Command consists of series of lower level Commands.

A high level Command could represent the transferral of money from one bank account to another. At a lower level, the Command object representing the actual money transfer will tell one Account object to lower its balance, and the other Account object to increase its balance.

If DCI tries to solve the problem of not being able to capture interactions between 'objects', I think this problem has already been solved by the Command Pattern, using OO principles.

Flat View: This topic has 119 replies on 120 pages [ « | 117  118  119  120 ]
Topic: Effect Choreography in Flex 4 Previous Topic   Next Topic Topic: Cooperative Visitor: A Template Technique for Visitor Creation

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use