<div dir="ltr"><b>Introduction</b><div>In order to follow Single Responsibility Principle, I break my types (but let's talk about classes) into smaller pieces, decouple it and try to give every single piece a separate functionality.</div><div><br></div><div><b>Motivation</b></div><div>Extensions, as a mechanism to extend an existing type, improve this kind of decoupling and make it possible to keep an extension in a separate compile unit (file).</div><div><br></div><div><i>Additional observation is that I personally don't see any purpose or value of an extension put in the same file as the type it extends. Ultimately, we will finish with a large class, with a lot lines of code, as if we put extensions' implementation directly in the type.</i></div><div><br></div><div>So, let's consider the cases when we want to put extensions in a separate file (separated of the original type file).</div><div><br></div><div>But here, I find the problem to access private members of my original type. If I define it to be "private" (which is my intention), unfortunately, I cannot access these members in the extension, but I need them.</div><div><br></div><div>Also, I see it very regular and useful to access original type members in an extension. As the name implies, we extend it. Why not to have full access to original type? We cannot break any logic or violet something.</div><div><br></div><div><b>Example</b></div><div>Let's consider an example where we have UsersViewController which has a stored property "users" (let' say it is our model) and we want to keep it private. Let's suppose that UsersViewController uses UITableView and it handles datasource/delegate implementation. But, let's move datasource/delegate protocols implementation in an extension in a separate file named UsersViewController+TableView (Obj-C category naming style). This extension cannot access "users" property, because it is private.</div><div>There are many other examples where we can apply the same approach.</div><div><br></div><div><b>Solutions</b></div><div>- Add another access level modifier (but it would be too much to have only one for extensions):</div><div>For example <b>extensionprivate var users = [User]()</b></div><div>This looks bad and complicates general understanding of access levels modifiers.</div><div><br></div><div>- Keep the existing access levels to work as-is, but allow marking original type with something like <b>@extension-internal</b>. <b>This will just allow "private" access level to be visible inside any extension of the type.</b> (<b>I personally like this approach</b>, because all Swift access level modifiers will work as it is designed, but if a developer mark the original type with @extension-internal, it will just make private modifier visible inside the extension, but it is clearly stated it was the developer's intention).</div><div><br></div><div>- Modify "private" access level to be visible in an extension. I suppose it is now not possible, because it will break your private vs fileprivate functionally.</div><div><br></div><div><b>Benefits</b></div><div>We (developers) can follow SRP, keep our classes smaller, keep our files smaller, without mixing different levels of abstraction, keep class (file) cohesion very high. Accessing private members of original type does not break SRP or violate a good design, especially in most cases when we are talking of an extension, we are talking about behavior extension (functions or protocol implementations). We will continue to encapsulate our functionalities in well defined types, keeping private all the things we don't want to share with outside world, but allowing it to be used directly in our type extensions.</div><div><div><br></div><div>Best regards,</div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Uros Krkic</div>
</div></div>