Version: 1.00.02 - last update: Friday 7th of March 2014, 13:25:00
This is a short introduction of what is so special about the FoxQuill framework and why I decided to do it just that way.
This is a short introduction of what is so special about the FoxQuill framework and why I decided to do it just that way.FoxQuill is not a framework only! Of course, FoxQuill incorporates a whole bunch of class libraries bundled with many cool tools to manage and maintain them. But that is not all, by far!
A Managed Runtime Environment
The design of FoxQuill's underlying software architecture can be called a Managed Runtime Environment for Biz-Objects. This is a runtime system where the Task Fulfillment Instances (all implementation components that make up the application a user actually is interacting with) are controlled by an superordinate governing like shown in the next diagram.
Therefore, in the first place, FoxQuill is a Generic Collaboration Controller at runtime!
The Encapsulation-Collaboration Gap
While a good OOP Class Design promotes encapsulation (to support of reuse of classes) a good APP Design has to stress the collaboration of the concrete implementations of these classes. I named that the Encapsulation-Collaboration Gap. What I'm talking about here is easy to grasp. Remember your last contact with an unknown VFP framework! After having spent hours of exploring the (sometimes) genius code inside the classes (stored in uncountable libraries) you finally may have asked yourself the elementary question: "How do I put all these gizmos together to create something useful for my client?"
Baking a tasty cake needs more than having all ingredients at hand! You need the knowledge how to mix them, and how to tamper with them to get the desired result:-) Let us stay with this real world example and ask: "Wouldn't it be nice to have a cake baking machine we could feed with our ingredients, select the cake we want from a menu, press the "BAKE" button, and finally watch it to do the nasty (and error prone!) job of joining, mixing, tasting, adding some more of this and that, tasting again, and finally baking our perfect cake - every time we want it, every time with the same perfect result?"
Encapsulated class components (the ingredients of our application) are not capable to mix/combine themselves into something working at a larger scale by design! This led me to the question: "Is it possible to alter my class design to overcome the Encapsulation-Collaboration Gap issue without breaking any rules of (good) OOP-design?" The FoxQuill framework is the result of my mediation!
App-Generators? No-Way!
I hate "Application Generators"! Look at the one you've got for free when installing VFP on your disk (see screen shot below)
Be honest, did you ever create something productive with that generator for your clients? I did not! I even refused to dive deeper into the workings of VFP's free App Generator simply because I never wanted to be forced into the constraints of someone else's mind/knowledge.
FoxQuill will NEVER put any constraints on you. You can enhance or alter every single aspect of it. Okay, maybe you will argue that you can 'pimp' the VFP Application Generator the same way to make it do what you want. But, to be honest, this can only be accomplished by understanding/knowing all and everything about it! Most of the components (classes) of that solution heavily rely on other parts of the same project which is called a (very!) tight coupling! This is one of the number one reasons why it is so hard to get used to an unknown framework/solution!
The solution
Free your 'workhorse' classes from being responsible to interact with others (in their method code) by delegating all collaborating code to another higher level! More than that, keep your 'workhorse' classes from being polluted by parameter checking code in that you move out that responsibility to another specialized level of government and you will get what FoxQuill is all about!
What FoxQuill finally is
FoxQuill is a framework that gives you all base classes you need during your daily coding challenge. All you have to do is to make your subclasses stemming from a FoxQuill base class to let the outcome run flawlessly within a FoxQuill controlled environment.
FoxQuill is a runtime environment that implements its own contracting, messaging, event-binding, and data- binding schemes. In short, it delivers a complete object's life-time cycle management (including object's interactions!) to free the re-using developer from taking care of all of these issues!
No comments:
Post a Comment