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!

Comments

  • Anonymous
    June 23, 2004
    The comment has been removed
  • Anonymous
    June 23, 2004
    Would it make sense to split up the method's representation along the following lines:
    1) information that is proper to the method (model)
    2) location, location specific information, formatting (view)
    3) manipulation (controller)

    I would imagine that there are multiple #2s since a method exists simultaneously in multiple contexts (editor, il, jit). Also, you could consider all methods on method to be non-side effecting, and then move manipulation methods into a 'builder' class such as #3.

    What do you think?
  • Anonymous
    June 24, 2004
    I think you are correct to have two classes for representing classes: one for compiled types, and one for types for which source is available. They each have a different representation and a different backing store (compiled types comes from an assembly, and "uncompiled types" come from a source code file). You should, however, have an interface that describes the functionality common between both "types of class" and have both of the "class classes" implement it. This will allow compiled classes and source classes to be treated uniformly when possible. This may also allow representation of other types of classes such as Web Services Proxies, "data classes", remoting proxies, and other meta-data derived classes without having to prematurely generate source code.