Make inheritance possible

On our radar

Sometimes I do not want a type to identify a specific object. For instance this case:

A real-estate agent has a database with 3 types of buildings. Community, Residential and Office buildings. He builds a web service that returns a list of buildings based om  the address. A residential building has people living in that building. A community building does not have residents but a community  building does have a description property like a church, funeral home or school, etc. All buildings have addresses and based on the type of the building different properties apply.

I know how to work around this in Outsystems but the way a modal is created is simply not right. It is not the truth and therefore just plain wrong in my opinion. Not being able to use inheritance also causes unnecessary data or relations in you database. Some options:

  • Create a different entity for each building resulting in multiple tables
  • You could also use a type for each building but that would result in a building of type community having Null or 0 residents. This is also wrong since residents do not apply to community buildings. Residents property on community buildings should simply do not exist.
  • Create a building and foreign key in the table for each building type to the specific building type properties that apply. Again resulting in more tables, relations.

I know when writing code and using inheritance a Object Relational Mapper “ORM” does the same thing and also creates relations, types and tables as needed. The difference is that my object [Building] in this case is valid and the absolute truth.

Returning a list of buildings without a base class [building] via the web service becomes complicated and hard to understand for the party that will consume the web service. Please change this / make it possible.

Created on 1 May 2017
Comments (3)

One of the principles of the OutSystems Platform is that they follow the 80/20 rule pretty strongly. This is why you don't see inheritance.

To this specific example, it sounds like you need a base "Building" entity with the common information, and then a "Community", "Residential", and "Office" entity, likely with an ID of type "Building Identifier", for the information specific to that type of building. This is the best way to model that kind of data in a relational DB anyways.


Hi Justin,

Modelling this in a database isn't theproblem and is very doable in Outsystems as well. I also think you should codeyour model representing the truth. The database model is just the way data issaved. Instead of a relational database an application could also use an objectorientated database.

therefore i think inheritance it should besupported as well.

Danny -

The question is not "is inheritance useful?" but "is inheritance inline with the OutSystems philosophy of development?"

"The database model is just the way data issaved."

Not in OutSystems. In OutSystems, the database model IS the model.

All development systems are filled with compromises. Languages like C++ let you do anything in the world, but the compromise is that they are difficult to work with, and by giving the developers enough rope to hang themselves, you often get developers making some really big mistakes.

A compromise OutSystems has made, is to jettison a ton of things that they recognize have benefits, but on the whole are detriments. Some examples:

  • No code branching. Code branching is great in a well run development team, but in practice it is very easy for someone to branch on Monday with a Thursday deadline, make a ton of breaking changes to things, and no one on the team knows until Thursday morning when then merge and NOTHING WORKS.
  • OOP. For every programmer who uses OOP sanely, there are a dozen developers who will hang the development team for three days as they agonize over "should this be an interface or a class? Should this be a concrete class or an abstract class?", or who build these disastrous mountains of objects and inheritance making every project look like a biological taxonomy chart.
  • Null values. Null values are super useful. They are also one of the most common causes of bugs, right up there with automatic variable initialization, "=" vs. "==" vs. "===" vs. "eq", and "not (0 or null) == true".
  • Recursive structures. Like OOP, these have their place and can be really useful, but much more frequently we see developers making some really poor decisions around them.
  • Advanced SQL makes it nearly impossible to directly access tables by name. Even if you know the names by reflecting the metamodel, the tool makes it deliberately hard to do this. This ensures that developers have to work super hard to accidentally destroy the database or create security problems.
  • eval(), reflection, callbacks, delegates, lambdas/closures, and other similar techniques. As useful as these things are, they can create a true mess in a hurry, and they make debugging and code maintenance substantially more difficult. As a former Perl slinger, I am all too familiar with "write once, edit never" code.

By deliberate rejecting these common conventions that you see in languages like C++, Java, C#, JavaScript, PHP, etc., OutSystems has made a development tool that dramatically decreases the risk of development. I can hand this tool to someone who is less experienced and trust them to not accidentally create a SQL injection vulnerability in the search screen. But it *does* sometimes frustrate developers who are used to working with certain patterns like OOP.