I'm currently trying to implement VIPER-architecture in my project, and there is some questions I encountered with.
I have two modules in my app, that have some similar functionality (they both have imagePicker and ability to upload media to server, that implemented absolutely the same for both screens).
My question is how could I reuse this similar functionality in both modules? Trouble is that my imagePicker has many methods declared in Interactor that handle different events while selecting and uploading image (such as didUploadMediaFile(), didFailToUploadMediaFile(), uploadMediaFile() and so on).
Should I create third module with this functionality and then somehow subclass my other modules from it? Or maybe there is a better way of doing it?
The only similar components/methods I'd use are Data Managers, which can be shared between as many Interactors are you want, and yet being 100% compliant with VIPER architecture.
So, a DataManager called, for example, MediaApiDataManager() would be responsible for the implementation of the core code to UploadMediaFile() etc
I suggest you read this post for more great tips on VIPER: https://www.ckl.io/blog/best-practices-viper-architecture/
I think you need create abstract class and implement inside imagePicker logic. Declare interface (protocol) for it class with didUploadMediaFile(), didFailToUploadMediaFile(), uploadMediaFile() methods, implement this methods in class and inject to your VIPER modules
For the two modules try to abstract the similarities and try to build a Class of it. If both classes differs on the data type use Generics, also you can use Protocols, so declare the common methods of the two modules in one protocol and implement each one of them as an extension.
Maybe this tutorial helps. https://medium.com/#richiemon/protocol-extension-dispatching-6d5229f1338e
I got a question that i'm trying to figure out.
How can i set 2 different Subclasses in 1 UITextField?
I have installed a library ShowPassword(via cocoapod) and currently i'm using it so users can see the password that they are typing.
But i have also installed another library that makes an awesome UITextField (also via cocoapods)
https://github.com/raulriera/TextFieldEffects
And with this library i can insert Subclass Hoshi for example (which i have done in username text field)
How can i import both of them in password textfield?
You cannot!
What you would need to be able to to is create a new class which inherits from both the TextFieldEffects and the ShowPassword. But Swift (same as Objective-C) does not support multiple inheritance (see this answer).
Your only option is to create a custom subclass from one of the classes and create the effect of the second one on your own in your subclass! Meaning that you have to write code to implement the functionality of one of the two desired effects.
Alternatively you can try to create an extension for one of the two library classes adding the logic from the second one. (basically the same thing)
It is highly unlikely that both subclasses would work together without any problems. As soon as both class override the same methods you are in a trouble since you have to decide which one really overrides it, etc.
If I create a subclass of one of Apple's classes, ie: UIViewController, it comes with some methods already defined in the implementation file, ie: -viewDidLoad.
Is there a way to do this with my own classes?
I have been searching for the answer but haven't come up with anything.
Edit: To clarify my Question
I know how to subclass & use protocols etc.
What I want to do is have important methods that should be overridden by a subclass written into the implementation file automatically.
Better example:
If you subclass UITableViewController you will need to implement
-numberOfSections...
-numberOfRows...
-cellForRowAtIndex...
But you don't have to write them yourself, Apple automatically adds them into the file.
So is there something in obj-c that allows me to do that with my classes or is that something Apple has baked into xcode that can only be done by them?
These are basically boiler plate code which is written when the IDE is being designed itself.
JSF 2.0 comes up with annotation. However in JSF 1.2 we defined attributes in faces-config.xml file.
In JSF 2.0 we have two options, either make use of annotation or use faces-config.xml. What is better approach? Writhing the properties in faces-config.xml is easily manageable, whereas writing annotation in each file is somewhat not easily manageable.
Annotations are generally preferable because they keep information about a class with the code of the class, so you don't have to look in another place to understand it. It also reduces duplication of information because you don't have to write out the class name to specify what class the annotation belongs to.
Then again, for some things it can be valuable to have all information of a certain kind collected in one place (e.g. URL mappings). Fortunately, annotations and XML configuration are compatible, so you can put some things into XML and use annotations for everything else.
Well, this is absolutely depends on you, but annotations are the "modern" way of programming. Code is becoming more readable and maintainable with them. IMHO annotations are less vulnerable to errors because you don't have to maintain a huge file of XML entries, but you have just few lines of annotations per each file(also it's nice when you open a file and immediately see that this class is a managed bean). so code is becoming more self-commenting.
If I were you I would definitely go with annotations, IMHO it's far more easy to manage them.
Delphi 8 introduced Class Helpers for the purposes of mapping the VCL/RTL to the .NET object hierarchy. They allow injecting methods into an existing class without overriding the the class or modifying the original. Later versions of Delphi found class helpers improved and they were ported to Win32.
In the help it says "they should not be viewed as a design tool to be used when developing new code."
Class Helpers violate traditional OOP, but I don't think that makes them a bad thing. Is this warning warranted?
Should class helpers be used when developing new code?
Do you use them when developing new code?
Why or why not?
Per Malcolm's comments: New code means daily application development, where you have some 3rd party libraries, some existing code, and then code you are writing.
Depends what you mean by "new code".
They aren't really relevant for classes you are newly developing, so in that case, no, they probably shouldn't be used.
But even in a brand new project, you may still need to modify an existing class that you can't change in other ways (vcl class, third-party class, etc). In this case, sure, I'd say go ahead.
They're not evil in and of themselves. Like most other things, you just need to understand how they work and use them in an appropriate context.
Before embracing class helpers as a new tool for fancy code, I think you have to understand the limitations is includes. There is only possible to provide one class helper for one class. So what will happen if you provide class helpers for your classes, and your classes derives from a common class that some other have provided a class helper for?
CodeGear introduces class helpers as 'a hack' to prevent breaking things, not as a cool design feature. When you design code, design it without class helpers. I know you can. When dealing with existing code that you can control, use refactoring. When there is no other way, reach for class helpers.
Thats my opinion any way...
Microsoft based LINQ heavily around their Extension Methods. In that light you should use Class Helpers in new code if that improves your code. See What are good uses for class helpers? for some good uses.
I use them a lot. I use Remote Objects and the objects there are created by the RO engine so you cannot add to them without descending from them and then other bits of messing around. Class Helpers mean I can treat them like any other object. and while a class can only have one helper, you can descend helper classes so you get the inherited behaviour.
Sorry, can't help but be Captain Obvious for a moment: If the internal Delphi people themselves state "they should not be viewed as a design tool to be used when developing new code" then by definition they shouldn't be used. They are there for extending the VCL for their own purposes only. Who else is going to give you a better reason than the people that wrote it?
I agree with Vegar in this: class helpers as a emergency tool. When you know they are the only way to get things done in the time provided. Later, if there's time to it, remove them.
I one time forgot a parametrization thing, and if class helpers didn't exist in Delphi 2006 it would cost A ENORMOUS LOT OF TIME..... With class helpers, it took 6 hours to make thigs work right. BUT, it was an emergency situation - class helpers are an obscure language feature and it create difficulties to new developers to follow the flow of the program.
Maybe a good aproach you can use is (as I use it):
Always give preference to inheritance over class helpers, use them only when inheritance is not an option.
Give preference to Class helpers over bare global methods.
If you're going to need the extendend functionality in more than a Unit, try something else (like class wrappers).
.Net Extensions methods are way too similar and where created and supported for the exactly same reason: Make an Extention of the base classes (rather than an upgrade wich in Delphi.Net was not an option in order to try to make Delphi native code kind of "compatible" with .Net code - IMHO this was too ambitious)
Anyway, Delphi Class helpers are still quite a tool in some situations.
These sound like C# extension methods. I would say that while extension methods like these are useful when you don't have the ability to modify a class that you need to extend with functionality, they are a poor way to design your own code. When designing your own code, you'd like all the functionality to be located in the same code file as much as possible rather than spread across different classes. I'd say use them for what they were intended for -- basically as decorators to add new functionality to closed classes -- and don't use them in designing your own code.
I find myself using them more and more as a design construct.
Situations in which I use them :
In a client/server setup, I extend shared base-classes with class helpers to provide server- or client-only functionality.
To complement VCL/RTL classes (and other third party code) with handy tooling functions.
To work around differences when classes don't share the same inheritance tree (using helpers makes it possible to have have generic Count and Items properties, for example).
In fact, I wish Delphi would accept multiple helpers for the same base class - I've even filed a request for this if I'm remembering correctly.
I found this article very interesting. It deals with C++ but the main ideas are language independent. The main gist is that global routines are sometimes preferrable to methods even in an OOP environment. From this view point, there's less need for class helpers.