I also want to share iOS interview questions and answers, stay tuned for more.
🔥5
#QA
Does a protocol can be inherit from other protocol?
- Yes!, Protocol types can inherit from other protocols, but not from other named types.
named types: (Class, Struct, Enum, Protocol)
@software_efficiency
Does a protocol can be inherit from other protocol?
- Yes!, Protocol types can inherit from other protocols, but not from other named types.
named types: (Class, Struct, Enum, Protocol)
@software_efficiency
#QA
Does swift support multiple class inheritance?
- No. Class types can inherit from a single superclass and conform to any number of protocols.
@software_efficiency
Does swift support multiple class inheritance?
- No. Class types can inherit from a single superclass and conform to any number of protocols.
@software_efficiency
#QA
What’s a Design Pattern?
- Design patterns are typical solutions to commonly occurring problems in software design. They are like pre-made blueprints that you can customize to solve a recurring design problem in your code.
You can’t just find a pattern and copy it into your program, the way you can with off-the-shelf functions or libraries. The pattern is not a specific piece of code, but a general concept for solving a particular problem. You can follow the pattern details and implement a solution that suits the realities of your own program.
A pattern is a more high-level denoscription of a solution. The code of the same pattern applied to two different programs may be different.
@software_efficiency
What’s a Design Pattern?
- Design patterns are typical solutions to commonly occurring problems in software design. They are like pre-made blueprints that you can customize to solve a recurring design problem in your code.
You can’t just find a pattern and copy it into your program, the way you can with off-the-shelf functions or libraries. The pattern is not a specific piece of code, but a general concept for solving a particular problem. You can follow the pattern details and implement a solution that suits the realities of your own program.
A pattern is a more high-level denoscription of a solution. The code of the same pattern applied to two different programs may be different.
@software_efficiency
next blog posts will be on design patterns, until then I will try to give a brief intro with such #QAs
add your friends or share the post to your channel, stay tuned for more.
@software_efficiency
add your friends or share the post to your channel, stay tuned for more.
@software_efficiency
🔥3❤1
Program to an Interface, not an Implementation
https://telegra.ph/Program-to-an-Interface-not-an-Implementation-02-08
https://telegra.ph/Program-to-an-Interface-not-an-Implementation-02-08
Telegraph
Program to an Interface, not an Implementation
Program to an interface, not an implementation. Depend on abstractions, not on concrete classes. Let’s look at an example that working with objects through interfaces might be more beneficial than depending on their concrete classes. Imagine that you’re creating…
🔥3
The flexible way to set up collaboration between objects:
1. Determine what exactly one object needs from the other: which methods does it execute?
2. Describe these methods in a new interface or abstract class.
3. Make the class that is a dependency implement this interface.
4. Now make the second class dependent on this interface rather than on the concrete class.
You still can make it work with objects of the original class, but the connection is now much more flexible.
1. Determine what exactly one object needs from the other: which methods does it execute?
2. Describe these methods in a new interface or abstract class.
3. Make the class that is a dependency implement this interface.
4. Now make the second class dependent on this interface rather than on the concrete class.
You still can make it work with objects of the original class, but the connection is now much more flexible.
👍1
Software efficiency pinned «The flexible way to set up collaboration between objects: 1. Determine what exactly one object needs from the other: which methods does it execute? 2. Describe these methods in a new interface or abstract class. 3. Make the class that is a dependency implement…»
#advice
Don't try to remember stuff. Brain is bad at remembering. It's rather good at processing.
Don't try to remember stuff. Brain is bad at remembering. It's rather good at processing.
🔥3
today I'll tell you the truth)
How I make all this content:
1. I learn something small and new
2. I write it down on paper
3. I organize the thought
4. I publish it
5. Repeat
How I make all this content:
1. I learn something small and new
2. I write it down on paper
3. I organize the thought
4. I publish it
5. Repeat
🔥3
Software efficiency
today I'll tell you the truth) How I make all this content: 1. I learn something small and new 2. I write it down on paper 3. I organize the thought 4. I publish it 5. Repeat
Step 1 is huge.
When I'm learning, it's easy to make content, and repeat to myself dive in deeper.
Inputs == Outputs.
When I'm learning, it's easy to make content, and repeat to myself dive in deeper.
Inputs == Outputs.
🔥3
#advice
Comments are an apology, not a requirement. Good code mostly documents itself.
@software_efficiency
Comments are an apology, not a requirement. Good code mostly documents itself.
@software_efficiency
#advice
Functions should only do one thing - this is by far the most important rule in software engineering. When you can isolate a function to just one action, they can be refactored easily and your code will read much cleaner.
@software_efficiency
Functions should only do one thing - this is by far the most important rule in software engineering. When you can isolate a function to just one action, they can be refactored easily and your code will read much cleaner.
@software_efficiency
👍3
Understanding the SOLID Principles: Building Better Software Design
https://telegra.ph/SOLID-Principles-05-17
https://telegra.ph/SOLID-Principles-05-17
Telegraph
SOLID Principles
Understanding the SOLID Principles: Building Better Software Design The SOLID Principles are a set of five object-oriented design principles that can help you write better code. They are: Single Responsibility Principle Open/Closed Principle Liskov Substitution…
🔥3👍1
Software efficiency pinned «Understanding the SOLID Principles: Building Better Software Design https://telegra.ph/SOLID-Principles-05-17»
#QA
What is the difference between a class and an object ?
- A class is a blueprint or template that defines the properties and behaviors of an object. An object, on the other hand, is an instance of a class. You can create multiple objects based on a single class definition.
@software_efficiency
What is the difference between a class and an object ?
- A class is a blueprint or template that defines the properties and behaviors of an object. An object, on the other hand, is an instance of a class. You can create multiple objects based on a single class definition.
@software_efficiency
🔥2
#QA
How does Automatic Reference Counting (ARC) work in iOS?
- ARC keeps track of the number of references pointing to an object. Each time a reference to an object is created, ARC increases the reference count. When a reference is no longer used or goes out of scope, ARC decreases the reference count. When the reference count reaches zero, ARC automatically deallocates the memory occupied by the object.
@software_efficiency
How does Automatic Reference Counting (ARC) work in iOS?
- ARC keeps track of the number of references pointing to an object. Each time a reference to an object is created, ARC increases the reference count. When a reference is no longer used or goes out of scope, ARC decreases the reference count. When the reference count reaches zero, ARC automatically deallocates the memory occupied by the object.
@software_efficiency
🔥2
#QA
When memory leaks may occur in Swift?
1. Strong reference cycles: When two objects hold strong references to each other, neither object can be deallocated because their reference counts never reach zero. This commonly happens when two objects have a property that holds a strong reference to each other.
2. Closures and capture lists: Closures capture and retain references to variables and objects they use within their body. If a closure captures a strong reference to an object that also holds a strong reference to the closure, a retain cycle can occur.
3. Delegate and callback patterns: If an object sets itself as the delegate or provides a callback closure to another object, and that object retains a strong reference back to the delegate or callback closure, a retain cycle can happen.
@software_efficiency
When memory leaks may occur in Swift?
1. Strong reference cycles: When two objects hold strong references to each other, neither object can be deallocated because their reference counts never reach zero. This commonly happens when two objects have a property that holds a strong reference to each other.
2. Closures and capture lists: Closures capture and retain references to variables and objects they use within their body. If a closure captures a strong reference to an object that also holds a strong reference to the closure, a retain cycle can occur.
3. Delegate and callback patterns: If an object sets itself as the delegate or provides a callback closure to another object, and that object retains a strong reference back to the delegate or callback closure, a retain cycle can happen.
@software_efficiency
🔥2
#QA
To prevent memory leaks in Swift, you can use the following approaches:
1. Weak and unowned references: Use weak or unowned references instead of strong references when there is a possibility of a retain cycle. Weak references allow the object to be deallocated, while unowned references assume that the object will always exist.
2. Capture lists: Use capture lists in closures to specify the relationship between the closure and the captured values. By using
3. Weak delegates: Declare delegate properties as weak to avoid strong reference cycles between objects.
@software_efficiency
To prevent memory leaks in Swift, you can use the following approaches:
1. Weak and unowned references: Use weak or unowned references instead of strong references when there is a possibility of a retain cycle. Weak references allow the object to be deallocated, while unowned references assume that the object will always exist.
2. Capture lists: Use capture lists in closures to specify the relationship between the closure and the captured values. By using
[weak self] or [unowned self] in the capture list, you can break retain cycles in closures.3. Weak delegates: Declare delegate properties as weak to avoid strong reference cycles between objects.
@software_efficiency
🔥2