design philosophy

Design Philosophy of Cinderblock

Object modeling is hard to do well

Over many years I've seen many frameworks attempt to make modeling business applications easier; some of them I've downloaded and used, some of them I've designed myself. These platforms have a tendency to make sacrifices which can quickly lead to inflexible software design, poor performance and a general lack of consistency as developers "work around" the limits of their architectures. The sad part of this whole situation is that these frameworks start with the best intentions, and over time become bloated and unmanageable because they try to solve "all the problems". This ultimately leads to a system that removes a developers freedom to design their software against a well defined paradigm.

Why Cinderblock?

If I look at the several hundred applications I've created over the last 20+ years, the vast majority of code written manages the lifecycle of data. As an OO methodologist and self proclaimed "lazy programmer", I really like a design that is simple, consistent, flexible, extensible and most importantly, decoupled.

This is harder to pull off than you'd think. To get there, Cinderblock uses a few lightweight design patterns that solve certain issues with regard to object and data lifecycle.

The Factory Pattern

Stuff about factory objects

The Repository Pattern

Stuff about repository things

The Command Pattern

Stuff about the command pattern

As you work with Cinderblock, you'll quickly realize that it does not use any methodologies that rely on reflection. In my experience (put stuff here about why reflection systems suck)...

When to use Cinderblock

Cinderblock isn't a hammer for all nails. While it provides a simple model for managing data lifecycle, it does not contain behavioral structures that define application logic. Instead, it is highly recommended that application behaviors be constructed of other design patterns and integrated within the concepts of the Cinderblock framework. In these cases, developers should use their own creativity and knowledge of both their domain problem and OO theory to construct robust application behaviors.