You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the Neo4j::Types documentation actively encourages driver authors to inherit method implementations that depend upon a specific data structure, which is to be provided by the driver. This violates encapsulation.
As a result, Neo4j-related modules are coupled more tightly with each other than one might like. Making a change in the Neo4j::Types implementation to improve compatibility with one driver runs the risk of reducing compatibility with another. Following the principle of least knowledge can reduce that risk. Basically, you should make as few assumptions about another module’s internals as possible.
Driver authors should be strongly encouraged to write their own implementations of the methods defined in Neo4j::Types. This allows authors to better adapt to the peculiarities of each driver while limiting action at a distance.
Existing drivers can probably just copy the code from Neo4j::Types, so the impact of such a change should be relatively small.
The text was updated successfully, but these errors were encountered:
Some methods could probably be inherited safely. For example, for a custom path class that already has an elements() method, the nodes() and relationships() methods could be mixed in from a role without needing to know the data structure – they would just call elements() and filter the return value. The same applies to get() and to many methods in the Point type.
But I think these are all refinements for a later date.
Right now, the Neo4j::Types documentation actively encourages driver authors to inherit method implementations that depend upon a specific data structure, which is to be provided by the driver. This violates encapsulation.
As a result, Neo4j-related modules are coupled more tightly with each other than one might like. Making a change in the Neo4j::Types implementation to improve compatibility with one driver runs the risk of reducing compatibility with another. Following the principle of least knowledge can reduce that risk. Basically, you should make as few assumptions about another module’s internals as possible.
Driver authors should be strongly encouraged to write their own implementations of the methods defined in Neo4j::Types. This allows authors to better adapt to the peculiarities of each driver while limiting action at a distance.
Existing drivers can probably just copy the code from Neo4j::Types, so the impact of such a change should be relatively small.
The text was updated successfully, but these errors were encountered: