[swift-users] Simultaneous accesses, but modification requires exclusive access

somu subscribe somu.subscribe at gmail.com
Mon Jul 24 05:35:11 CDT 2017

Thanks Joanna Carter, sorry forgot to mention it uses generics, so would contain associatedtype if protocol is used.

Is the below mentioned approach the usual way to hide implementation details or is there a better approach ?

With this approach, I had to pass functions of C1 as closures into Helper functions.

struct Helper {} //This is could be a protocol / struct / class

class C1 {
    private let helper = Helper()

Please let me know if the question is off-topic and needs to be posted in a separate thread / elsewhere.

Thanks and regards,

> On 24 Jul 2017, at 5:43 PM, Joanna Carter <joanna at carterconsulting.org.uk> wrote:
>> Background:
>> Just a little background into what I was trying to achieve (I could be wrong):
>> - I have a set of classes C1, C2, C3 which has a lot of common code
>> - I would like to build something that can be reused without exposing the implementation details. (I can subclass but would expose the underlying functions, same applies to protocol as well)
>> - I thought I would build helper class / struct which would contain the common code. I can make the helper a private property so that the functions wouldn’t be exposed to the instances of C1, C2, C3. In order to achieve that I had to pass some functions from C1 into the Helper struct.
>> Question 2:
>> - Is this problem (hiding implementation details) normally tackled using Helper class (or struct) or is there a more better approach ?
> Usually, as long as the protocol doesn't reference self or have associated types, I would use a protocol as the "abstract" type and then you could implement it in either a class or struct.
> Joanna
> --
> Joanna Carter
> Carter Consulting

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170724/bc732a26/attachment.html>

More information about the swift-users mailing list