I have a tricky question on interface. Please try to give me a solution for it.
Scenario:
I have written an interface with five methods. Also I have implemented more than 100 classes using this interface. Now, I need to add one more method to the interface. Consequently, I will need to define the same method in all classes. How can I avoid this???
Please reply...
Thanks,
Akif
Could you avoid adding a method to the interface by instead creating a new interface which inherits from that first interface and then only changing the classes you need that new method on? Hence, if foo didn't need the new method, leave it alone but if bar did, change it to the new interface.
Java 8 has default method which you could add to an interface
https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
All the subclasses which do not override this method will resort to the default implementation in the interface
Related
I was going through this since some of my UVC use this methodology:
https://www.doulos.com/knowhow/sysverilog/uvm/easier_uvm_guidelines/parameterized_interface/
But i want to extend the class in the interface and add/override some more functionality.
But when i tried to override the class, the compiler could not find the class, since it is scoped in the interface.
Any suggestions as to how I can override the class instead of re-implementing all the functions?
Thanks in advance.
That is one problem with using this methodology - you can only extend the class from within the interface. But that is no different from using a virtual interface — you cannot extend the interface.
The best thing you could do in put the extended class inside the interface. Use the factory to override the construction of the class.
I tried to create a properties view for a graph model in an Eclipse RCP Application. The graph elements are from a non-eclipse library and so don't implement IAdaptable or even IPropertySource.
The Tabbed Properties View, explained here:
http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html
seems to be a simple possibility - but only for inputs that implement IAdaptable.
I've thought about implementing my own IPropertySheetPage but the only implementations I found are the built-in PropertySheetPage and TabbedPropertySheetPage which are very complex.
Is there another way to create a properties view for input elements that don't implement IAdaptable? Can I use Tabbed Properties View in a way I don't see yet? Are there any other less complex implementations of IPropertySheetPage, I can look at?
Thank you!
Kristina
Actually, you can write an IAdapterFactory for objects which don't implement IAdaptable and register it in plugin.xml or in your plugin activator. See http://www.eclipsezone.com/eclipse/forums/t61666.html.
Are there any other less complex implementations of IPropertySheetPage, I can look at?
Short answer: No.
But why don't you wrap the non-adaptable object into your own object that implements IAdaptable or IPropertySource or whatever, so that the property-page can work with your wrapper which holds the object you want to make editable through the property-page. And instead of providing this "library" object to global adapter-mechanism, create the wrapper, set the object and provide it to your global selection-service or whatever.
I have an iPhone app that uses a Tab Bar Controller with 3 tabs. Each tab is a separate class. There are several methods that are identical in each class. Instead of having three copies of the same method, I'd like to share the method between the classes. However, I have not figured out how to do this.
Thanks.
This is a classical case of inheritance. Create a base class, and put all things that are common across the classes you are trying to build, into it, both functions and data members. Then, derive your three classes for your tabs from this class (inherit from it, or make it the parent class, lots of overlapping terms here that people generally throw around). Make sure your methods in the parent class are NOT defined as private methods. That would make them inaccessible to your child classes. Hope that helps!
Here you can make a new class and define that method inside that class which you want to share between more than one class.
Now whenever you want to access that method, just import the class and you can use the same method in multiple classes.
Let me know if you need more help.
I'm new to Objective-C so I may be doing this completely wrong, and if I am please correct me. I am trying to make a separate class in my iPhone app just for skinning buttons. My hope is that this will allow me to reuse as much code as possible but before I spend too much time on it, I would like to know if its possible/a good idea to send a message to a UI Control from another class, and if i can, how should I do it? right now im trying to pass the sender ID to my SkinTools class and message that but it doesn't look like it will allow me to message the layer object.
So, am I just completely off the wall here, or is this possible?
Consider looking into using the delegate pattern.
One could just use the addTarget:selector: method for this purpose. As target set the class you want to send the message to, as selector the method you want to call on the class.
You could add some iVars to your class, like id buttonTarget and SEL buttonSelector and create an initializer like -initButtonWithTarget:selector: to set these values on initialization.
It turns out categories was the answer I needed, then I can just add a skin method to each control I use. I can even put them all in the same file to make it easy to get to.
I have two classes that are already subclasses of a different parent (due to an external library I cannot change this). However I want to share some common code between them, say for example, code that handles an action after a popup dialog etc. How do I do this?
Refactor the shared code into its own class, and include an instance of that class as a field/property within your other two classes.
You can re-factor the appropriate code into a utilities class, and then have the two classes call it. As for the iPhoneSDK, you can probably have the utility method be the delegate method itself.
You could write a category on a common ancestor class. Then both classes could import that Category and call the common code.