Open Concepts

Most examples of open classes are extensions of core system classes (string/float), such as adding a "to_cents" method on Float. Often such extensions are not needed, as a new wrapper class, such as "Money", would serve the purpose better.

Core classes may not need to be open for extensions, although that can sometimes be useful (remember how long it took Sun to add java.lang.String#replace(String,String)). It is important for Model classes to be open for downstream extensions. For this reason I use the term "Open Concepts" to indicate that the concepts in the model are extendable.

The biggest advantage for having "Open Concepts" is that the model can be modified without modifying the original source. This creates many opportunities for multiple team system development. By enabling the model to permit dynamic integration of independent and decentralized designs (open), the code becomes simplified and more useful to a wide array of use-cases. Consider the productivity advantages of allowing downstream development to have more influence to extend the supplied model without necessarily involving upstream in the changes. These are many of the advantages that allowed the Ruby language to gain so much popularity.

There are many ways to enable this, even in more mainstream languages. One popular approach is to implement a plug-in system for key points in the model (although this quickly become complicated with many "key points").

A more generic way is to implement the role class model in all the concepts. This allows every individual to expose itself through multiple concepts. However, anyone that has used Mozilla's XPCOM, knows first hand how the syntax of this pattern can get out of hand.

Today, with the popularity of new languages that support the run-time mixing of classes, new opportunities for creating an expendable model now exist. Such an approach allows both plugin-style and role-style extensions, but still uses the syntax of the host language. This allows the model to be used the same way as if no extensions are present.

Any large system will need some type of extendability be it a plugin-style, a role-style, or an open-style model. It is worth considering the approach early in the development cycle, as many of these approaches are intrusive, by syntax or language.

Storing Business Rules

Every application has some domain logic or business rules, but how much thought goes into how it is stored? Try asking yourself the following questions to help identify possible ways to serialize the domain logic.

How often will it change? Will each deployment need to have customized rules, will they be changing at run-time?

Who will be managing the domain logic? Will it be managed by people with a particular skill set? Does the domain logic need to have its own version control and distribution channel? Will the domain logic be reviewed by independent parties?

What form will the domain logic take? Can it be defined in a formal structure? Is it data driven?

There are many ways that domain logic could be stored, the most common is not always the best. Consider the following ways to serialize and store domain logic. You might use the same language as the application logic, or You might encode it in a domain specific language.

Domain logic might be stored in flat files that are compiled or in a form more suitable for a rule engine. It could be embedded in one or more XML files, for indexing and quick access. Domain logic might also be stored in a formal structure, for user-initiated rules or dynamic version control.

Domain logic can take on many forms and how it will be stored should be consider carefully. Depending on the makeup of the team or other external influences there maybe a need to make a greater distinction between domain and application logic.

Utilizing a Multi-Core System with the Actor Model

Demand for multi-core/multi-processor applications is growing, but developing for a multi-threaded application does not require a steep learning curve or an understanding of complicated edge cases. Learn how to develop efficient multi-threaded applications without using synchronized blocks.

http://www.devx.com/Java/Article/39868

What a Modelling Language Should Look Like

InfoQ gave a summary yesterday of a few blog posts on Modelling languages.
Briefly, Steven Kelly and Juha-Pekka Tolvanen say such a language should:
1) Map to the domain problem concepts and not implementation details.
2) Be formalized and helpful.
3) Have stand alone tooling support.

http://www.infoq.com/news/2008/11/useful-modeling-language

Unfortunately, the discussion focused on a visual modelling language (UML) and did not address any alternative modelling languages, such as the standard Web Ontology Language (OWL), which addresses many of these issues. Although OWL was not designed as a visual language or arbitrary code-generation, it has grown to support such usage.

TopBraid Composer, for example, is a mature editor and visualization tool for OWL.
http://www.topquadrant.com/topbraid/composer/

Module Dependencies

I was reminded recently of a domain model I used to work with that did not separate interfaces from their implementations. They never considered dependencies to be an issue because javac could compile the entire source tree at once.

When I came on board, their product was nearing it's first release and their domain model's class dependency chart looked like a bowl of spaghetti. Eventually the lack of dependency management become apparent: each team was developing at a different pace, but everyone was forced into monolithic releases.

Much of the circular dependencies were addressed by introducing interfaces or abstract classes. However, the process was slow and full of challenges. Hibernate only supports a single inheritance model, but with so many different perspectives such a restriction proved very limiting.

Many of these problems could have been avoided had more thought gone into the the conceptual class hierarchy earlier and distinct modules been created to force developers into observing and thinking about class dependencies early in the development cycle.

Where are programming languages going?

Anders Hejlsberg gave a keynote last month at JAOO http://jaoo.blip.tv/#1324214 (published two weeks ago) entitled "Where are programming languages going?". He said that with a little more restriction in languages, compilers could do a much better job at optimizing the code. I think this is an interesting discussion and agree with many of he ideas.

Towards the end of the talk he addressed concurrency. He suggested that a for loop, for example, could automatically execute all iterations in parallel - if few mutable variables existed. This is an interesting idea, although a very difficult task. Unless the code fits into the map-reduce pattern, it will likely modify some shared memory structure or external state (read database) and could not safely be executed in parallel. I think we will have to see more integration between persistence frameworks and optimizers before such as idea could be realized.