Basics of software design

On the ALT.NET email list there was a question about how to present Agile/OO Design to peers. Much of the advice centered around presenting principles like OCP, SRP, Demeter, Liskov, etc. However, while its good stuff, I don't think it hits at the heart of designing software... Also in the world of postmodern software design I think that some of the old guiding principles need new interpretations :-)

This was my advice... ( which is pretty rough )


From my experience none of the so called "principles" are good starting points. They are secondary ideas that reinforce the main idea.

Separation of concerns is a key idea.
Secondly we want to Compose Behavior together.

So we want to TDD concerns.
We want to TDD composition of concerns

Identifying "Concerns" is about finding abstractions.

Finding a name for an abstraction :-
Having conversations to find key abstractions. Making sure you take more note of behavior and less on Nouns. (Nouns trip people up)
Refactoring common behavior to find abstractions and then naming it

Understanding Concreteness vs Abstractness
Understanding Cohesion and Coupling
Understanding the different levels of Perspective (conceptual, specification and implementation)

Then!

- Principles come in and reinforce ideas about abstraction, what a "concern" is, what composition is, how things should be composed.
- Design Patterns support abstract composition of concrete concerns.
- Things like DDD helps formulate the way you have conversations about "concerns"

Alternatives to OO

- Functional Programming has different composition mechanics but the same ideas of software design of separating concerns, finding abstractions, and composing software together.


To present this to people...

You need to show examples of it in action