One of the major new areas in OpenEdge 10 is the language support for classes. ABL now lets you define source files as classes, as an alternative to procedures, to take advantage of many valuable object-oriented features established by languages like Java and C#, including inheritance and strong-typing of object references. One major pragmatic value of this new direction is the greater ability it gives you to define within your source code just exactly what things refer to and how different classes are related, so that the compiler can cross-check your references and give you much more feedback on your code's correctness at compile time, rather than waiting until runtime to see whether you've defined all the pieces correctly. So rather than defining a reference to a procedure as a handle variable that could point to anything at all at runtime, you define the variable as a reference to a specific class, and by gosh, the compiler will make sure that every reference to a property or method of that class is correct, and that you don't use that variable to reference anything else. This is a clear advantage to developers, and has little to do with any need for a deep understanding of object orientation.
So far, so good. But one of the major benefits of using ABL as a high-level programming language, as distinct from Java or C#, is the tight integration into the language of business logic that knows how to deal with relational data (and after all, most of the data managed by a business application written in any language is still relational), and that knows the details of the data's schema and lets you program accordingly. This is the key to the value of ABL, and goes all the way back to the language's FOR EACH Customer: DISPLAY Customer beginnings. In today's ABL we support the same kind of data manipulation, whether it's against the physical data schema (the database) or the logical schema of an application (temp-tables and ProDataSets).
This combination of support for classes with its object-oriented approach to code design, juxtaposed with the still very relational view of the business data, poses some serious challenges. Should you now try to treat each data item (a customer, say) as a true object? Does a set of all the customers in Ohio now become a collection of objects, that is, independent running instances of an ABL .r file, each holding the data for a single customer? This kind of approach has been tried in at least a few cases, and seems to go very much against the grain of the relational advantage of being able to treat these customers as an organized table of information, and presents the potential for serious performance problems as well.
There has been work in some areas on balancing the usefulness of a relational table as a way to hold and access multiple objects (like customers in Ohio), while using a more object-oriented approach to represent a single customer object, as properties of a class. See for example this thread on the PSDN Principles and OERA Forum:
http://www.psdn.com/library/thread.jspa?threadID=7645&tstart=0
There is also the question of how to balance what we traditionally describe as 'static' references to tables and fields – taking advantage of the compiler's knowledge of database and temp-table definitions – with the more dynamic approach of using a reference to a set of data (a handle, in this case) as a way to access its tables and fields and values more indirectly, using syntax like httCustomer::CustName, for instance. The static approach requires, at this stage of the product's evolution, having all the table definitions coded (perhaps as include files) in every class or procedure that references them, which is not a very encapsulated, object-oriented way of constructing things. The dynamic approach sacrifices some of the simplicity of the traditional FOR EACH...WHERE coding style along with some of the ability to count on the compiler and other tools to make sure references are correct and efficient.
So in short, we find ourselves in a transition between a more or less strictly procedural way of dealing with more or less strictly relational data, and a much more object-oriented way of dealing with what is mostly that same data. The product itself is always evolving. Future language features and other enhancements, always influenced by the experiences and the requests of our customers, help bring us closer to an ideal of really simplifying the hard job of building successful business applications. Open discussions about best practices, that is, how to do the most effective job of using what the product provides at any given point in time, are also a key component of creating a common understanding of how best to proceed.
I won't attempt any definite answers here. That would turn a blog entry into a full-blown white paper. And the point is, the answers are still in flux, and not as definite as we all would like. But the topic is important, and needs everyone’s input and experiences. There have been a number of threads on the OpenEdge Principles Forum on one aspect or another of the issues around handling relational data as objects, and you should take a look at them. To stimulate a continuing discussion, I've started a thread for comments and discussions on the subject, with this entry as a starting point. Join in. We need the participation of the broader OpenEdge community to help us guide where we go from here with the product, as well as with the discussion of how best to use it and apply its distinct and still considerable value. Here's the link to the thread, just in case you don't yet know your way around the forums:
http://www.psdn.com/library/thread.jspa?threadID=9532
Hope to hear from you.
