Table Oriented Programming

[Gerald Davis]

All the rage is Table Oriented Programming, what do you guys think.

http://www.geocities.com/tablizer/top.htm

I found this while looking for get programming practice tips.
http://www.javaworld.com/javaworld/jw-10-2004/jw-1018-butler.html

[Ilja Preuss]

Originally posted by Gerald Davis:
I found this while looking for get programming practice tips.
http://www.javaworld.com/javaworld/jw-10-2004/jw-1018-butler.html

Despite the dominance of the relational database, the mainstream persistence frameworks (Enterprise JavaBeans (EJB), Java Data Objects (JDO), Hibernate) refuse to model objects in a relational database. All relational databases are built from tables, columns, primary keys, foreign keys, records, queries, etc. But none of the mainstream products has an object model that corresponds to these entities.

Well, I'd guess that the implementations of those frameworks actually model the relational database inside, but hide it from the user of the framework.

developing CRUD functionality is much simpler if the database structure is not hidden

That's really a strange statement. With Hibernate, I just create, update and delete objects and tell Hibernate to persist the changes to the database. How can it get any simpler?

One argument for having an object model that doesn't correspond with the actual database structure is that the business logic should remain the same even if the database structure changes. But this argument neglects the fact that much business logic is implemented in a relational database schema. Changing the database schema will, by definition, also change the business logic.

My experience is quite different. Database schemas change for a couple of reasons that don't have anything to do with business logic: performance, normalization, requirements from other systems sharing the database etc.

In fact I think that is a good reason to *not* also put business logic into the database.

One consequence of this refusal to model a relational database's real structure is an extra layer of abstraction. [...] SQL must be reinvented (Hibernate Query Language (HQL), JDO-QL, EJB-QL, etc). Why bother adding this extra layer? It adds complexity and provides few additional features.

Actually I feel that it reduces complexity in many cases, because I can concentrate at one job at a time - I don't have to think about the database structure when in fact I want to concentrate on business logic. "Divide and Conquer".

Many in the object-oriented world argue against data-aware components. One common contention is that the GUI and database don't share the same structure. This is indeed true for some clients, but for CRUD-oriented clients, data-aware components could save a lot of development time. Just because data-aware components should not be used everywhere is not reason enough for avoiding them altogether.

I think we have differentiate between *data*-aware and *database*-aware components.

Interestingly I recently worked on two CRUD projects that used those two different approaches.

The first used Borland DataExpress, a JDBC-aware component library, which I would call quite table-oriented. This is a maintenance nightmare - even changing small things in the GUI have ripple effects to the database that are very hard to get under control.

The second used a combination of Hibernate for persistence, and the new Java Bindings framework for binding the Java Beans to the GUI. It's right that it had a slightly steeper learning curve, but once we groked it, it was real fun working with. After implementing some custom components, we have whole JTables automagically refill when things happen to a combination of other tables and comboboxes. Changes that are mind-bending complicated in the first application are made in minutes in this one.

[Ilja Preuss]

Originally posted by Gerald Davis:
http://www.geocities.com/tablizer/top.htm

I already said something along the lines in another thread: OOP is basically fancy syntax for building Control Tables.

Actually the article mentions that, but it fails when it implies that OO somehow favors one dimension over the other. It definitely does not.

That is, there is no rule in OO that says

class MyFoo1 {
  void doBar1();
  void doBar2();
}
class MyFoo2 {
  void doBar1();
  void doBar2();
}

is to be favored over

class MyBar1Command {
  void execWithFoo1();
  void execWithFoo2();
}
class MyBar2Command {
  void execWithFoo1();
  void execWithFoo2();
}

Both designs are totally valid OO - which one you should prefer basically depends on which dimension you think will need more flexibility (as it is easier to add another class than to add another method), and where you see more potential for code reuse through subclassing.

Finfally the Visitor pattern allows you to have an OO design which actually doesn't prefer one dimension over the other, as it allows you to define operations outside of the class hierarchy they are working on.

That doesn't mean that a non-OO control table isn't usefull from time to time - sometimes it's just the best thing to do. It's just no reason to drop OOP from your bag of tools, in my not so humble opinion.

[Jeanne Boyarsky]

I think Ilja pointed out everything from the article.

However, I think part of it is efficiency too. We use EJBs when we can, but for some complex queries, JDBC is still needed. An object-relational framework can think in terns of objects. But the database is still thinking in relational terms and can be slower if you force it to think relationally.

Regarless, all this is in a single layer and doesn't have any effects on the rest of the code.

[Gerald Davis]

Thank you thank you thank you, I have a few things to do at the moment but when I have some time I bet I'm ganna love reading these messages.

[Gerald Davis]

