PeterC:or I’ve identified a shortcoming in ORM (something the OO community thinks might be the case?)?
I haven't heard this argued. ORM provides different abstractions from OO, but the differences are in degree of succinctness, not in the scope of things (actualities, as opposed to abstractions) that can be described. OO however provides some hints at the kinds of operations that might need to be efficient, such as in the queue example below.
PeterC: the different concepts between ORM, ...and the relational paradigm
ORM and the relational paradigm are built respectively on logic and set theory, and thus are two sides of the one coin. ORM is however more powerful because it insists on elementarity, which is almost isomorphic to relational sixth normal form, and on verbalisation, which allows us to discover and verify models that match our natural understanding of a problem domain. In the process, it elicits enough structural constraints (uniqueness) that an efficient database design can be automatically constructed, where a 6NF relational schema would not be effective.
PeterC: things like abstract classes (for collections and queues, etc)
When I don't have any ordering requirement in a collection of things, I don't need to specify how those things should be arranged.
When I have an ordered collection of things, I use the Ordinal value type: "Person is in Ordinal place". To insert concept instances in here, we see how natural the verbalisation is: "John is in third place". The ability of a queue to remove the person who's in first place and re-number all the subsequent entries is an implementation detail; ORM does not attempt to address that issue.
Here's where OO can inject an implementation detail into the semantic model, by requesting a specific data structure that can do that renumbering efficiently - the queue. However, since not every queue implementation will have the same profile of efficient versus inefficient operations as every other implementation, it would be preferable not to specify a class of data structure, rather to provide a way to indicate the types of performance envelope expected for different classes of operations. This would allow proper performance prediction, analysis and management of user expectations. Because OO tends to take more shortcuts in this respect, the success of an OO project (its ability to meet expectations) is dependent on hidden implementation details that cannot always be known. I personally can recount actual cases where such oversights have cost millions of dollars and postponed or prevented project success for years.
Furthermore, I would argue that injecting operational and implementation details into a semantic model is often:
- Confusing, by diverting attention from what and why (more on this below), and
- Wrong, the injection happens at a time during modeling at a time when the actual requirements cannot be known,
- Unnecessary, because in most cases data structures exist or can be adaptively applied after the performance is shown to be inadequate - provided that the underlying algorithm is expressed in terms of things in the real world. In the case of a relational database, that can be as simple as adding an index.
The software industry will continue to fail until it stops jumping to solutions (answering the
how question) until after it has satisfactory answers to the ones the business is concerned with, which are
what and
why. It's in the nature of engineers to want to always know how - these are people who like me have spent their youths taking things apart to find that out - but our selection and training of such people must be changed to teach them
when to ask each type of question.
Your FlyingThings category is unnecessary, and should be modelled using a AbilityToFly or FlightCapability object, such that any number of categories of creature (and things too!) can have that ability.