Say a framework provides customizable services through an open class A, that exposes a shared instance to use as follows:
open class A {
public static let shared = A()
open func aService() {}
}
The regular usage of the service is as follows:
A.shared.aService()
Important note: the shared instance itself is also used from within the class A code or related code in the Framework.
Say you want to customize the service through inheritance, and you still want to keep the use of the shared instanced as follows:
override class B: A {
public override func aService() {
super.aService()
}
}
When you refer to the shared instance, unfortunately, it refers to the class A instance where you would like it refers to the inherited class instance.
B.shared.aService() // Failed!: This actually calls A.shared.aService()
One way to fix it is to make the construct as follows:
class A {
public static var shared = A()
}
Then you are sure before any use of the service within you app, to change the instance as follows:
A.shared = B()
B.shared.aService() // OK! This actually calls B.aService()
Though the whole thing works, I would like to make it automatic and not rely on the initial line that changes the shared instance.
How would you do that?
[CODE FOR PLAYGROUND] that illustrates the goal to achieve and to help you better understand the question
open class A {
public static var shared = A()
open func aService() {
print("\(type(of: self)): service (from A)")
}
}
class B: A {
public override func aService() {
super.aService()
print("\(type(of: self)): service (from B)")
}
}
A.shared = B() // Question : How to remove the need to this line, yet achieving the same functionality (and output)
A.shared.aService()
B.shared.aService()
// The output (which is correct) :
//B: service (from A)
//B: service (from B)
//B: service (from A)
//B: service (from B)
There's a solution, but...
I do, personally, agree with the other comments here. This really doesn't sound like a job for the singleton pattern.
In your current solution, you seem perfectly happy to overwrite the singleton instance mid-execution, which means it's not a singleton. There's only ever supposed to be one instance of a singleton, and if you can continually create and assign a new instance to the shared variable without breaking anything, then it's just not necessary to have this global state across your application.
However, for the record, you can achieve what you want with a struct that composes the static instances of each class, and which can detect the calling context and return the appropriate one each time shared is accessed:
protocol ExampleProtocol {
static var shared: ExampleProtocol { get }
func service()
}
struct ExampleProvider {
private static var a = A()
private static var b = B()
static func instance(type: ExampleProtocol.Type) -> ExampleProtocol {
return type == A.self ? ExampleProvider.a : ExampleProvider.b
}
}
class A: ExampleProtocol {
static var shared: ExampleProtocol {
return ExampleProvider.instance(type: Self.self)
}
func service() {
print("Hello")
}
}
class B: A {
override func service() {
print("Goodbye")
}
}
A.shared.service() // Hello
B.shared.service() // Goodbye
So, yes, you can achieve what you want. But there's a pretty strong case for saying that you shouldn't...
Related
I'm drawing a blank for some reason.. If I want to make a bunch of objects from a class, but I want each instance to have its own unique implementation of a certain method, how would I do this?
For example:
class MyClass {
var name: String
func doSomething() {
// Each object would have custom implementation of this method, here.
}
}
Do I provide each object with its own closure during initialization, and then call that closure in the doSomething() method? I'm trying to figure out the correct or "Swiftly" way to do this. I'm also thinking along the lines of something with protocols, but I can't seem to figure out how to go about this.
I think there're many ways to do it.
In case of Base class + some sub-classes (e.g. Animal, subclassed by Dog, Cat, etc), you can do this:
First of all it's a good idea to define a protocol:
protocol MyProtocol {
func doSomething()
}
Also provide a default implementation, which throws a fatal error if a class doesn't override that method:
extension MyProtocol {
func doSomething() {
fatalError("You must override me")
}
}
Now your base class confirms the protocol thanks to default implementation. But it will throw a fatal error at runtime:
class MyClass: MyProtocol {
// conformant
}
Child class, however, will run correctly as long as it overrides this function:
class MyOtherClass: MyClass {
func doSomething() {
print("Doing it!")
}
}
You could also move fatal error into base class, and not do any extension implementation.
In case of many instances of the same Class, that solution makes no sense. You can use a very simple callback design:
typealias MyDelegate = () -> Void
class MyClass {
var delegate: MyDelegate?
func doSomething() {
delegate?()
}
}
let x = MyClass()
x.delegate = {
print("do it!")
}
x.doSomething()
// Or you can use a defined function
func doIt() {
print("also doing it")
}
x.delegate = doIt
x.doSomething()
It can also be that you re looking for Strategy pattern, or Template pattern. Depends on your usage details.
Do I provide each object with its own closure during initialization, and then call that closure in the doSomething() method
Yes. That is extremely common and eminently Swifty. Incredibly miminalistic example:
struct S {
let f:()->()
func doYourThing() { f() }
}
let s = S { print("hello") }
let s2 = S { print("goodbye" )}
s.doYourThing() // hello
s2.doYourThing() // goodbye
Giving an object a settable method instance property is very, very easy and common. It doesn't have to be provided during initialization — you might set this property later on, and a lot of built-in objects work that way too.
That, after all, is all you're doing when you create a data task with dataTask(with:completionHandler:). You are creating a data task and handing it a function which it stores, and which it will call when it has performed the actual networking.
I'm trying to hide a inner class so the caller is not aware of it. If the caller want, they can get an instance of the inner class by using a public method. But the caller should not be able to directly get the inner class.
Example to show what I want:
class A {
static func getSettings() -> Settings {
return Settings()
}
class Settings {
func turnOnSomeThing() {
}
}
}
class test {
func testFunc() {
A.getSettings().turnOnSomeThing() // correct way of calling
A.Settings().turnOnSomeThing() // should not be possible
}
}
Is this possbile in Swift?
Why do both calls work in the test caller?
Both currently work because:
The first case, A.getSettings()... is a classic getter that returns an object. I'm just puzzled with the fact that a new Settings is constructed each time, but this is perfectly legit.
The second case, A.Settings().... invokes the constructor of Settings to create an anonymous object, and invokes some methods on it. It's ok, because the inner class is public, but it's weird.
Can you make the inner class private?
You could make an inner class private to avoid it being accessed from the outside world:
This would work perfectly well for an private helper class totally invisible to the outside world.
For Settings this is not possible, because getSettings() returns objects of this class to the outside world, and this makes only sense if the outside world knows the class to deal with it.
Exemple:
class A {
static func getSettings() -> Settings { // ERROR if Settings would be private
let helper = Helper() // purely internal use: Helper can be private :-)
helper.demo()
return Settings()
}
class Settings { // making private is not possible (see above)
func turnOnSomeThing() {
print ("On")
}
}
private class Helper { // Cannot be used outside
func demo() {
print ("Demo")
}
}
}
But how to do with Settings?
If you want to return Settings objects to the wild outside world you need to keep that class public. However, if you want to avoid that the outside world misues the inner class and avoid objects to be created from the outside wolrd, you can use access control on the constructor:
class A {
static func getSettings() -> Settings {
...
}
class Settings {
fileprivate init() { /// <=== ACCESS CONTROL internal or fileprivate
}
func turnOnSomeThing() {
...
}
}
}
This prevents the calls of the form A.Settings()..., but only according to swift access control: with internal you can still call the constructor from another file of the same module; with fileprivate the constructor can only be called from within the source file in which you've defined your external class.
This technique of making the constructor inaccessible while keeping the class usable is frequently used for classes which instances shall only be created via a factory.
This question already has an answer here:
In Swift 3, is there a difference between 'private class Foo' and 'fileprivate class Foo' in regards to member variables?
(1 answer)
Closed 2 years ago.
As the sample code here, what's the difference of private and fileprivate class in the same file in Swift?
// ViewController.swift
private class A {
var name: String = ""
let d = B.D()
}
fileprivate class B {
var name: String = ""
private let c = C()
private class C {
var number: String = ""
}
fileprivate let d = D()
fileprivate class D {
var number: String = ""
}
}
Since class A and B are in the sample file, A can't be any more private then B, right?
Sorry this is a very picky question, but I just want to confirm it.
Access modifiers in swift have been charged a few times during the past few releases.
For now, let me suggest a code sample instead of explanation first:
All code in one file:
fileprivate class Foo {
private var someVariablePrivate: Int?
fileprivate var someVariableFileprivate: Int?
private func makeBar() { }
fileprivate func makeFoo() { }
}
extension Foo {
func bar() {
let value = someVariablePrivate // OK
let value2 = someVariableFileprivate // OK
}
}
private class Foofoo: Foo {
override func makeFoo() {
// OK
}
override func makeBar() {
// NOK, because private
}
}
class Bar {
func foo() {
let object = Foo()
let value = object.someVariableFileprivate // OK
let value2 = object.someVariablePrivate // NOK - because it private to that class
}
}
Previously, private restrict access only to type definition, but within few lates version of Swift, it has been modified and updated, so even extension of same type can use private variables
As Apple mention:
File-private access restricts the use of an entity to its own defining
source file. Use file-private access to hide the implementation
details of a specific piece of functionality when those details are
used within an entire file.
Private access restricts the use of an entity to the enclosing
declaration, and to extensions of that declaration that are in the
same file. Use private access to hide the implementation details of a
specific piece of functionality when those details are used only
within a single declaration.
we could compare a bit this modifiers:
why do we ned both of them:
You may, however, want to mark some parts of your code as file private
or private in order to hide their implementation details from other
code within the app’s module.
When to use fileprivate
Although the keywords are almost the same, there is a clear difference in their use cases. Fileprivate access restricts the use of an entity within the same defined source file. The only reason you would use fileprivate is when you want to access your code within the same file from different classes or structs.
When to use private
The private keyword is used a lot more and restricts the use of an entity to the enclosing declaration and its extensions. The extensions, however, have to be defined within the same file. In other words, private declarations will not be visible outside the file. You can use this keyword to only expose the minimal code needed to interact with the entity. This will improve readability and makes it easier to use and understand your code for others.
your question: Since class A and B are in the sample file, A can't be any more private then B, right?
In case of class A with private access specifier it won't be accessible outside it's declared scope.
In case of class B it will be accessible to the class A but it's private properties won't be accessible in class A
For more information, you can refer to this interesting article:
https://www.avanderlee.com/swift/fileprivate-private-differences-explained/#when-to-use-private
I'm relatively new to swift and searched around but could not find any satisfactory answer to my problem. I would like to have a Singleton class instance which can be initialized with some variables. E.g.
public class Singleton {
var car: String
var bus: String
init(car: String, bus: String) {
self.car = car
self.car = bus
}
func drive() {
print("I will drive")
}
}
public class SingletonConsumer {
// create an instance of Singleton Once
var driver: Singleton = Singleton(car: "honda", bus: "volvo")
driver.drive()
}
public class driverClassWorld : SingletonConsumer {
driver.drive()
}
how can i achieve it? I tried protocol but issue i am hitting is how to instantiate singleton class with parameters.
I don't get this problem?
First remove singleton from your brain for a moment. Because I think you have the wrong idea on what a singleton is.
Now lets rephrase your question to: "How to instantiate a class with parameter"
Its like this:
import Foundation
class Test {
let someText : String!
init(something:String){
someText = something
}
func test(){
print("TEST \(someText)")
}
}
let a = Test(something: "Me")
a.test()
Output:
TEST Optional("Me")
You just need to define a init with the parameters you want.
Now to properly instantiate a singleton (basically it just the class above but single instance). There are a lot of ways, the old Objective C approach is still valid.
But for swift this is the most common pattern. You need to define a Static Property.
Example:
import Foundation
class Test {
static let shared = Test(something: "REAL SINGLETON")
let someText : String!
init(something:String){
someText = something
}
func test(){
print("TEST \(someText)")
}
}
Test.shared.test()
Output:
TEST Optional("REAL SINGLETON")
Now reread the definition of a singleton:
a singleton class is a class that can have only one object (an
instance of the class) at a time
For other patterns in declaring a singleton:
https://cocoacasts.com/what-is-a-singleton-and-how-to-create-one-in-swift
Now, you might wonder: When does this singleton instance instantiated?
Answer: It is when it is first used/called.
Hi I would like to ask if it is any way to get an error on xCode at compiling, when you are using a class method that needs to call first to another method?
I explain:
class MyClass {
func initializeClass(){
}
func loadConfig() {
}
}
var myClass = MyClass()
myClass.loadConfig() --> Throw Error while coding, the same as you get when you don't implement a required protocol function
Correct way :
myClass.initializeClass().loadConfig()
One way to approach this situation is by using the Proxy Design Pattern. Rather than adding both methods to MyClass, make loadConfig() an instance method of MyClassInitProxy:
public class MyClass {
public class MyClassInitProxy {
let owner:MyClass
public func loadConfig() {
// Do the config work using owner to access MyClass
}
private init(owner:MyClass) {
self.owner = owner
}
}
public func initializeClass() -> MyClassInitProxy {
// Do preparation, then
return MyClassInitProxy(owner:self)
}
}
Now the only way one could call loadConfig is by obtaining MyClassInitProxy through initializeClass() call:
var myClass = MyClass()
myClass.initializeClass().loadConfig()
The short answer is - No, you can't have a compile-time error using this approach.
However if you want to make it impossible for anyone to instantiate your class without having configuration prepared, then just require the configuration as an argument in the initializer. E.g.
class MyClass {
init(config: YourConfigType) {
// do something with the config parameter
}
}
... read config from somewhere and create config variable ...
let x = MyClass(config: config)
And then you have a "compile time error" whenever someone wants to use your class without having config setup initially.