Share via

Thinking about objects; thinking about C# editing

  • Article

I’ve read the first 7 chapters of Object Thinking. I’ve still got a lot of questions, but I’m liking it so far. Today I talked with Renaud about some of the ideas & the problems we work on.

The first step, says West, is to understand how users think & work in the problem domain, in terms of objects. I’m going to play the role of C# Developer for the time being.

The “Editor” is a centralized controller, a violation of object culture tenets. “Editing” is an activity, not an object in the domain.

Here are some objects that I think you interact with:

  • class
  • source file
  • project
  • method
  • statement
  • expression

To contrast, in the C# editor code today we have a “Signature Change Engine”, to provide Remove Parameter, Reorder Parameters, Promote Local Variable. It’s a controller object, not an object in the domain.

We also have one object for a class in the parse tree, and another for a class in the type tree. As far as I can tell, in object thinking there would just be one object for a class.

We then talked about methods. We tried to brainstorm the kinds of behaviors you might expect of a method:

  • Tell you its name, parameter list & return type
  • Tell you its location in source code
  • Tell you its body
  • Tell you its attribute list
  • Tell you about all of its references (calls to this method)
  • Format itself
  • Move itself to a new class
  • Reorder, Remove, or Add parameters

(The first 4 should probably be “Describe itself”).

This is a pretty different way of thinking about things for me.

There are also some conflicts here that I’m not sure how to resolve. For example, I want my objects to be as simple as possible. How can I write such an object and have it fit comfortably on a single screen?

I’m going to have to think about this a lot more. If you have any insights to offer, please do!