I agree with halfway on nearly all of these issues; I don't know how to reply, I can tell you of my puny experiences. I like MS-Access very much it is easy to work with and GUI are very easy to create, and very fast on a old P100 I see it as a very useful for prototyping systems to. I assume MS-Access is a CRUD-oriented clients.

Compare EJB with the like of MS-Access and even though EJB has to handle multiple clients at one, it seems to be very complicated and the end product seems to be objects based on tables that are not joined relationally but through the EJB server. Its been some time now but I don't remember using any container managed bean handle anything that would otherwise be queries in SQL. EJB could be very nice if it came with a nice IDE and used a better language like Python or to a limited extent C#.

[Alexandru Popescu]

Compare EJB with the like of MS-Access[...]

... yes why not. I will take one of the medium size app developed last year. It was about 150 tables, 1 mil.records. Can MS-ACCESS (in fact V BASIC + VBA + MSACESS) handle this? I guess not... I will not bring into discussion handling concurrent access or throughput or transactions.

EJB could be very nice if it came with a nice IDE and used a better language like Python or to a limited extent C#.

Here I cannot see the point. I am not sure what Java is doing wrongly/hard in EJB. I am also not sure what a nice IDE would have to do for me when working with EJB.

./pope

[Peter Rooke]

You may be interested in a development product that I used a few years back - Sybase's Powerbuilder. It had a nice IDE, good documentation, and support for most RDBMS. To develop you typically use a DataWindow, not too dissimilar from development using MS Access. I've never used the product since version 7, but it is still around and up to version 10.

Of course I still think Java is the future.

Powerbuilder 10

[Ilja Preuss]

Just for the record, I'm not at all talking about EJBs at all. In my limited experience, EJBs are just overkill for most applications.

What I'm talking about are POJOs connected to a database by a nice little persistence layer. That's fun to work with.

[Stan James]

I'm glad you mentioned PowerBuilder. We used it for one generation of the system I'm on. I always said it was extremely productive for splashing a database on the screen. If you just need to give the user a channel to update database tables it's fairly amazing. VB may be just as good - haven't looked since 1995. But that functionality describes about 1% of what we do. I could be tempted to use a tool like that for a couple admin functions - letting users add and remove rows that wind up in dropdowns - but not for any of the heavy lifting I have to do.

[Gerald Davis]

Originally posted by Ali Pope:

... yes why not. I will take one of the medium size app developed last year. It was about 150 tables, 1 mil.records. Can MS-ACCESS (in fact V BASIC + VBA + MSACESS) handle this? I guess not... I will not bring into discussion handling concurrent access or throughput or transactions.

./pope

MS-Access is a front-end that connects to a crap SQL server by default . The power of MS-Access is limited to the power of the SQL-server back-end, to my knowledge anyway. For handling clients concurrently EJB has been design very wall and does a better job then MS-Access.


I am also not sure what a nice IDE would have to do for me when working with EJB.


What I mean by IDE is a wizard for constructing EJB classes and setting options for the EJB container. I might assume that most EJB servers come with such an IDE since I last used EJB 3-plus years ago.



Here I cannot see the point. I am not sure what Java is doing wrongly/hard in EJB



Java fails in both departments it's JVM is just to slow for server-side applications. Personally I don't see the why a Java would use a virtual machine for server side applications like EJB. If EJB container was implemented in C++ with Java and other language connectability this would speed up things considerably. The trick is to let the C++ library take the strain not the higher level language.

For most applications I prefer to use a low level language combined with a scripting one. A combination of speed of development and speed of execution. VB + C++ , TCL + C, Python + C work like a horse with a rider; the horse is fast and the rider has fast brains.

The Java's JVM does use C++ library's to implement many functionality but it doesn't do it enough. Take GUI Swing for instance, it is all completely written in Java make it too slow. They did try use native OS features in GUI with AWT but it had to cater for the lowest common denominate so AWT ended up weak on features and abilities. wxWindows uses native features and is better then AWT and Swing.

[Alexandru Popescu]

Java fails in both departments it's JVM is just to slow for server-side applications. Personally I don't see the why a Java would use a virtual machine for server side applications like EJB. If EJB container was implemented in C++ with Java and other language connectability this would speed up things considerably. The trick is to let the C++ library take the strain not the higher level language.

Because you probably don't want to have the same application written in different ways (compiled with lots of compilation flags maybe) just to fit different server machines. Moreover you will not need different specialized guys in flavours of C++. Afaik I don't know any application server for C# usable on at least 3 main OSs.

As you probably know this interlanguage connectability has already a name: SOAP and till now there are no great signs about it.

Finally I would say that the days where the discussion about C++ vs Java performance are gone.

./pope

[Ilja Preuss]

Originally posted by Gerald Davis:
Java fails in both departments it's JVM is just to slow for server-side applications.

An interesting statement - can you back it up with numbers?

I am asking because, as far as I know, the server JVM actually is quite aggressive regarding compilation to native code and optimization. At least theoretically it could even be more effective than a C++ compiler, not only because it can compile to the specific platform the server is running on (OS, processor, memory etc.), but also optimize it for the specific usage patterns of the running server instance.

[Jeanne Boyarsky]

Originally posted by Gerald Davis:
Java fails in both departments it's JVM is just to slow for server-side applications.

Given that we are talking about table oriented programming (aka databases), this shouldn't be a problem. Even if Java were significantly slower than C++ (which I doubt), most of the time is spent on the database anyway.

[Gerald Davis]

Originally posted by Ali Pope:


Because you probably don't want to have the same application written in different ways (compiled with lots of compilation flags maybe) just to fit different server machines. Moreover you will not need different specialized guys in flavours of C++. Afaik I don't know any application server for C# usable on at least 3 main OSs.

As you probably know this interlanguage connectability has already a name: SOAP and till now there are no great signs about it.

Finally I would say that the days where the discussion about C++ vs Java performance are gone.

./pope

I am not talking about compiling C++ Code for server functionality, but using about using pre-existing C++ library combined with a high-level language. I have never compiled c++ for any of my applications and I hope I never will. If I am working on a cross-platform development I just use pre-compiled C++ for the platform that I am working on and connect it to a cross-platform scripting language of my choice, I usually choose python.

Don't see Java being the future, well not in the way it is currently being used at the moment. I just don't see it replacing the role of c++, because Java is noway as fast as C++ and to low level to be used as a scripting language.

One of the fundamentals of Object Orientation is data hiding, implementation changes while interface stays the same. Making implementation and low level design change are so much easier with high level scripting languages then a low level one like Java.

[Alexandru Popescu]

Don't see Java being the future, well not in the way it is currently being used at the moment. I just don't see it replacing the role of c++, because Java is noway as fast as C++ and to low level to be used as a scripting language.

I never heard somebody saying that this is the intention of Java - to replace C++. On the other hand, if you would stay more updated on the performance benchmarks you would see that this noway fast has changed a lot in the last years. If I would like to join this no args afirmations I would say that the speed of running C++ is nothing compare to the speed of dev and maintainance with Java for multiplatform solutions. But I will not do this.

As for scripting languages I am not quite sure I would develop one of my 1000 clients multi transactional applications using scripting languages. Probably for playing around I would give a try to rhino/groovy/jython .

peace,
./pope

[Gerald Davis]

Originally posted by Ali Pope:


I never heard somebody saying that this is the intention of Java - to replace C++. On the other hand, if you would stay more updated on the performance benchmarks you would see that this noway fast has changed a lot in the last years. If I would like to join this no args afirmations I would say that the speed of running C++ is nothing compare to the speed of dev and maintainance with Java for multiplatform solutions. But I will not do this.

As for scripting languages I am not quite sure I would develop one of my 1000 clients multi transactional applications using scripting languages. Probably for playing around I would give a try to rhino/groovy/jython .

peace,
./pope

Holy Crap, It seems that you are right, To even depute the speed of Java over C++ must mean Java has come a long way. My assumption of Java must come about using Swing, which is still inhumanly slow and full of memory leaks.

Either though I don't mind Java syntax to much, I still find the IO is unnecessary complexed, with its over use of the decorate pattern, the same goes with many of Java packages; they are just to complexed. Saying that, I am sure that someone will come or has already built a fa�ade for all Java complication maybe the dudes at Jpython have already done this.

[Stan James]

I just spent a week long class using an intricate IDE in a class and only learned it was Swing at the end of the week. It was absolutely up to the job. Swing does not necessarily equal slow. I've only done a few small apps with one or two windows on my own, and I have no complaints about they way they run at all.

BTW: I spent some time and googled for table oriented programming and found a large number of references to a small number of articles. The link at the top of this thread has many of the same words as the articles. I couldn't tell if they're by the same author(s) or just cut & pasted in there.

I also spent some time on the "OO is bad" and "structured is good" pages on the same site and don't think I found one assertion about what OO claims to be or actually is that I'd agree with. And I won't get that time back before I die, either.

The notion of a language or framework that lets you work in a relational or data oriented fashion from UI to persistence is kinda cool. Like PowerBuilder, it could be extremely productive in a small set of problems. But casting it as an alternative to OO doesn't seem to be the right argument. It could be a nice OO design as well as a nice structured design.

[Gerald Davis]

