How I had this strange idea

While approaching several mainstream opensource applications coded in OOP (mainly CMS/ERPs and web-based apps), I noticed that I had a certain difficulty in finding what were the classes instantiated, their methods, and the data-structures that they used.
In plugin-based architectures then, the code becomes bloated and "spaghetti-like" very easily due the contribution of many brave developers without guidance.

Another side effect of the (mis)use of so many objects, data-structures, and methods is that applications coded in OOP nowadays run really slow (imho). Sometimes – and this is true especially in Java - (sloppy) developers, make methods to perform the easiest functions.

One day, while I was researching about scalability, I stumbled across a presentation of the Ebay architecture and I started reading it looking for interesting details. Seeing that in order to accomodate their scalability needs they had eliminated stored procedures in the db and they had moved joins at application level, gave me some insights about creating a "grammar" for database design that let developers encode certain information at database-level, without using the canonical database tools (foreign keys constraints, and cascade operations/stored procedures).

Having looked, in the past, at the way in which the development of *BSD (FreeBSD, NetBSD etc.) is managed, and rememberming the philosophy behind its architecture, I thought about replicating its "monolithic" architecture and its clearly organized approach to development. And I thought to do this by binding people to use only 1 object. A single object which used the "grammar" that I had conceived.


I thought that this approach could reduce the complexity of their code, and at the same time offer a lot in terms of performance, scalability and security. Unifying data-structures, methods, and - ultimately - code, would make execution very fast. Also, this would give the chance to centralize all the methods for everything (input-gathering, input-validation, data-access etc. etc.), making the code a "black-box" that doesn't need to be included inside any other class (encapsulation/inheritance), thus truly hiding the complexity from the developer, and bringing the business-logic coding on a new level.

So I started writing some code during my spare time. Trying to minimize the overhead with some (sloppy) use of recursion, and trying to write the database grammar at the same time.

SingleObject is the outcome of all of this.