Interface and abstract entities - Mendix Forum

Interface and abstract entities

26

It would be very cool to be able to use interface and abstract entities in Mendix, just like in Java.

See https://docs.oracle.com/javase/tutorial/java/concepts/interface.html  and https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html

An example of how an interface entity could be used: In the (fake) screenshot below you see a Person interface-entity, which is implemented by the Employee and Customer entities. Employee uses the System.User entity as generalization, hence inherits the Name attribute. With both entities implementing the Person interface, you can use both of them as a Person. This could come in handy, for instance in the case you would like to create a overview page with all Persons (Employees and Customers) in a single list.

 

asked
5 answers

Really interesting feature to have !

Please vote !

Created

Thanks Otto!

Spread the word, because we need more votes! ;)

Created

We really need this, would make it so much easier to reuse microflows if you can specify a interface as input parameter.  Then you can pass all entity that implement the interface.

 

Also in Java you can only extend 1 class (inherit) but you can implement multiple interfaces.

Created

Hi Marnix,

Thank you for your comment on my idea. Sorry my reply comes so long after. The difference between generalization/specialization and interface/implementation is that with interfaces there is much more flexibility. For example when I create a module which I plan to publish in the Marketplace, I might add a microflow which expects an entity as input parameter but I don't want to force the developer who's going to use my module to use a specific entity. Let me elaborate this with a specific case:

Let's say my module microflow needs a Person (ModulePerson in the above picture) as input parameter. In the app which is using the module, there is a Customer entity (AppCustomer in the above picture) which is already a specialization. You can see that it will be a challenge to make AppCustomer a specialization of ModulePerson. If ModulePerson is an interface it's much easier. Then only the names of the attributes are compared and AppCustomer has the same attributes as ModulePerson.

Created

Isn't this just an example of a poor data model? That could be solved by linking accounts (inherits from system user) to employees and or customers.

And making a generalization entity called Person that both customer and employee would use.
I don't really see any benefits over generalization / one to one? Could you explain that?

The generalization Person could be passed to microflows and can receive Employee or Customer objects which then can be cast in order to trigger specific logic per specialization.

 

Created