3

This is a common design pattern, but what is its name, and are its pros/cons discussed in any open literature? What do you think the pros/cons are?

// get a token object that identifies this registration
var registration = Registry.register("Foo", ...);

// unregistration accomplished via the token object
registration.unregister();

As opposed to:

Registry.register("Foo", ...);
Registry.unregister("Foo", ...);

Or even:

var registration = Registry.register("Foo", ...);
Registry.unregister(registration);
  • 1
    If it's a common design pattter how come the name is not as common as the pattern itself? Is is a pattern at all? A pattern is something more elaborate. Could it be a common practice? – Tulains Córdova Jul 7 '16 at 14:45
  • 2
    @TulainsCórdova It's a "pattern" because it's a distinct and recognizable way of solving a specific problem. It's common because it can be found in the wild in many libraries/APIs across many different programming languages. The name may be as common as the pattern itself - I simply do not know it. Or, it may not have a name. – TypeIA Jul 7 '16 at 14:55
  • 1
    This just seems like ordinary OO mechanics to me. – Robert Harvey Jul 7 '16 at 19:16
  • 2
    It probably has a name, but I can't remember it. The point of this pattern is that I avoid temporal coupling, where an API consumer has to know which functions may be called in which order. Your registration object uses the type system to only expose those parts of the API that make sense in the current state. This is not inherently about OOP but about type systems. Your last example with the static Registry.unregister(registration) is equivalent to registration.unregister() for this purpose: we just need to make sure that a registration was created before unregister() can be invoked. – amon Jul 7 '16 at 21:00
1

It isn't a pattern, but an anti-pattern, in that the API requires the declaring scope to manage the token and will leak the registration token (and probably the registered object too) if you fail to do so properly. This could be remedied through the use of a destructor function for the object.

But given the sample code appears to be Javascript, which has no such facility, you have to manage the object's registration yourself.

  • In a garbage collected language, what alternative pattern prevents the problem of "leaking the registered object" if the user doesn't explicitly call unregister()? (Of course in a language with scope-based object lifecycles like C++ this would be resolved by implementing a destructor, as you suggest.) – TypeIA Jul 27 '16 at 13:58
  • The problem is that even though a runtime environment might have garbage collection, it doesn't necessarily provide a destructor-like function. For example, javascript() as the OP's example seems to be, doesn't. And even runtimes that do, such as JVM, don't guarantee to call the Java language's finalize() method. It's easier to write code which is unstable in such environments. – Huperniketes Jul 29 '16 at 5:43
  • I agree completely. Your answer claims this is a defect in the pattern rather than in the programming language design, and I'm not sold on that idea yet. To justify your claim, can you show an alternative practice which doesn't suffer from the same problem of requiring the caller to keep track of and free resources (in the OP example, by calling unregister())? – TypeIA Jul 29 '16 at 16:30
  • Unfortunately, at this level of research I've conducted on architectures and design patterns, the alternatives I can devise to manually managing the object's lifecycle (e.g., a background process which periodically checks and removes unused registry entries) is just compensating for the weakness of the language (or platform) or violates SOLID principles. Thank you for asking for what I didn't clarify: it's an anti-pattern in the API (some do this intentionally), which in this case is necessitated by the short-coming (not technically an anti-pattern) of the language. – Huperniketes Jul 29 '16 at 20:38
0

The code you've provided isn't clearly or unambiguously an example of a token "pattern." What you've provided just looks like "object oriented programming."

Tokens are special objects (usually strings) used for identification or authorization when connecting to another service (or process, or namespace). And in those cases, there isn't a singular pattern name I'd use. You're simply "using a token."

You could dig a little deeper and name purpose of the token, like a session token or authorization token. But, it's not really a formal "pattern" per se. It's just, "using a token."

  • Fyi: the GoF has defined a patteen called "memento" and claim it's also known as "token". This is still smt different, but shows that "token" must be considered with a broader view – Christophe Sep 26 '16 at 6:43
  • @christophe Hmm .. i didn't recall that was aliased as such. In any case, I understand that the term can have a few different meanings. But, the more popular idea, which seems to be what the OP is going for, is the session/security-type token... No? – svidgen Sep 26 '16 at 12:26
  • i'm not sure: i have understood that it was about registration btw object (e.g registration of a class to a factory or to an observer) and what op calls token is the object on which you would perform subsequent operations. May be OP could clarify – Christophe Sep 26 '16 at 12:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.