Daniel Larsson

Greenhorn
+ Follow
since Nov 12, 2012
Daniel likes ...
Eclipse IDE Windows XP Java
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
4
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Daniel Larsson

I solved it by using the path to the package, iterating trough the classes and by reflection, invoking a no args method called initialize. This method creates an instance and adds it to the list.
11 years ago
For anyone with the same issue: I used multiple interfaces that were seperate. The main interface "Item" has methods to return the instance as the other applicable interfaces, such as "Inventory". As the method is written in the scope of the interface implementing class its a simple upcast and typesafe.
11 years ago
Thank you. URI decoded the string correctly and now it works.
11 years ago
I'm using the class.getResource(filename), where filename is the absolute path to a package.

It responds and gives me an url that is not null, but spaces and nonenglish symbols are replaced with lots of strange symbols when I print it out to System.out.println()
When I make a file with that url and check file.exists() it says false.

The path looks correct if I disregard the strange symbols.

Is there some way of doing this that is portable and ensures that I can retrieve a path that works, regardless of symbols on the path, and regardless if its in a jar or not? I never managed to get it working properly.

Or maybe the strange symbols aren't the problem, but what could it be then?

I'm running windows xp and using pathnames with nonenglish symbols in them.

please help.
11 years ago

Winston Gutkowski wrote:

Daniel Larsson wrote:EDIT: I just realised I never actually said I wanted the classes to initialise them selves. ...


Hunh? This seems to be getting more and more bizarre.

Quite apart from wondering why you would want to do this, or even the wisdom of having singletons to start with, I agree with Manuel:
back up and explain to us what you're trying to do, not how you want to do it.

Winston



Well I can't blame you, I'm not sure it follow any standard patterns but I find it fitting so far to my purpose and logic, I'm self taught so some eccentricities are to be expected I suppose ;). So why singletons? Because I need the reference to the class, as it will be used in lists. The singletons are stateless actually, they implement an interface and that's it, no real reason to keep them bound to a single instance, but no reason not to either. The reason I want them in a list is that the application will ask another class that manages these classes and produces lists of them(This might be what is called factory methods?). The parameters for retrieving a list of these classes is a list of properties, and the properties of each implementation is retrieved in a method in each implementing class. Thus I want a kind of masterlist of every applicable instance so I can loop through it and select the implementations that have the correct configuration of properties.

I plan to let the application use this list to produce a new list for every possible configuration and be able to retrieve them without creating new lists. There aren't THAT many configurations that will happen so its a marginal expense to have them all in memory instead of making new ones quite often and inducing unnecessary GC(its a lag sensitive application), and also hopefully speeding up the retrieval.

All of this nonsense is because I want to have all the code when implementing new classes for the interface inside the one file, making it easier to plugin new ones and remove old ones without having to remember to clear a manual list somewhere. Over the top? Perhaps. But its a good learning experience! =)

I think I have found a solution, using the classpath I can list all the classfiles in the package that contain these implementations, and thus create instances trough reflection by using the string. This makes me wonder though, what happens with portability of my app when I use that kind of reflection? Anything I should be mindful of? Also can I compile new classes by themselves and just put them in the correct package folder and expect them to be used appropriately?
11 years ago

Pat Farrell wrote:I'm not sure that what you say you want to do is really a good idea. But ignoring that, this is what I'd do.

I'd define the interface Foo and an AbstractFoo class that has a constructor that adds "this" to the list.
Each class that implements the Foo interface then just has to subclass from AbstractFoo and call the constructor.
The compiler will do the right thing, as long as the developer doesn't deliberately screw things up.

But I still think this is probably a really bad idea.



I'm not certain its a good idea either, but I think it will work.

Anyway this is a good idea, but I have already thought about it. The issue with this solution is: when and where does the class get instantiated? It has to be called from the outside which sort of means there has to be an argument excecuted outside of the subclass. Which essentially means there already exists a handmade list, and I want it automated. I read up on javas static initialisation orders and my anticipation is correct, if I use static initialisation only the classes that has been accessed will be initialised, so whatever happens I see no solution except accessing the classes from outside the class definition.

EDIT: I just realised I never actually said I wanted the classes to initialise them selves. I'm sorry for being unclear. The more I think about this the less I think it will be possible to do. My motive for this, is that the future implementer of the interface in question should not have to go in and manually add the new class to a list, but only need to write the class, compile it, and put it in the same folder as the others and it would be included. Or if that doesn't work, supply me with the file and I'll do it when recompiling the entire application.
11 years ago
I did a quick search and found no other queries about this, might be because I don't really know what keywords would be applicable than the ones I use here.

