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
Wednesday, 12 December 2007
Tuesday, 4 December 2007
Weapon of Composability
Further to my recent post on programming weapons and categories of said weapons.
Composability
This is probably the most lethal of programming weapons/tools. This is the idea you can join bits of software together to achieve some goal.
The easier it is to compose software together the more "powerful" the tool.
The most obvious of these tools are languages. The popular players in terms of composing software together are functional languages, OO languages, dynamic languages, and hybrids. Each approach the problem slightly differently. It's worth mastering a number of these. This stuff is fine grained control of how software joins up and does something interesting
Another tool of composobility is Frameworks. These allow the user to wield a lot of precreated software in a very controlled way. Again, these are bread and butter stuff for most software developers.
DSLs are languages that match a particular problem domain and often leverage both frameworks and languages to achieve its end. This allows for an easy composition of ideas in the context of a particular domain. Gainning lots of traction these days.
Software Factories. These are similar to DSLs in that they tend to allow you to compose framworks and languages together in very quick ways. Factories can cut across many domains. Essentially you dial in what kind of software you would like and it will spit out software that does it. Currently there tends to be a lot of tweaking and the resulting software can be overly bloated, but if there is a factory that matches the type of soloution you want to create then its going to compose a lot of software very quickly for you.
Wizards. Can be great for creating chunks of software. Kind of like mini factories. I think a lot more could be done with these. Mostly software developers have very little control over these. I think if these were a lot easier to customise or make context aware they could be a lot more powerful.
Operating Systems / Open Standards. Things like *nix have a very composable runtime system. There are also many open standards for how things should talk together all of which has tooling and support for creating said systems
Application Scripting. A peice of software which essentially provides a framework for controlling it
Application Plugins. A peice of software which provides a framework and/or open standard for writing extentions to it.
Editors are the ultimate tool for actually composing software together. This is probablly 80/90% playground of software developers. It is worth being a master of your editor. I feel it also pays to at least appreciate multiple styles of editor also.... Vim / Xemacs / (Visual Studio, Eclipse, IntelliJ )
This is but some of the composobility weapons we get to employ as software developers. The essence of being a good software developer tends to being able to create good designs / acrchtetures / structures that allow software to be composed easily and utilising the right tools for the job. The techniques for how to go about doing this comes under "thinking weapons". And of course all this gets pretty hard to do without "Validation Weapons" or "Transformation weapons"
Composability
This is probably the most lethal of programming weapons/tools. This is the idea you can join bits of software together to achieve some goal.
The easier it is to compose software together the more "powerful" the tool.
The most obvious of these tools are languages. The popular players in terms of composing software together are functional languages, OO languages, dynamic languages, and hybrids. Each approach the problem slightly differently. It's worth mastering a number of these. This stuff is fine grained control of how software joins up and does something interesting
Another tool of composobility is Frameworks. These allow the user to wield a lot of precreated software in a very controlled way. Again, these are bread and butter stuff for most software developers.
DSLs are languages that match a particular problem domain and often leverage both frameworks and languages to achieve its end. This allows for an easy composition of ideas in the context of a particular domain. Gainning lots of traction these days.
Software Factories. These are similar to DSLs in that they tend to allow you to compose framworks and languages together in very quick ways. Factories can cut across many domains. Essentially you dial in what kind of software you would like and it will spit out software that does it. Currently there tends to be a lot of tweaking and the resulting software can be overly bloated, but if there is a factory that matches the type of soloution you want to create then its going to compose a lot of software very quickly for you.
Wizards. Can be great for creating chunks of software. Kind of like mini factories. I think a lot more could be done with these. Mostly software developers have very little control over these. I think if these were a lot easier to customise or make context aware they could be a lot more powerful.
Operating Systems / Open Standards. Things like *nix have a very composable runtime system. There are also many open standards for how things should talk together all of which has tooling and support for creating said systems
Application Scripting. A peice of software which essentially provides a framework for controlling it
Application Plugins. A peice of software which provides a framework and/or open standard for writing extentions to it.
Editors are the ultimate tool for actually composing software together. This is probablly 80/90% playground of software developers. It is worth being a master of your editor. I feel it also pays to at least appreciate multiple styles of editor also.... Vim / Xemacs / (Visual Studio, Eclipse, IntelliJ )
This is but some of the composobility weapons we get to employ as software developers. The essence of being a good software developer tends to being able to create good designs / acrchtetures / structures that allow software to be composed easily and utilising the right tools for the job. The techniques for how to go about doing this comes under "thinking weapons". And of course all this gets pretty hard to do without "Validation Weapons" or "Transformation weapons"
Subscribe to:
Posts (Atom)
