VFP's BASICS (Part 3)

Version: 1.00.01 - Last Update: Monday, September, 1st, 2014

 

---

This Thread is About OOP BASICS

In this thread we will discuss diverse methods that can be used to implement OOP features that are not supported by Visual FoxPro natively.

Most of the time our "discussions" will be based on my FoxQuill framework, which implements features like Multiple Inheritance, Design-by-Contract, Aspect-Orientation, Behavior Injection, and Namespaces, just to name a few.

Next Steps

I will write short posts, which describe some very special (widely unknown/unrecognized) behavior of VFP, that I then can refer to in this more conceptual thread. Thus, you do not only have a theoretical OOP concept, then but also a concrete VFP-based solution that you can use as a starting point to run your own further experiments and implementations.

Some Renaming

As I scanned through my blog I noticed that I never posted any entries under the Windows API section. Well, I have tons of things to post there, but no time to do so!

Thus, I decided to expand this section to encompass Unknown VFP Behavior, too! I think, this is a good coupling, because you also can create a lot of 'weird' behavior within VFP using WIN-API calls ;-) To get the most out of it, I will also discuss some features of public FLL libraries that support WIN-API calls in this context.

Please Note

This writing is a work in progress, as I am using this thread to structure the timeline of my upcoming posts (in the first place). Please use it as a starting-point for your lookups. Also keep in mind that most of the more or less unusual things I will discuss here are targeted to easy migration of VFP code to other OOP languages. Thus, they may not be that valuable when applied to a VFP-only Project lacking that need!

---

Overview

This is an unfinished list of what we will talk about in this section.

Multiple Inheritance in VFP

The first question we have to ask is: Should we support multiple inheritance within our platform/framework? This is the most basic decision we have to make, because it will have a deep impact on our whole design!

Aspect Oriented Programming

Another big point is, to find out if it's possible to support Aspect Oriented Programming, introducing a generic implementation approach of so called CCCs. A Cross Cutting Concern is a feature (behavior!) that applies to classes used in any layer of our design – it is cross-cutting our horizontal domain layers. A class feature obviously belongs to the CCC Feature Set if we find the same method code, and very often even the same method name, in classes belonging to any of our domains like: the GUI-, the BIZ-, and the DAT-Layer. This directly leads us to the following topic…

Namespaces in VFP

If you ever faced the task to develop a reasonable migration path from your current VFP-based environment to another language, like C++, C#, or JAVA, just to name a few, you must have stumbled over all these weird VFP SET-tings, like SET DATASESSION TO n, just to name the most prominent one. How can we handle them in other languages? My answer is: Let's introduce namespaces in VFP like I did in my FoxQuill Framework.

Multitasking in VFP

The time for multi-core processing has come! How can we introduce side-effect free multi-threading/tasking in Visual FoxPro? There are some really cool projects on the net targeting this feature (VFPX:ParallelFox is the most complete, IMHO). But we want more than just a "simulated" multi-treading based on a bunch of (very slow) VFP-EXE COM-Servers. We need 'Persistable' Message Queues, Conditional Activation, Execution Forking, and the like…

Code Generation

Sometimes, maybe, you're still using one of the old VFP Dinosaurs called the Menu Generator, even today. Back in the good old FP2.6 days, there were much more of these generators involved to create the finally outputted code. Many of the concepts introduced above cannot be realized without introducing a discrete code generation layer 'filling' VFP's gaps. And, fast and reliable Code Generation heavily depends on a suitable DSL (Domain Specific Language). Thus, we have to grow our own, to enable the following feature set…

Feature Harvesting

So, what's about our existing codebase? Do we have to start all over again to employ the newly introduced concepts? That would be to no avail, then, right? What we ALL need is some kind of code harvesting tool that enables us to analyze even large projects, building Dependence Trees as well as Code DOMs. This abstraction then can be used by our Code Generators to create any desired output…

Pattern Based Design

There are design patterns for OOP, AOP, and DSL. I have extend my own Pattern Vocabulary defining additional patterns for Unit-Testing, Workflows, and Messaging. All patterns match internal templates, that can be used to parse, evaluate, extend, and transform data. Basically, my Patterns are abstract feature sets, that can be applied at design/runtime to manipulate, either the class definition, or their instances at runtime.

Persistent Objects

Serializing VFP class instances at runtime isn't that easy. But, if you've got the darn thing to work, you don't want to miss it any more! I've spent a lot of my free time to develop some serializing feature based on VFP-DBFs exclusively (and did it successfully, by the way!). But, what if you are migrating to some SQL-Server based environment. There must be a reasonable fast way to persist and retrieve VFP object(hives) from a set-based Data-Server, too!

Simplified Signatures

Do you know LEGO blocks? Have a look at the picture I've linked and tell me what you see as an OOP developer? What made these little blocks so incredible successful? Why is it so easy, even for the untalented, to build (sometimes:-) really impressive Lego-thingies? The answer is: Each Lego block has an interface which is very easy to handle! Every 'nub' on the top will fit into ANY 'slot' in the bottom. Lego blocks only differ in the number of nubs they implement, which makes them distinct from each other. Let's keep the color of a Lego block out of this picture, because it don't belong the Lego block's constructional interface. Think about it for a while! If a Lego block is what we call a class in VFP, what is one nub of a Lego block then? And, how could we apply the uniformity of those nubs to our own class features, so that instances of this new breed of classes can be used at runtime to compose large-scaled objects with ease?

Stop Writing Code

This is my favorite continuation of the well-known slogan: Don't repeat yourself! Instead of writing code, we should better write templates, that enables our code generators to do this for us automatically. This will not only increase robustness/reliability, but will also speed up the performance of our complete development cycle!

Strongly-Typed Class Features

Boon and bane of VFP's type system is, that there barely is none. Boon and bane of (for example) C#'s type system is, that you cannot disable it completely…
If we want to employ any design by contract enabled scheme, you have to employ some kind of type checking sub-system within VFP. Which is, in my humble opinion, easier to achieve, than the other way round: Trying to overcome the restrictions a rigid, strictly typed environment would put on us.

Content-Checked Class Features

I must admit, this is a poorly chosen term for "Implementing the real Design-by-Contract scheme". But, that's exactly what I want to say: A main feature of the "real" implementation of Design-by-Contract is, that a valid static feature (property) must not only hold a value of the right (class-defined) type, but also, in addition to that, must be within valid (class-defined!) boundaries! Both DbC features (strongly typed, and content-checked) are essential ingredients for creating bullet-proof applications.

Class And Object Reflection

VFP offers a wide range of Reflection-related functionality. But, as usual(?), there are some features missing, especially, if we're working with PRG-based classes only! This makes it necessary to introduce some home-grown Meta-Data based Reflection Management, which can be easily migrated as well.

The Open Close Principle

This is all about implementing the well-known Open Close principle. We should go for closed classes, disallowing modification of their features directly, that are open to extend them, in terms of inheritance, instead. Following the Open-Close-Principle inevitably leads us to another problem domain…

Feature Extensibility

This is all about how to practically manage extensibility at our class level within VFP. We will discuss Hook-Operations, Hidden Feature Layers, Meta-Data driven Extensions, Code Injection, Instance Cloaking, Runtime Compilation, CodeBlock Interpreting, just to name the most common/important ones.
Finally (this is damn cool!), MAYBE, I will show you an unknown but documented (really!) Native VFP behavior I've named Member Runtime Extensions.

<to be continued…>

---