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
What is exactly inheritance, polymorphism and encapsulation in iOS with example? Do iOS uses all this features? And how?
The concept of inheritance brings something of a real-world view to programming. It allows a class to be defined that has a certain set of characteristics (such as methods and instance variables) and then other classes to be created which are derived from that class. The derived class inherits all of the features of the parent class and typically then adds some features of its own.
Please check This link: An Objective-C Inheritance Example
The word polymorphism means having many forms. Typically, polymorphism occurs when there is a hierarchy of classes and they are related by inheritance.
Objective-C polymorphism means that a call to a member function will cause a different function to be executed depending on the type of object that invokes the function.
Consider the example, we have a class Shape that provides the basic interface for all the shapes. Square and Rectangle are derived from the base class Shape.
Please check This link: An Objective-C Polymorphism Example
Encapsulation is an Object-Oriented Programming concept that binds together the data and functions that manipulate the data and that keeps both safe from outside interference and misuse. Data encapsulation led to the important OOP concept of data hiding.
Data encapsulation is a mechanism of bundling the data and the functions that use them, and data abstraction is a mechanism of exposing only the interfaces and hiding the implementation details from the user.
Please check This link: An Objective-C Data Encapsulation
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 5 years ago.
Improve this question
I'm already using Dagger2 and everything is working but I have a doubt about the proper way to integrate it into the business logic.
What Robert Martin says in "Clean Architecture" is that the DI frameworks, since they are frameworks, are details that should be kept away from the Entity and Use cases and more in general from all the classes that are at a higher level than the frameworks.
What R.M. suggests is to allow only the Main-module to know the DI framework used and to inject the other classes by yourself in such a way that you can replace one DI framework with another one without having to change the BL.
Is there a way to isolate Dagger in such a way that the business logic does not see it?
Strictly speaking, yes: DI frameworks should also not be used in use case or entities circle. (That includes attributes and annotations)
The question would be how strict u want to handle this rule in ur project. Every rule and decision has pros and cons. As u said the pro of keeping DI out of the inner circles would be that u could easily replace it later. U would have to decide how big the benefit is compared to the cons, e.g.: having to pass dependencies to use cases manually.
Personally I currently try to handle it very strict in my projects. But my usecases tend to have only few dependencies ...
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
Is it better to declare an ivar in a class extension?
Or is it only a developer preference?
As the name suggest it is an extension to the functionality of class. You may add extra behavior to the class using extension. Adding member variables or stored properties have quite a bit problems viz:
When it is possible to add data member in extension the original class is not aware of the added data member. This leads to problem of allocation for such members while creating object for such classes.
It could also create problem with initialization and de-initialization of data members as these are not known to original init() or deinit() methods.
Adding data member may alter the very nature of class in terms of its behavior.
Currently you are unable to add instance variables to class extensions. This is true for both swift and Obj-C. See this question: Defining a property in iOS class extension.
If you mean, by adding a iVar to the interface extension:
#interface MyClass(){
MyIvar *ivar
}
well, thats a bit of a matter of choice and convenience. In general you should limit your public interface to a minimal set of properties/methods that allow the user to interact with the class in the way you design/expect. While your code will work fine using either method, exposing more properties/functions can result in more problems as consuming classes may uses properties/functions in ways unplanned for or unexpected.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
HAs anyone implemented MVVM pattern in your iOS app without using ReactiveCocoa?
Found lots of examples here, but all of them use Reactive Cocoa. I wanted a simple example of MVVM implementation.
Reactive Cocoa is definitely not required for MVVM. I have built a very successful MVVM framework w/o any bindings at all. Bindings are not a requirement for MVVM.
Specifically, the linkage between the View Model and the View does require the View Model to signal to the View that it needs to update its data. This can be achieved using Reactive Cocoa, KVO (I really like Facebook's KVOController), or even using a simple delegate pattern.
The View Model knows when the View needs to update - either data has changed, or you're making an async data request via the Model and the Model has been loaded into the View Model.
When you set up your View, you could bind each control to the corresponding value on the View Model. I have found that when I need to churn out screens, this can get very tedious. Instead, I'd rather have a single method that is called when the View Model signals that the View should update itself. Within that method, I'm simply going to set all of my control properties.
Now, you only need to concern yourself with how that method is triggered. In my personal framework, I leverage KVO and my ViewControllers monitor a timestamp property on my ViewModel baseclass. Any time my view models update their underlying data, its timestamp is updated which triggers the update. You could just as easily have the View Controller register itself as the ViewModel's update delegate and use a standard delegate pattern.
Again, MVVM is not about specific implementation requirements, and more about a higher level concept of separation of concerns, dependency decoupling, and encapsulation.
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 8 years ago.
Improve this question
As Craig revealed within the announcement of Swift, it is said to be faster than Objective-C by far.
But i'm not that convinced by that comparison because a properly implemented algorithm should be fastest in C, because it can be highly optimized by the compiler and is hardware-friendly by nature.
So I would guess the best performance Swift could get, would be the performance of the same algorithm in C.
And as C is part of Objective-C, why is there a that big gap between Objective-C and Swift performance?
The only reason I could imagine is Apple using NSNumbers and such instead of C types, but should not be the base for a Obj-C - Swift comparison, right?
This is largely speculation (although informed speculation) but my two big theories are:
1) No Reduced dynamic method dispatch. Every method call in Objective-C goes through objc_msgSend. In the fastest case, this can be as quick as 16 instructions, but it can also be a lot slower. Swift will incur this penalty in fewer situations than Objective-C will, for instance: method calls to swift-only protocol methods do not hit objc_msgSend, but if the protocol is declared in Obj-C, or if the swift protocol is decorated with #objc (such that it can be adopted by Objective-C objects as well), then method calls to methods in that protocol adopted by swift objects appear to be dispatched via objc_msgSend.
2) Avoiding heap allocations. In Objective-C, (effectively) every object is heap allocated. With a static type system, the compiler can infer more about the lifecycle of an object and allocate it on the stack unless it has to cross the Objective-C boundary (or is too big to be allocated on the stack).
I suspect that #2 is the much bigger of these two, but both are likely significant contributors. I'm sure there's more to it than just this, but these are two very likely contributors.
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 9 years ago.
Improve this question
I have read several articles discussing pros an cons about singleton patterns. But I would like to know:
Is it advisable to have multiple singletons in an iOS App?
what are the pros and cons...?
Currently I am having only one singleton globally and holding strong references of other necessary properties including custom composite classes. But the idea sounds something strange for me for an example, accidentally I can create several instance of a custom composite class which I don't want.
You should have as many singletons as you need. Take a look at Cocos2d - it contains a fair amount of them: CCDirector, CCTextureCache, CCSpriteFrameCache and so on. There's no limit on singletons, say 5. If it's convenient for you to have one single center class for a certain kind of operations (like accessing network or a database or whatever) and you never need a second instance of this class then feel free to make it a singleton.
It depends on your requirement.
You can have multiple singleton classes or objects.
The singleton object will be alive till your application quits.
For memory managing concern, it'll be very difficult if you have multiple singleton objects(You can't release these singleton objects, when a memory warning raises).