Think Objects Anyway
Think Objects Anyway[ CategoryPattern ] (or is that CategoryPseudoPattern??)
Often, the programming environment that allows the best access to the desired functionality (or the environment imposed by management) does not support object-oriented concepts. This isolates the project from some of the favorite features of object-oriented development, such as OO patterns.
Therefore
ThinkObjectsAnyway, and code without the crutch (of language-supported object concepts). Given the idea of a data record (or even a dictionary) and a function pointer, most of the benefit of "object-oriented languages" can be duplicated. Think of your records as objects, and of your functions as methods. Pass your "this pointer" as the first parameter of each "method call". If you can't segregate methods into namespaces, at least prefix each method name with a short prefix to prevent collision.
But
Some environments are so anti-OO that this can easily become an AntiPattern. I had this AntiPattern in university when I had to do a project using embedded SQL in C/C++. I spent a lot of time trying to wrap the embedded SQL in objects but just couldn't do it in time. I spent more time on that project than most university projects, but still couldn't get it to work. Of course, the caveat is that I'd never use embedded SQL in the real world, so I guess it doesn't matter much.
(Issues of wrapping SQL covered in PerniciousIngrownSql)
Uses
[P.S. I'd appreciate thoughtful criticism. This is my first submitted pattern. This seems to me to have been a major pattern influencing my work at several points, and one that others have appreciated learning. I was surprised not to find it already in here, which makes me concerned that it might fail some PatternityTests, or already exist with a different name.]
I had one OO book (which I was just unable to find in my bookcase) that had as its primary theme the application of OO concepts to non-OO languages. (Sorry that I can't provide a reference, but I liked the book, and agree with all you have said.)
Consider ObjectBasedProgramming, which describes "translation from an object-oriented design to an implementation in a procedural language using an "object-based" programming style". Good patterns tend to be rediscovered several times.
I have a feeling that this might really boil down to applying OnceAndOnlyOnce as extensively as the language allows, outside of a few specific cases such as OO extensions or decorations in "mostly non-OO" languages (Perl, JavaScript come to mind).
Or rather, I can't relate the above advice to any concrete experience I've been through which didn't boil down to that, although I have had an "OO frame of mind" for years and years and have at times applied it to "less than fully OO" languages.
The advice given has a familiar "feel" to it, and does bring some experiences to mind. But on reflection these experiences only involved making my "functions" generic with respect to the entities manipulated by these functions, which enabled me to apply OnceAndOnlyOnce.
Is the ActiveServerPages example documented somewhere ? My own experiences were with PHP and JSP code, so by looking at the design of the ASP stuff specifically I might figure out how that differed from my own PHP/JSP tricks.
The author is describing something very close to AbstractDataType (ADT), which is all about encapsulation and not at all about inheritance or polymorphism. This mix can result in very well organized code, more toward a component model than many OO languages would tend, and without all the junk that comes from the inevitable experimenting with arcane inheritances and polymorphs. A nice pattern.
A real world experience: After leaning the SmalltalkLanguage, I spent several years continuing to work on C language projects. (C++ was available at the time, but my customers wouldn't allow us to use it.)
So I spent a fair amount of time writing functions with "class name" prefixes, which took a pointer to the structure of the same name as their first argument. Like "polygon_isPointInside(struct polygon *p, int x, int y);"
One can also use function pointers: You can simulate the C++ "vptr" table by having the first member of each structure have a pointer to a structure containing function pointers. You can nest these "function pointer" structures for inheritance. But the pointer coersions quickly get messy, and the business applictions I was working on did not need polymorphism that bad. -- JeffGrigg
Back before I got my first C++ compiler, I implemented something similar in C. Each "class" was a simple C struct with a bunch of function pointers at the start -- It didn't occur to me to put the vtbl somewhere else, and use a vptr. The function table was populated with a bunch of preprocessor macros.
Then, I simply made sure that I called the methods through a structure of exactly the same shape (effectively the interface "class"). Worked quite well.
For an example of what I'm talking about, look at the original OLE1 headers, and possibly the C interfaces to COM (check most of the DirectX samples for these).
Indeed, as I'm sure everyone here knows, OO languages came from this sort of usage of previous languages.
-- MichaelRHead
EditText of this page
(last edited March 10, 2006)
or FindPage with title or text search