BT

InfoQ Homepage Presentations Reflections on Reflection

Reflections on Reflection

Bookmarks

Bio

Jim ("Cope") Coplien is the father of Organizational Patterns and one of the founders of the Software Pattern discipline, a pioneer in practical OO design in the early 1990s and is a widely consulted authority, author, and trainer in the areas of software design and organizational improvements. With Trygve Reenskaug he is a co-originator of the Data, Context and Interaction (DCI) paradigm.

About the conference

SPLASH is the ACM conference on Systems, Programming, Languages and Applications: Software for Humanity. SPLASH is an annual conference that embraces all aspects of software construction and delivery. This is the premier conference at the intersection of programming languages, programming, and software engineering.

Recorded at:

Mar 01, 2013

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Reflections on Reflection slides

    by Carlos Silva /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great talk!
    Some slides have superimposed texts. Can fix?
    Thank you. I will read your book again e try hard, now...

  • How about using AOP to implement this

    by Wouter Hermeling /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    To implement the behavior of the use cases into the objects, can AOP be used for this. Any thoughts/comments on this?

  • Fail to see how DCI affects User Experience

    by Adam Nemeth /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I normally agree with Coplien, but I still fail to see how DCI helps us build a world keen to Alexander's vision of his IEEE talk.

    I think, or rather, I believe, that the way to catch end user's mental models is to sit down with them and speak to them a lot and design in front of their eyes.

    What does it mean? Watching them use the previous systems. Making them talk about their realities. Show them drawings. Ask them to play make-believe with those.

    For the user, the user interface is the software. His/her daily life is the system. Anything behind the user interface? Doesn't matter to them.

    We should design for the real problems. We shouldn't use abstract words. We abstract them out later. Of course we abstract them out! But we should be able to show the code afterwards to a user, to any user basically, and they should be able to reason about it, and understand how it's connected to their daily life! I call it the "janitor test", and I regularly do it (hint: first remove type declarations: users don't need that).

    Classes were never about object orientation: they are a way to structure code. It's a way to put things into a logical structure! Forget Alan Kay, the way we use classes is how it's written by Dahl in Structured Programming from 1972! Is it wrong? It's fine! It's about put the code where you expect to find it! Put things together which change together.

    Just like we expect users to be able to find the thing they need right now in a menu structure of a large webpage (think of a government site or such) we build code hierarchies primarily to let programmers find it quickly!

    Of course, we should still build code where we can reason about behaviour. You press a button - you should be able to look up what that button does in the sourcecode just by looking up the file structure.

    But that's through process and not through structure! Remember what Alexander said in Nature of Order: forget the structure, a structure is only good as the process it was born through! Concentrate on your design process instead, make sure that every single part of that design is about the central topics of the problem you design against!

    I fail to see how could we make user-reconfigurable systems if we build context into the whole model. If you build your system around context, how do you expect users to use its elements out of their designed context?

    I don't believe everyone should be an architect, but I believe we should design architecture - and let me use a strange definition: architecture is whatever a user can't change for themselves as it'd cost a lot of effort, knowledge, or tools - in a way that users don't even think about it.

    I usually say I like to design tapwater applications: when you open the tap, you don't even think about wether the water would flow. It's not natural, especially for high-rise buildings. But it's so well-designed, that for 364 years a day, you don't even have to think about it, and you can reconfigure it to whatever purpose you see it fit, cooking bathing or anything else.

    Sometimes I feel that as the developer community as a whole neglected users, the design of our actual buildings - the software - is into the hands of UX designers, and developers are merely the construction workers making dreams a rigid reality.

    But I hope this won't be about putting the bolts together for that long. Would DCI be the way out? I'm sorry but I can't see that still.

  • all data can be viewed as conversational state enclosed in boundaries

    by William Louth /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What I have come to realize is that all data (or state) is is created and managed in the context of some conversational boundary that can span many interactions and have a time window of relevance that goes from nanoseconds up to years. These conversations can represent a contract or a transient association but it is the conversations and the signals that are enclosed within them that can drive runtime adaptation (behavior) - it is this that turns a class into an object.

    Signals approach to what DCI is tackling is based on self organization, self regulation and self adaptation.
    www.jinspired.com/site/introducing-signals-the-...

    When I first came across this talks title I was hoping to see that reflection would be revisited in terms of behavior and not state or structure (as exposed by classes). There were hints of this possible direction but sadly nothing of significance. What is lacking today is self awareness and the ability to reflect on past, present and predicted behavior.

    Going Beyond State/Structure Reflection in Java with Behavioral Tracking
    www.jinspired.com/site/going-beyond-state-struc...

    From Anomaly Detection to Root Cause Analysis via Self Observation
    www.jinspired.com/site/from-anomaly-detection-t...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.