I don�t know about any musc soundtrack but schindler's list isn�t to bad and I like the music played in silence of the lambs when the villain starts dancing to that queer music then reveals himself like some sort of queen bee. If anyone knows what that song is called, I would be greatfull.

I know that good OOP is hard to do; it is like a car that is designed for a skilled driver like Michael Schumaker not one designed for an average person. I don�t have any problems with the high learning carve with OOP, it is because OOP has so much elements to it when something goes wrong, it is harder to find the problem.

If working in a team of inexperienced developers, it is easy to give them I couple of rules to follow. I will use these roles when I start my open-source development later this week.

1.Keep the functions small and use functions instead of inner loops.
2.Use nested functions to reduce the need of global variables.
3.Never used global variables from another module
4.All global variables will start with g_ or g_c_ if it is a container class.
5.Create factory-methods to simplify any complicated object construction.
6.Make ample use of assertion, use at near top of function is a good place to start.

Any ideas of how I can improve or ad to the list.

[Gerald Davis]

It seems that I made an error on what I ment by globel veriables. What I ment is module level veriables.

[Ilja Preuss]

Originally posted by Gerald Davis:
I know that good OOP is hard to do;

Good *programming* is hard to do. A good assembly programmer will start using jump tables somewhere in his career to decouple his code. A good structured programmer will sometime start using function pointers to do the same. A OO programmer "simply" uses polymorphism.

Or perhaps it isn't that hard at all. Nine year old kids can write OO programs... http://www.squeakland.org/

it is like a car that is designed for a skilled driver like Michael Schumaker not one designed for an average person.

Now you are talking about Lisp, aren't you?

Seriously, I don't think you are right. Good OO programming needs experience, but you can learn it. Just don't expect to be good at it from the beginning.

And by the way, the name is "Schumacher"... :roll:

I don�t have any problems with the high learning carve with OOP, it is because OOP has so much elements to it when something goes wrong, it is harder to find the problem.

That's an interesting statement, but one I have problem to connect to. Would you like to share a story?

If working in a team of inexperienced developers, it is easy to give them I couple of rules to follow.

...

Any ideas of how I can improve or ad to the list.

In my not really so humble opinion, a list of simple rules isn't going to help them much - regardless of what the list looks like.

What will help them is
- getting feedback on how they are doing early and often,
- getting to work with experienced people they can learn from, and
- learning the skills to improve the code while they learn about better ways to design.

The one technique that helped me personally most in this regard is Test Driven Development. The only thing I could imagine to be more important might be a very collaborative working style - using regular retrospectives and probably pair programming.

[Stan James]

I don�t have any problems with the high learning carve with OOP, it is because OOP has so much elements to it when something goes wrong, it is harder to find the problem.

I can empathize with this point of view. When I had a 20,000 line COBOL program and wanted to know where a field is referenced it was a simple search in the text editor. Of course the answer was "the field is reference everywhere".

I had huge complaints about 4GL tools that made it very hard to find things with code hidden away in button events and menu widgets and no good search or cross-reference tools. I wrote my own PowerBuilder tools to export everything to text and navigate it.

One benefit of using clear architectures and common patterns in OO is that you often know right where to put or look for a bit of logic because the design tells you where it should be. I rely on the search and "open declaration" features in Eclipse ... a good IDE is a huge help. It's still frustrating when the tool takes you to an interface and leaves it up to you to figure out which implementation was involved in a problem.

[Gerald Davis]

Originally posted by Ilja Preuss:


In my not really so humble opinion, a list of simple rules isn't going to help them much - regardless of what the list looks like.

What will help them is
- getting feedback on how they are doing early and often,
- getting to work with experienced people they can learn from, and
- learning the skills to improve the code while they learn about better ways to design.

The one technique that helped me personally most in this regard is Test Driven Development. The only thing I could imagine to be more important might be a very collaborative working style - using regular retrospectives and probably pair programming.

That's interesting, educate the developers while they work on your project. I wonder if that works well on an open-source project. Unit testing will be important in my project or using plenty of assertions. Because Python doesn't specify type in function declaration I will need plenty of assertions.

I am very much stubborn about not using OOP in my design; however, I understand the benefit of competition and if I was to create an object oriented version along with an my procedural one, the best methodology will shine in the end.

Because my application is made up of loads of independent functions it would make my applications easier to convert to any good object oriented design next to no time; I can put most functions into any class or module without breaking any existing code, I am already moving function back and forth from and to modules as I cycle between designing and coding; doing that with OOP would never be that easy.

So many implementation factors make it necessary to change design at any stage. Most those factors are down to not having enough experience with the system being developed, not enough knowledge libraries that are being used, not knowing being able to predict future changes in language or libraries.