F* is a meta-pattern realizing a ‘feature first’ approach to software design. This page provides concise information about F*, along with links to my original articles.

As wit would have it, I sometimes refer to F* as an anti-pattern. However, 3 years after the original insight, I still very much regret that encouraging teams to use F* is difficult, and I still believe that F* is fun, safe and productive.

What is F*?

As a design principle, F* encourages developers to avoid both naive design and arbitrary choices regarding the choice of a separation model. At the core, the idea is to focus on the problem at hand (the feature we are developing) and provide just enough bindings to plug the feature into our existing software.

As a separation model, F* suggests a disciplined approach to feature separation; this affects logical design (forbids type dependencies across features) and physical design (1 feature = 1 folder); it is in sync with agile thinking ( don’t over-design; postpone design whenever possible ). Glue is needed to hook features together. Typically the glue is provided by a separate package (e.g. *.event ) used to define event and observer types.

When to use F*?

• I recommend using F* for application design. I encountered fair success using F* to develop a sequel to my first programming tool, Antegram (ee-ide and ee-docs; maybe some versions are lying around on the web).
• Unless your guys are enthusiastic I would avoid it altogether in a team environment (you don’t wanna see a depressing ‘refactoring’ of your neat F* code; I’ve had that).
• I cannot recommend its use when developing frameworks/components (it could be tried – insofar as this doesn’t affect the public interface of your API).
• F* bows to concrete requirements regarding separation. For example…
• if you have persistent data, then ‘data classes’ exist in their own right so I would find it reasonable to prioritize separation using this angle.
• Likewise if you’re selling components, surely component driven separation should be prioritized.

How do I know I’m doing it ‘right’

If you adopt F* as a separation model you may need to setup a mini-framework (or at least adopt naming conventions) as backup.

With languages such as Java and Objective-C, it is possible to implement feature separation in such a way that a feature will drop without a sound (no compile error) after deleting all related files. If your instance can do this, you are following the ‘disciplined approach’.

The main class should instantiate and boot all application features in no particular order. If ‘turning off’ a feature breaks another feature, either there is a non-formal dependency (in which case regressing acceptance tests would reveal incomplete / broken features although the software ‘still works’) or something’s wrong.

Original articles

Republished from my previous blog @ oogtech.wordpress.com; first public presentation.

• Feature programming & Feature annotations - Why ‘thinking about features’ is important when designing applications; focuses on a non invasive (tagging oriented) technique that is more compatible with teamwork as your co-workers may be reluctant to adopt F*.
• F* – an introduction - Introduces the rationale behind the meta-pattern
• The F* meta-pattern - public presentation at Perl Workshop Beijing 2009

For those who wish to combine an MVC oriented approach with feature separation, this article may provide hints.