(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.

  • 3
    Use of singletons to lower coupling sounds suspicious. Mutable singleton introduces a strong coupling between all components that have access to it.
    – Basilevs
    Commented Jun 22, 2020 at 5:52
  • @Basilevs you are right, coupling isn't the correct term again, I need to update my question. In this case the point of the singleton setup would be to provide a single source for the same data in different parts of the the software. In my specific case this allows me to use the same data in different UI stages of the mobile app, which will stay in the memory even if the lifecycle of one screen ends.
    – Endanke
    Commented Jun 22, 2020 at 6:38

1 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.

  • Great answer, thank you! You are right, abstraction is not the correct term, but I'm also not sure about third-party package. What I'm specifically thinking is a "combination of design patterns" or "generalising a solution for reusability" and not sure what's the right expression. Maybe "customised pattern" could be better. My approach is close to a Mediator, but since it's using a generic type and a shared instance I think I needs some additional considerations, which made me think about this question. I'll accept the answer a bit later in case someone wants to add anything more.
    – Endanke
    Commented Jun 22, 2020 at 4:49
  • 2
    I think you are missing a criterion: No Defects. :-) Commented Jun 22, 2020 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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