Scenario: I want to have a list that includes every instance ever made of a certain interface.

All implementers of this interface will be singletons, they will be static and immutable and the instance is only used for reference.

I want to avoid having to manually add each instance to the list to keep track of all these singletons, I want the mere act of writing another implementing singleton class to make it written in the list.

A method to get all instances and put them in a list is ok too, the issue is that I want to be able to implement the interface without having to write it into the list manually somewhere outside the class to ensure its in the list.

The problem is that its a catch 22 for me, to make sure that these classes have written themselves into the list I have to make sure they are loaded, and I got the impression that classes statical initialisers are loaded when the class is demanded the first time?

Performance is not an issue, it will only happen at the startup of the application and this master list is used to sort the instances into other lists depending on their properties.

Thanks in advance.
11 years ago
Thank you for trying to help me, I apreciate it. =) And thanks for the welcome.

I'm aware my describing turned out abstract and convoluted. You are right that the problems pertain to memory and wanting a small and clean interface. And memory is more important in this specific case. My solution on the memoryproblem is not wanting to instantiate any more objects to solve the problem. Thus I have only the original item instance to store the variables necessary for the Inventory management.

The solution of having several interfaces might be better, but that would mean I would have to cast the Item object to an inventory object, to access the inventory methods? This is probably not much different from my solution with the static helper/utility class, except for the casting performance overhead. I think I won't be needing an inventory interface because it currently looks like I only need one implementation of the inventory methods.

I have been avoiding this kind of casting based solutions in my code since I see a lot of warnings and flak responses to such solutions in assorted forums. Perhaps I'm being overly cautious because I don't understand the real risks behind it and just avoid it because of general warnings?

What should I watch out for, and be mindful of when casting like this? In the bigger picture, and in good practise terms? Thanks in advance. =)
11 years ago
Hi! I'm new to this forum, I hope my stay will be pleasant for everyone involved. =) I place my question here since it's more a question on how to design an interface in a "good practice" way, than solving a game making problem.

To clearify: the Item class is an inanimate thing that can exist in the world and in an inventory of any kind. The Action class is a class that uses the methods of the Item class and references to other objects like the position in the world, the player, the target, etc, to produce effects and actions. The seperation is motivated by me wanting to reuse code for actions that happen across a wide range of objects, and also keep the effects modular.

I am designing an Item interface in a game I'm making. My main issue is that I have tried to make the interface clean with only a few methods because I want it to be easy for the person implementing subclasses of the Action class, as it will need to contain implementations that use this interface. I have seen other games having massive item/object interfaces with lots of isX() methods and methods that doesn't really apply to the object behind it all. I find such solutions marginally better than instanceof and casting, since they both use if clauses to a large extent.

But I am stumped with the question on how to solve Item "inventory". Memory overhead is a real issue since these items will number in millions, and even if many will just be references to static Items, inventory Items will need to have a list/array of some kind that must be in an specific instance. So I want to avoid having an object handle these inventory methods because it carries additional memory overhead beyond the actual array or list. This List/Array will contain Items, but not all items will have such inventories. Therefore I find it ugly to have about 5 methods about just how to manipulate this list/array in the actual Item interface, as only a few will use it. Even if the potential to cause bugs on the action implementing side is not that big, it's still ugly and I feel an Item should be more abstract than this. I could have just made an abstract Inventory class and have some Items extend this, as the inventory related methods would mostly use the same implementation, and then connect to the subclasses by overridding a method so the actual variables for inventory size and such would be reachable by this superclass, but this would only make implementation of inventory Items easier, it will still leave a bloated and messy interface, and I anticipate more methods for other different aspects could also start appearing if I don't restrict this watering down of the abstraction and it could turn out a mashup of different possible subclasses! I think any class should avoid having methods that is not relevant for the contained object.

My Proposed solution is just having a way to check if the item has an inventory, and then if it has it then the implementer in a action class either checks if it is an inventory, or knows this because of testing earlier than the scope of this Action. Then the implementer would feed the Item in question to the desired methods that would now instead reside in an abstract helper class that now gets the list and important variables from the Item. The solution makes the list public and I don't really like that in a way, but now all methods in Item have a purpose and the number of methods has decreased.

Is there another way of doing this or is there some flaw in my reasoning that any of you experienced programmers notice? I'm selflearned and have no idea of what is the best practise but I know I prefer interfaces to not contain hundreds of methods. =) Are classes like my outlined helperclass to be avoided? I feel there is something fishy about spreading out the implementation of the Item behaviour outside the class scope... Perhaps making it an internal class or being careful in designing the package so this behaviour is emphasised?
Any ideas, tips that come to mind?
11 years ago