daniel added a comment. In https://phabricator.wikimedia.org/T118860#1823155, @Bene wrote:
> I wonder if we could just use the decorator pattern (isn't that basically the > "interfaces" approach?). With decorators, you can't mix and match: you only have one perspective (role), and no way to get the other perspectives. You can give the decorators a way to access other decorators, of course - that's essentially what the Role Object Pattern is. > Another idea I found is the Extension Objects Pattern > (http://st.inf.tu-dresden.de/Lehre/WS06-07/dpf/gamma96.pdf, > https://msdn.microsoft.com/en-us/library/ms733816%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396). > That seems to be somehow related to the roles pattern (is it actually the > same?). It's at least very similar. It seems like some authors use "Extension" when the roles share a common base interface, and "Role" if they don't - but others use the terms differently. > I'm not sure if I understood Role Object Pattern correctly. To me, it seems > that it is created to support objects which occur in completely different > roles (like the Character/Director example on enwiki) while in our use case > the statement doesn't suddenly become a sitelink. A sitelink with an url > attached is still in the role of a sitelink and an unit snak with some > normalized unit is still a snak. And the Character and the Director are still people, not hydrants. A Sitelink with a URL attached could be said to have a UrlProvider role (which defines a getUrl() method). The code that uses the URL may or may not also use the "main" object, or other roles. A Snak with derived values could provide an AlternativeValues role (which defines a getValue($name) method). A ConstraintViolationSubject role could be added to Statements, without the core model caring. It would be simple to include the constraint violation info in the output. A snak with an EntityId value could have the target's label attached via a ThingWithLabel role. The label could be included in JSON output, for easy display, simply by registering a serialiezr for that role. > Do I understand the intention of the Role Pattern correctly? Is that really > (from an abstract point of > view) what we need conceptually in our data > model implementation? It seems to me the following requirements indicate the Role Object Pattern: 1. we want the data model to be used for input: 3rd party clients should use it to represent the output of the web API, and the content of JSON dumps, including any extra info like derived values, sitelink URLs, or entity labels. 2. we want the model to be extensible: it should be possible to associate additional data with parts of the model without modifying the model component (e.g. attach constraint violations). Without requirement 1, we could go for the "injected lookup service" approach which we currently use in many formatters. Without requirement 2, we could go for subclassing or decorators (though this gets a bit messy, since we can't mix & match freely). If we want to cover both requirements, the ROP seems a good match. And I don't see any good alternative, really. The question has been raised whether it's a good idea to look for an approach that can cover all our "extra data" needs. Maybe the requirements are overly broad, leading to an overly complex solution. But I think the essential requirement is actually always the same: provide a way to //associate// additional data with a //specific bit// of the data model, for use during rendering or serialization. Where that information comes from and how it is used for generating output doesn't really matter for the modeling requirements. TASK DETAIL https://phabricator.wikimedia.org/T118860 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Bene, Lydia_Pintscher, mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331 _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
