Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommend that driver authors always write their own type implementations #4

Closed
johannessen opened this issue Jun 20, 2023 · 1 comment · Fixed by #5
Closed

Recommend that driver authors always write their own type implementations #4

johannessen opened this issue Jun 20, 2023 · 1 comment · Fixed by #5
Assignees
Labels
Drivers Compatibility with type implementations
Milestone

Comments

@johannessen
Copy link
Owner

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.

@johannessen
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Drivers Compatibility with type implementations
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant