What are the main aspects to consider in the design of a customised pattern?

Question

(I’m trying to phrase this question to be as specific as it can get, but since I’m mostly interested in high-level design it might be a bit still too vague. Let me know if I need to edit it or specify it any further!)

I have recently made a customised pattern for data sharing in Swift, and I’m looking for ways to validate my solution and improve it further.

What techniques are used to verify the design of a customised programming pattern? Apart from memory management, thread safety, and access control, what are some other important aspects which I should consider when I first implement it?

In my specific case: The idea combines singletons and mediators to share data between different parts of the app. This would allow the developers to easily access the same content in different parts of the software. (And can also work as a cache between different UI elements of an application.)

I have specified the solution as a class with the following properties:

• It can be specialised with any give type.
• Creates a shared instance on the first access.
• It contains a public optional property with the given type, which holds the data we want to share.
• Exposes a function which other objects can use to subscribe and unsubscribe for notifications about the data modification.
• Sends a multicast notification to the subscribers when the data is modified.

You can find the work-in-progress implementation (in Swift) here: https://github.com/endanke/Observator

My question in context of the example: What are the main aspects that determine if this specific class is ready to be used in a production environment? I have tested it in a small scale software and although it works as intended, I would like to rule out some possible design issues that I might not considered yet.

Answer 1

I think your use of the word "abstraction" isn't quite right here, and us maybe putting people off answering..

What makes a third party package good and useable in enterprise applications is:

1. Zero Defects
2. Zero Defects
3. Thinks of the edge cases you havent thought of
4. Clear pattern of usage. ie. "the way it's meant to be used"
5. Dosen't interfere with other things. ie. you can plug it in and pull it out easily.
6. No dependencies
7. Zero Defects

In your specific case, it looks like you have implemented the Meditator pattern. I would be looking for how you deal with unsubscription, double subscripition, naming of events, binding etc

And whether you have a nice clear pattern of usage which is hard to get wrong, needs minimal code on my part whilst also being super flexible.