Sorry for the long name. I didn't know where to put this. A while back I wrote this out:

	* value - a number or character. immutable
	* collection - holds values. it's owner keeps track of it's state. mutable
	* responder - keeps collections. other's observe it's state by sending #addObserver:. has only one process
	* process - keeps responders. has it's own thread of execution
	* server - has it's own memory. owns processes

It's a sort of hierarchy of object functionality. You can usually pick up a program and categorize all classes into this.  The classes that are higher up are more important for understanding how the program works.

I thought it might be interesting to create a framework that has these as abstract classes.

Also, it might be an interesting way to do top-down design. You create your servers. Then you create processes and so on.  Prototype programmers would of course create the minimum of the lower level so the program would run at all times during design.

----

''Also, it might be an interesting way to do top-down design. You create your servers. Then you create processes and so on. Prototype programmers would of course create the minimum of the lower level so the program would run at all times during design.''

This sounds to me like just applying good ol' fashioned StepwiseRefinement or perhaps something a bit more formalized like HIPO, both of which essentially take an n-layered approach to the system with each layer defining successive levels of detail in the system. I've used this approach for StructuredProgramming and particularly well with ModularProgramming although I've never really considered an adaptation of StepwiseRefinement to ObjectOrientedProgramming simply because ObjectOrientedProgramming tends to have better (?) ways of refinement within the system, i.e. inheritance and polymorphism (perhaps this is what you're referring to indirectly?).

I've not done much ObjectOriented development lately, so I'm a little rusty and couldn't tell you whether or not the general premise of grouping classes in such a hierarchy is a OneSizeFitsAll solution or not.

Also your development approach possibly sounds related to JustInTimeProgramming? Perhaps someone else could clarify.