Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Personally I prefer callback over delegate in Swift for simple logical correlations, because it's pretty straight-forward and easy to understand. At the same time, some prefers delegate, since delegation is a popular pattern in other languages, such as C#.
There are some discussions I found online:
1. "Why you shouldn't use delegates in Swift?"
https://medium.cobeisfresh.com/why-you-shouldn-t-use-delegates-in-swift-7ef808a7f16b#.hqb7zrc1v
2. Apple is shifting its focus more on the callback pattern
https://www.reddit.com/r/swift/comments/2ces1q/closures_vs_delegates/
3. blocks or delegates?
http://blog.stablekernel.com/blocks-or-delegates/
After reading these discussions, I am still undecided on the preference.
I would like to know when is better to use closures and when is better to use delegates? and reasons?
Thanks!
(Opinion based answer for an opinion based question)
The questions shouldn't be which is better, it should be what's the best solution for the problem I'm trying to solve.
My simple rule: if something requires one function as it's interface, a callback is usually a good solution. If more than one function is required, especially when they're required for the basic function of an object, a Delegate is probably a better solution.
As always it depends on the specific situation, but absolute statements rarely work out in real-world usage.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Personally I prefer callback over delegate in Swift for simple logical correlations, because it's pretty straight-forward and easy to understand. At the same time, some prefers delegate, since delegation is a popular pattern in other languages, such as C#.
There are some discussions I found online:
1. "Why you shouldn't use delegates in Swift?"
https://medium.cobeisfresh.com/why-you-shouldn-t-use-delegates-in-swift-7ef808a7f16b#.hqb7zrc1v
2. Apple is shifting its focus more on the callback pattern
https://www.reddit.com/r/swift/comments/2ces1q/closures_vs_delegates/
3. blocks or delegates?
http://blog.stablekernel.com/blocks-or-delegates/
After reading these discussions, I am still undecided on the preference.
I would like to know when is better to use closures and when is better to use delegates? and reasons?
Thanks!
(Opinion based answer for an opinion based question)
The questions shouldn't be which is better, it should be what's the best solution for the problem I'm trying to solve.
My simple rule: if something requires one function as it's interface, a callback is usually a good solution. If more than one function is required, especially when they're required for the basic function of an object, a Delegate is probably a better solution.
As always it depends on the specific situation, but absolute statements rarely work out in real-world usage.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So I've been wondering myself if it's better to use Recursion in Swift or the regular For Loops (iterations in general).
If so in which cases should I choose to use Recursion instead of Iterations.
I know that in some languages one is better/faster than the other, but I'm in doubt about Swift (maybe the same opinion as Objective-C).
If you can give me a solid, or close to, answer I'll be even more thankful.
Thanks in advance, and stay strong in code :)
Cheers.
- IC
This question is a bit general and has many answers already. Regardless, I would always stick with iteration when possible for readability's sake and the fact that it's more efficient than recursion. This is because we often end up solving the same math more than once in recursion. I've also worked with people who discourage the use of recursion in favor of iteration.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have been hearing that the controller should be as concise as possible. So, I try to keep most of the processing work in the helper for the corresponding controller. But, I am little confused regarding whether I should instead use private controller methods or helper methods.
I am using helper methods only for processing and returning values. They have no other usage for now. They are not called from views.
That's a bad idea in general. Helper methods shouldn't be used except for specific convert-something-into-string stuff (basically, should be used only in views).
For anything else, you should use service objects or something similar, basically, PORO (plain old ruby objects)
In controllers you want to handle authentication and render the right thing, you don't want to deal with anything else otherwise they become too complex.
You might want to check these books to improve knowledge about this topic:
Growing Rails applications which is a really good book on how to avoid putting code in wrong places and how to keep codebase maintenable on the long term
POODR which is a Ruby guide on how to write good Object-Oriented code, it's a must for any developer and will help you understand why using an helper it's a bad idea
Usually, a Helper is called in a template or a view.
If you want to keep your controller DRY, use functions in your models or in services (read this good article about services by Ben Lewis)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm just wondering, I'm new to this pattern subject, I started like couple of weeks ago but my main problem is, when I start writing small applications (for self purposes) I can't think where to put any pattern to use, maybe it's my thinking structure that needs to be tweaked ?
If I start a new project, how would I know if I need to use a pattern ? what questions do I ask myself ? what steps do I take before writing the actual code ?
Look at the Delphi VCL...it's basically took the Design Patterns and ran with them...
Forms are Composite Patterns.
Datasets use the Iterator Pattern.
Screen and Application are Singleton Patterns.
Components use lots of
different Patterns, the Chain of Responsibility, Decorator, Facade
to name a few...
Patterns are ways to organize your program and objects in lightly coupled objects that have jobs that you do over and over again...
Design patterns are just ways to approach solutions to common problems. As you internalize the patterns and as you understand the problem better you will sometimes see that the problem (or part of the problem) you are solving is addressed by a particular pattern.
That's when you use it. When you see it solving your problem.
Design patterns are reusable solutions for common problems.
The principles of Software Engineering cites the reusability of codes, when you use a design pattern you are using a concept previously tested that went trough several validations and is less prone to an design error than if you design your own model.
So first, you have to know the existing design patterns and what they're intended to solution. When you face a common problem you may remember the design patterns you previously studied and use them to solve the situation you're facing at the moment.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
In my application, I want to have a "brain" that keeps track of what's going on. That is - multiple view controllers need to be able to set values in this brain and get at its data too.
How would I go about implementing this? From what I can tell, making my brain a singleton class is an option, otherwise I'd have to declare the brain as a delegate in every view controller and assign the brain to it every time it's created, which seems quite messy.
Your answer is in your question as you said. Use Singleton pattern if you want to access an object from multiple objects and there is no need for more than one copy.
Bear in mind that you must keep your data thread-safe if you will have two or more objects in your code that will try to manipulate the "brain" at the same time.
As for the Singleton pattern, you might like to read this What is so bad about singletons?
Make sure you design your app using the MVC pattern and you should be good. The "brain" is the model.
How your "model" behaves depends on your application.
Singleton pattern is an option. Another option is NSUserDefault.
Yes you are right Singleton is a good option.
As i think you are dealing with low amount of data so singleton will be good and easy otherwise go for saving data in a database or NSuserDefaults.