The Feature Set - Simplified
In my last blog entry, I listed the features of Charlie.
After reading through it a couple of times, two thoughts occurred to me. First, some items are very specific while others are very general. This meant that the feature list is not consistent in its level of abstraction. Second, some items were a mere variation of another item. This too meant that the feature list is not consistent in its level of abstraction. This inconsistent level of abstraction concerned me.
The idea of application design is to start at a general level, and slowly move to increasingly specific levels. A rough example would be that we start by identifying the application itself, then move to identifying its layers, then move to identifying its components, then move to identifying its classes, then move to identifying its members, and finally move to coding those members.
I realised that if I want to follow this general-to-specific approach to application design, I must rework my feature list so that it attains a consistent and high level of abstraction. I started by asking myself, yet again, what it is that I want Charlie to do. The answer was that I want Charlie to provide a general website framework on top of which specific websites will be built.
That answer made me remember a design principle that is repeated throughout Head First Design Patterns:
“Identify the aspects of your application that vary and separate them from what stays the same.”
With that design principle in mind, I have reworked my feature list so that it identifies what must be allowed to vary from site to site, and what can be allowed to stay the same.
For all users, Charlie will:
- Support multiple websites
- allow for custom and turnkey websites
- Support multiple content types
- allow for custom and common modules
- Support multiple response types
- allow for different devices (browser, mobile, assistive, etc.)
- allow for different document types (webpage, PDF, Word, RSS, etc.)
- Support multiple asset types
- allow for different ways of creation (manual, parse, scrape, conversion, etc.)
- allow for different renditions (size, language, currency, etc.)
- allow for different versions and status
- Support multiple user types
- allow for visitors and members and owners
- Provide common services
- reporting (hits, problems, performance, etc.)
- site, page, and module CRUD
- integrated help
- security and user management
- messaging (email, SMS, etc.)
- high-level objects
I feel more comfortable with the above feature set. It maintains a fairly consistent and high level of abstraction. Its generalisation allows me to recognise the components that may be required, and even some patterns that may be applicable.
As tempted as I am to start sketching out my view of Charlie, I will resist the temptation. I promised that I would work through Coder to Developer, and I will keep my promise.
by Alister Jones | Next up: Methodology - Finding the Right Path →
----
Post a Comment