Tables Already Exist In Oop

Have you ever looked at the Object Inspector in visual basic or delphi?

Guess what that is: a table.

OOP already has tables, they just are tables with side effects.. OOP is not separating the data from the methods (procedures), it welds them together.

Take a look at this.. what is this:

It's a table! A table of object properties...

Or see this:

These are just displays. We cannot tell what's under the hood from just looking at them. Plus, having tables and being table-oriented is like having objects versus being object oriented.

It is a display or view, yes, like a spreadsheet; this display of the published object shows that there is at least a tabular structure that objects have to them similar to IniFile which is a long list of name/value pairs. One could map this object inspector to a database fairly easily, since it is boxy and tabular. That's why object relational mapping works to some extent because objects are a bit tabular in shape. When you exit or close vb or delphi, there is persistence - this object inspector data is saved to a DFM form file or similar... that sounds like a reinvention of a database...

Related: ObjectsAreDictionaries

Dictionaries with methods, though? Methods tightly bound to the data..

OO-ness doesn't require they be "tightly bound". Strong typed/compiled OO languages tend to bound them tightly, but they do it with every language element, not just methods.

Structs in Cee are also rows/tables.. See DumbTables

Beware of conflating the term "table", which typically refers to persistent bags of rows in SqlLanguage, with various tabular displays that may be used for anything from spreadsheets, to object browsers, to the grids commonly used to help visualise relations in the RelationalModel. None of these have much to do with each other. Resemblances are more coincidental than reflective of significant underlying theoretical commonality. Their differences are much more profound, and are defined in terms of what each of these lacks in relation to the others.

The resemblances are why object relational mappers exist - but how can we remove mappers and solve the problem without any mapping? I don't see a solution to the problem, I just see a big mess. If I want to save this object I can use files and a DFM form file like delphi, but this is reinventing the database... rolling your own widget storage database to save the state of the widgets when you close the program. The database wheenies seem to think object relational mapping is a bad idea, and yet it is the only practical solution available.. what other options can we possibly have? If I want to save the widget data, i can either roll my own file storage system (dfm files in delphi) or I can object relationally map it to a database. Both are bad practices because we want to remove the mapping, and stop reinventing the database. Another option would be to have a database where you store the widget information inside the database cells, rather than via the columns. I mean take a button entirely and store it in a single cell, rather than dissecting the button and putting its properties into columns through mapping. The disadvantage of putting the button in a cell (or as a blob) is that this button now no longer can be accessed relationally.. it's stuck inside a cell and the data is just a blob in the cell. The advantage of mapping the data (call it object relational mapping if you want) to table in a database is that it splits up the widget properties into columns that can now be accessed relationally. Until these issues are resolved (which they may never be) the industry will continue to struggle with mappers or roll your own file storage formats, I just don't think TheThirdManifesto has the final word on this mapping problem, they've just barely touched the issue and left a lot of questions unanswered in my opinion.

If you're in a mindset of using objects to model problem domains with the database merely providing persistence, object relational mapping may seem to be of value. A typical approach is to create Customer, Invoice, Employee and Cheque tables in the database, and mirror them in the object-oriented client as Customer, Invoice, Employee and Cheque classes. Or vice versa. Yes, that might make OR mapping seem useful.

However, that's a labour-intensive and inflexible way to build applications. Rather than using both object-oriented programming and the database to (redundantly) co-model the problem domain, leverage the strengths of both: Use OO to model the computational domain, and use the database to model the problem domain. Remember, the DatabaseIsRepresenterOfFacts -- it is not merely persistent storage for dead objects! In database driven applications, try using classes to model forms, reports, data-entry widgets, menus, queries and ResultSets. Use the database for Customer, Invoice, Employee and Cheque tables. Use the database to model facts about the world, and use the client application(s) to present and edit those facts.

Applying this mindset results in more flexible applications that leverage the power of both DBMSs and OO, with no need for OR mappers.

See OopBizDomainGap, OopNotForDomainModeling

MarchTwelve