We have 2 JAVA classes related to a project, call them AGraph and CallGraph. We also have an interface named Graphism which is implemented by AGraph. There's one abstract class we have, named GraphSnippet, which basically creates a visualization of a ZEST graph.
Now, we want CallGraph to extend AGraph. My silly doubt here is, does CallGraph need to implement the interface Graphism as well?
Next, instead of making GraphSnippet an instance of the Graph class (Graph is a pre-defined class in the ZEST package), we want it to be an instance of CallGraph so that the functionalities of CallGraph and AGraph become a part of the implementation. And because we'll need the class AGraph during the later stages, we can't really knock this class out and get all its methods implemented in CallGraph.
Could someone help us with how to start with it? It's difficult for us, novice JAVA programmers, to figure out a way?
PS: We're working on Eclipse-JUNO.
Now, we want CallGraph to extend AGraph. My silly doubt here is, does
CallGraph need to implement the interface Graphism as well?
Yes, but you won't have to do anything. Because it extends from AGraph, it will already implement Graphism. You won't have to mark this anywhere in your code.
Related
I am currently working on a videogame (assignment), and the problem I have is the following:
The player can move vertically and horizontally, but some other objects can only move vertically OR horizontally. I would love to have an abstract class "HorizontalMovingObject" and "VerticalMovingObject", and have an abstract class "MovingObject" which extends both these classes. I was wondering if there happens to be a workaround for this?
I currently have these abstract classes, but find myself constantly copying code from the unidimensional moving classes to the regular moving class. I have tried a couple of things, but all felt wrong somehow. I worked through interfaces for the unidimensional moving parts, but there is a default underlying behavior that should extend to all objects moving in that direction, and thus it feels wrong to write these over and over again. I tried the reverse and have for example the horizontal class extend the MovingObject class, but with all its vertical components set to 0, which somehow felt even worse.
I know this might not seem like a very important detail, but it has been driving me crazy for some reason. Mostly because I come from C++.
Any help is appreciated!
I would love to have an abstract class "HorizontalMovingObject" and
"VerticalMovingObject", and have an abstract class "MovingObject"
which extends both these classes.
The workaround for that is interface.
MovingObject should implement both HorizontalMovingObject and VerticalMovingObject
I currently have these abstract classes, but find myself constantly
copying code from the unidimensional moving classes to the regular
moving class. I have tried a couple of things, but all felt wrong
somehow.
Java 8 introduces default methods that allow to define default implementations for interfaces.
Note that if a class implements both HorizontalMovingObject and VerticalMovingObject , which both have a same default method, you should override it to make the class compile : default interfaces allow to mix inherited behaviors from distinct interfaces while no ambiguity is present about which method is inherited. When it is not the case, a compilation error occurs.
An alternative to Java 8 interfaces default method to achieve this requirement is using the decorator pattern : define each part of behavior that you want to reuse in a specific decorator class, chain the decorators designed to work together and and add these to the decorated class that need these specific behavior.
This approach favors composition over inheritance and requires more boiler plate code but is more flexible.
One workaround that can be done for multiple inheritance is using default methods of interfaces.
I personally don't think it's a good idea, this is not what default methods are there for, but technically it's a loop-hole you can expliot
A better solution for me can be to have some MovingObjectAbs class that will hold the shared direction-agnostic logic that both horizontal and vertical classes will extend, or to have some utility classes that will have shared logic.
I am using a 3rd party API in few Java applications. They have updated few things in the latest version. We will have to update to the latest version and it needs corresponding changes from our code.
The changes are,
1) The interface and the abstract class name which we used to implement/extend has been changed. Also, the method names has been changed.
These are all just the name changes.
2) Need to annotate the class which implements these interfaces with #Service
3) Then need to add some new Java file and a property file.
4) We also have the abstract class which implements the 3rd part abstract class and then there are many concrete classes. So, few methods from the 3rd party abstract class is been overridden in our base abstract class which extends the base abstract class and few methods are there in the concrete abstract class.
I can do the refactoring through Eclipse IDE, but we dont prefer this.
I like this to be completely automated like running a script.
I tried with Java reflection to find all the concrete class of an Abstract class and rename the methods. Still, it looks risky.
Is there any other better approach?
It depends how much code you need to change, how long it takes to do each step and how many times you repeat the same refactoring.
If it is only a few hundred classes and/or simpler refactorings like rename class/interface can do most of the work, then do it by hand.
Otherwise if you really want to, you can try to write rules in a tool like AutoRefactor: https://github.com/JnRouvignac/AutoRefactor
Disclaimer: I am the author of AutoRefactor.
I remember reading somewhere that a programmer is someone who would rather spend 12 hours writing a script to automate a manual task than to spend 20 minutes actually doing that task.
I understand why you want to automate this - the API you're using is making life hard for its clients by renaming things. It's unusual for APIs to break compatibility with naming only - are you sure it's as simple as that?
My strong recommendation is to just bite the bullet and manually refactor. It will almost certainly take less time than automating the process, you'll identify further opportunities to improve your own application's design, and it's unlikely you will ever need to use the refactoring script again.
Unfortunately, I do not now the exact details of you situation. I can point some principles which can simplify life in future according to my experience.
Shortly, if you are using any 3rd party API, try to minimize it's propagation into your code. Hide the 3rd party code behind your own abstractions (interfaces) using patterns like Adapter, Facade etc.
So, in case the 3rd party code changes, you will make changes only in one place. This approach gives you extra freedom: if you'll decide to use another 3rd party API, it will be simple, because the major peace of your code will not touched. Also it is useful while testing: you can mock actual 3rd party functionality.
For example, suppose your project need to have persisting storage. So you can start from declaring interface like this:
interface IStorage {
void save(Model m);
Model load(int id);
}
This will allow you:
Make decision about storage provider (may be it will be MySQL or
MongoDB or simply just XML file on disk) more later.
Easily substitute one 3rd party API by another (for example change from file storage to DB).
Test you business logic easily by mocking this interface instead of use real storage.
Speed up development in case some modules (which another developers have to do) require working storage (they will just use
IStorage interface as if it is already implemented).
Under Android environment, I need to list all subclasses of one of my classes.
I saw that there is samples with reading the directories.... But I would like to find them by asking to the Thread or application level or another running object.
Under iOS I use objc_getClassList and then I select the ones that I am interested in.
Dose someone know if there is a way to find a clean solution like objc_getClassList on generic java or specific android libraries?
Thanks in advance.
PS: All these classes I want to list are in a certain java package
I am not really sure did I understand your question, but you could make a class called AllClasses or something, and in it put an ArrayList subclasses; and then in every subclass you have do
AllClasses.subclasses.add(this).
Thanks should do it
You will need to use introspection and the class loader to find out the classes and test if they are subtypes of a given super type. Here is an interesting implementation of your problem on J2SE : http://nonstop-rp.blogspot.fr/2010/05/java-reflection-know-subclasses-of.html
I have a parent class in Android that inherits from Activity and all my other activities inherit from that parent class. This parent does some life cycle stuff in onPause and onResume that all my activities need. The problem is I have a Map activity that must inherit from Android's MapActivity yet I still need this activity to have my parent classes life cycle methods. Is there a way to have the MapActivity inherit from two parents? Or maybe a partial class I'm not really sure here. Any Ideas would be great.
Thanks,
Bryan
The short answer is no. You cannot have a class that inherits from two classes in Java. The standard recommendation would be to use an interface, but I don't think that's right for you in this case.
Perhaps that you can achieve the code reuse you are looking for by using composition, for example, instead of inheritance. If you post a code example, I could give you a more specific answer.
Sorry but in Java you can only extend one class. However you can implement multiply interfaces. You could have a BaseMapActivity class extend a MapActivity and then have your MainMapActivity extend that BaseMapActivity. The easiest way would be to copy the code from the already existing base Activity and put it into the MainMapActivity.
In Java you can only extend from a single class, however you are able to implement multiple classes from a single class. Another thing to consider is chaining extended subclasses together (this simulates multiple inheritance).
A better description can be found here: http://www.javaworld.com/javaworld/jw-10-2005/jw-1024-multiple.html
It’s funny, I had exactly the same problem earlier this day (but with a PreferenceActivity).
Unfortunately, I don’t think it’s possible, I ended up making a copy of my parent class and changing the name and the extends Activity into extends PreferenceActivity.
I have the following problem:
I have an abstract Activity class, lets call it MyAbstractActivity, that contains some code I'd like to reuse (for example: a standard service binder, common menu items, common initialization code, etc. etc.). Normally I would just use it to subclass my concrete activities and be done with it.
However, I occasionally need to use another supertype, such as a ListActivity or a MapActivity.
So the question is: how do I avoid duplicating that support code within an Activity, if I have to use another base class?
I have thought up of a solution based on the decorator pattern, like this one:
.
However, I see a problem with this approach:
What to do with protected methods (like onCreate())? Should I introduce an additional "bridge" class that makes them public for the purpose of the decorator, similarly to the way presented below (starting to look a bit byzantine...)?
Any other way?
I hope I made myself relatively clear. Thanks in advance for any feedback!
PS. Using static utility classes is not a good solution in my opinion, since it introduces a possibility of hard-to-identify programming bugs.
If I understand correctly, neither Fragments nor the Decorator Pattern are clean or appropriate solutions for what you want to accomplish. They were designed to solve other problems.
I find myself moving "support" code, or "framework" code, or "all that verbose, repetitive, boilerplate crap" to static utility methods. This isn't necessarily the approach I'd take on a non-Android project, but in my Android projects, it works pretty darn well.
Also, know that you don't need to subclass ListActivity to have a ListView.