search

RubenVerborgh / Hydra-Architecture-Diagram

6 stars 2 forks source link

Resources depend on errors #2

Open tpluscode opened 7 years ago

tpluscode commented 7 years ago

I'm not sold on that idea. If anything I'd say it was the other way round because errors don't exist on their own. They are only a side effect of an operation gone wrong. Hm, I didn't even use the term Resource...

RubenVerborgh commented 7 years ago

I made resources depend on errors, such that a resource (type) can indicate "these kind of errors can occur".

More or less the same way that a Java ArrayList depends on Error, but not the other way round.

Would that make sense?

tpluscode commented 7 years ago

I see. Although I'm not sure I understand how the elements depend on one another. I feel like the term is used in more that one sense.

RubenVerborgh commented 7 years ago

Mostly intended as "uses", I think.

tpluscode commented 7 years ago

I was just inspired today by a presentation on hexagonal architecture and it brought up the dependency inversion principle which I realize now is what I was thinking about unconsciously here.

A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions.

In this particular case I would like to view Error as an abstraction. Interface, if you will. This way implementors are given a clear signal that it defines a base contract and a possible extension point. We would at the same time provide a basic realization of said contract. Similar pattern could (possibly) be applied to collection filtering, field constraints or URI Template field serialization. Of course, anything not defined in the Core would be ignored by clients unaware of the extended semantics.

That said, I'm not yet sure how such open design would affect the core specification...

Does it make sense? Is this something you can sympathize with?

RubenVerborgh commented 7 years ago

Dependency inversion is great for software architecture indeed, but we are designing an ontology here, not a software product. As such, it is not clear whether the principles also apply.

However, I agree with all of the examples that you've given. Error, being a base class, is indeed an abstraction. The base class Resource depends on the base class Error; but concrete resource subclasses will have concrete error subclasses.