I wish to create an instance of TreeMap whose keys will be of type String and values of
type ArrayList <String>:
Map<String, List<String>> directory = new TreeMap<String, List<String>>();
String[] names = {"Anne","Ben","Charles","Dawn","Edward"};
for (int i = 0; i < names.length; i++) {
directory.put(names[i], new ArrayList<String>());
}
My question here relates to line 5 of the following code. Is it acceptable/best practice to pass an anonymous object (in this case given by new ArrayList()) as the actual argument to the put() method? My rationale for this is that by the nature of a map, these objects can still be reached by the following for example:
directory.get("Anne");
I don't see anything wrong with that. As a matter of fact, I don't even see a reason to call such a thing "anonymous". You are simply avoiding declaring a variable (i.e. a reference to that object - you are still creating the object) that you are never going to use anyway.
There is no such thing as an "anonymous" object in Java. There are anonymous classes, i.e. classes that don't have a name. An object has no concept of a "name". It is simple referred to by one or more references as needed.
Nothing wrong with that at all. I use it all the time.
In your code you create a new ArrayList object for every one of those names. Is this what you wanted to do? Whether it is best practice depends on what you are trying to do, it would be best practice to store e.g. the names of the pets these people own (a list of pets for every person).
Related
Good Afternoon,
i would like to ask regarding the methods to use string as reference.
Let say, that i got two object of type LinkedList named ChinaShip and HongkongShip
Normally, if i wanted to access a method (for example getFirst())
i will type ChinaShip.getFirst()
Now, let say that in other object, i got a variable Destination which content is a String.
The example of the Content will be China and Hongkong
Is it possible to use the content of the variable as the name for accessing the LinkedList object?
my approach first would be concatenate the variable first, which will be Destination + "Ship"
This will produce a string which is ChinaShip and HongkongShip
The reason i'm doing this way rather than comparing the string is that the Destination consist of hundreds of posibilities.
Thank You Very Much.
Regards,
Unfortunately you can't do that in Java. But this is closer with that:
HashMap<String, LinkedList> dest = new HashMap<String, LinkedList>();
dest.put("China", ChinaShip);
dest.put("Hongkong", HongkongShip);
.....
if(dest.containsKey(Destination){
dest.get(Destination).getFirst();
}
You can use the reflection API. If the lists are declared in the class MyClass you can use the following code:
LinkedList list = (LinkedList) MyClass.class.getDeclaredField(Destination + "Ship").get(this);
This assumes that the above code is called from within a MyClass object, otherwise the get(this) call must be changed to get(myClassInstance). Though as MadProgrammer mentions, you might be better of using a Map.
You can use a Map and use the desitnation string as your key because these will be unique:
Map<Desitnation, value> destinations = new HashMap<Desitnation, value>();
then search through the Map for your destination key:
http://www.tutorialspoint.com/java/util/hashmap_get.htm
I think you need to re-work your architecture. You shouldn't have to create method names from Strings.
It seems to me like you need a Ship object which has a destination, and a linkedlist of Ships.
If you need to map ships by destination, what you can also do is have a Map where they key is the destination string, and the value is the linked list of ships going to that destination.
So if you do a map.get("China") you will get a list of ships going to China, and from there you can do what you want.
So i have a code snippet here. I go this issue while i was discussing some code with my friend
Map<Integer , List<String>> myMap = new HashMap<Integer , List<String>>();
List<String> list = new ArrayList<String>();
myMap.put(45,list);
List<String> lst = myMap.get(45);
lst.add("String1");
lst.add("String2");
lst.add("String3");
System.out.println(myMap.get(45));
My question here is.
-> If its ok to modify the list outside the map through another reference? I am asking from OOP design point of view.
That is completely ok, IMHO
When you write
List<String> lst = myMap.get(45);
Still it is refering to the value in the map, for the key 45.
Once you get the value(reference to the list), It's up to you what you are doing with it.
If its ok to modify the list outside the map through another reference? I am asking from OOP design point of view.
It really depends on the context in which you're modifying it. If you plan on doing this a lot, with a lot of different values, then you're quickly going to find yourself with very confusing code that is difficult to debug and to follow.
BUT, in your example, you first load it from the map, then you edit it. It's completely clear that the data is coming from your Map object. Provided you make it clear with comments and documentation, especially when you're passing this reference between other methods, this isn't bad practise at all.
It is OK, provided that you take care of any potential synchronizations; e.g. if there are multiple threads that might be modifying the map and / or the list.
You might be confusing this with the case where you modify a key object. That is distinctly NOT ok if the modification breaks the hash table invariants; e.g.
if it causes either the key's hashcode to change, or
if it causes the key to give a different result when compared with some other key used in the table.
I am asking from OOP design point of view.
I'd say that OO design is neutral on this issue. You are using a Java interface (i.e. Map) that doesn't take control of the values. You are not violating encapsulation because the values are not encapsulated by the Map abstraction.
Whether this is sound design from the application perspective depends on the overall design. We can't make a judgement one way or another without understanding the context.
Every reference has a scope, it is your take(based on your requirement) whether you want the Map to be accessed through multiple reference or through a single reference.
It's OK.
After you have added numbers to the list in lines 5-7 in your code snippet, and then you get the list from the map again in line 8, the list you get from the map will have the extra numbers you just added.
That depends on what you want to do with the list and what your requirements are.
I'd say it is ok-ish but it might be better to encapsulate that in another object.
Consider the question what to do with empty lists, should they be removed or kept?
Encapsulation would allow you to ensure that empty lists are removed, since the user would then only access the wrapper, not the list directly.
Btw, with HashMap you have to change the list outside the map ;)
ArrayList is mutable. It is resizeable and keeps the same reference after modification. To have immutable list you should use following code.
List<String> list = Collections.unmodifiableList(new ArrayList<String>());
If you define list above way, than you can't modify it.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Java - HashMap vs Map objects
whats the different between
private Map<String, Integer> drawableMap = new HashMap<String, Integer>();
and
private HashMap<String, Integer> drawableMap = new HashMap<String, Integer>();
The type of the variable at the left-hand side of your assignment expression has nothing to do with object creation; therefore in both cases you are creating the exact same object. Since in Java you can only store a reference to an object into a variable, the type of that variable constrains the types of object the variable can refer to. In the first case it can refer to any object that implements Map; in the second, only HashMap objects are acceptable.
The other consequence is that in the first case you can only call methods of HashMap that are declared in the Map interface, whereas in the second case you can call any additional methods specific to the HashMap implementation.
In most real-world cases you will prefer the first case since you almost never need implementation-specific methods. The same rule goes for the complete Collections Framework.
In the first example, you can later assign drawableMap to other implementations of Map (e.g. LinkedHashMap). In the second example, you cannot - you are confined to HashMaps (and any of its subclasses). Generally, the first approach would be preferred over the second as it would provide greater flexibility down the road.
Ultimately, the first statement creates a variable of type Map that is an instance of HashMap. The second creates a variable of type HashMap that is also an instance of HashMap.
Is it possible to create new variables in java dynamically.
class A {
methodA(String variableName) {
}
}
So if new method is called twice, 2 new variables should be newly added to this class?
Is it possible?
No. Have you considered storing a Map<String, Object> in the class instead? The keys in the map would be the "variable names" and the values in the map would be the logical variable names.
If you could give more information about what you're trying to achieve (from a high-level perspective) that would help.
No, this is not possible to do in Java.
The fields in a class is determined at compile time and can't be changed during runtime (except though sophisticated techniques such as class reloading though for instance JRebel). I would however not recommend doing this, unless you're writing some IDE for instance.
A class and its members are defined and then compiled to bytecode, so they cannot be readily modified at run-time. That said, there are a number of libraries out there, such as cglib, which provide runtime modification functionality. This page can tell you more: http://java-source.net/open-source/bytecode-libraries
(This is not to say that runtime modification is the right thing to do!)
In a good design, a class must represent something, semantically speaking. You design it to represent an object in your system.
If you want to add more things to a design in run-time, well, something's not quite right -- unless, of course, the design needs adding information in run-time, and there are tons of data structures just ready for the job!
Check out Maps in Java, for example.
Following is the way that i have implemented and helped me to fix my solution easily without much hurdles.
// Creating the array List
List accountList = new ArrayList();
for(int k=0;k < counter;k++){
accountList.add(k, (String)flowCtx.getValueAt("transitId"+m));
}
Iterating the loop and adding the objects into the arraylist with the index.
//Retrieving the object at run time with the help of the index
String a = accountList.get(i));
Using a HashMap could be a solution. For example, if we have the following class:
class Staff {
private HashMap<String, Object> mylist = new HashMap<String, Object>() ;
void setNewVar(String s, Object o) {
mylist .put(s, o);
}
HashMap<String, Object> getVar() {
return mylist;
}
}
I can use it as:
staff.setNewVar("NumVars",11);
staff.setNewVar("NumBatches",300);
...
and then:
staff.getVar()
wherever you need. I use it to convert some variables (the number can change) to JSON, successfully.
So I have two questions about HashMaps in Java:
What is the correct way to initialize a HashMap? I think it might be best in my situation to use:
HashMap x = new HashMap();
But Eclipse keeps suggesting that I use:
HashMap<something, something> map = new HashMap();
Which is better?
Can a HashMap hold different types of objects/data types as values? For example, would this work and be OK:
map.put("one", 1);
map.put("two", {1, 2});
map.put("three", "hello");
In the first put(), I want an int as a value, in the second an int[], and third a string. Is this okay to do in Java with HashMaps? Also, is it okay to store a HashMap as a value within a HashMap?
It really depends on what kind of type safety you need. The non-generic way of doing it is best done as:
Map x = new HashMap();
Note that x is typed as a Map. this makes it much easier to change implementations (to a TreeMap or a LinkedHashMap) in the future.
You can use generics to ensure a certain level of type safety:
Map<String, Object> x = new HashMap<String, Object>();
In Java 7 and later you can do
Map<String, Object> x = new HashMap<>();
The above, while more verbose, avoids compiler warnings. In this case the content of the HashMap can be any Object, so that can be Integer, int[], etc. which is what you are doing.
If you are still using Java 6, Guava Libraries (although it is easy enough to do yourself) has a method called newHashMap() which avoids the need to duplicate the generic typing information when you do a new. It infers the type from the variable declaration (this is a Java feature not available on constructors prior to Java 7).
By the way, when you add an int or other primitive, Java is autoboxing it. That means that the code is equivalent to:
x.put("one", Integer.valueOf(1));
You can certainly put a HashMap as a value in another HashMap, but I think there are issues if you do it recursively (that is put the HashMap as a value in itself).
This is a change made with Java 1.5. What you list first is the old way, the second is the new way.
By using HashMap you can do things like:
HashMap<String, Doohickey> ourMap = new HashMap<String, Doohickey>();
....
Doohickey result = ourMap.get("bob");
If you didn't have the types on the map, you'd have to do this:
Doohickey result = (Doohickey) ourMap.get("bob");
It's really very useful. It helps you catch bugs and avoid writing all sorts of extra casts. It was one of my favorite features of 1.5 (and newer).
You can still put multiple things in the map, just specify it as Map, then you can put any object in (a String, another Map, and Integer, and three MyObjects if you are so inclined).
Eclipse is recommending that you declare the type of the HashMap because that enforces some type safety. Of course, it sounds like you're trying to avoid type safety from your second part.
If you want to do the latter, try declaring map as HashMap<String,Object>.
The way you're writing it is equivalent to
HashMap<Object, Object> map = new HashMap<Object, Object>();
What goes inside the brackets is you communicating to the compiler what you're going to put in the HashMap so that it can do error checking for you. If Object, Object is what you actually want (probably not) you should explicitly declare it. In general you should be as explicit as you can with the declaration to facilitate error checking by the compiler. What you've described should probably be declared like this:
HashMap<String, Object> map = new HashMap<String, Object>();
That way you at least declare that your keys are going to be strings, but your values can be anything. Just remember to use a cast when you get a value back out.
The 2nd one is using generics which came in with Java 1.5. It will reduce the number of casts in your code & can help you catch errors at compiletime instead of runtime. That said, it depends on what you are coding. A quick & dirty map to hold a few objects of various types doesn't need generics. But if the map is holding objects all descending from a type other than Object, it can be worth it.
The prior poster is incorrect about the array in a map. An array is actually an object, so it is a valid value.
Map<String,Object> map = new HashMap<String,Object>();
map.put("one",1); // autoboxed to an object
map.put("two", new int[]{1,2} ); // array of ints is an object
map.put("three","hello"); // string is an object
Also, since HashMap is an object, it can also be a value in a HashMap.
A HashMap can hold any object as a value, even if it is another HashMap. Eclipse is suggesting that you declare the types because that is the recommended practice for Collections. under Java 5. You are free to ignore Eclipse's suggestions.
Under Java 5, an int (or any primitive type) will be autoboxed into an Integer (or other corresponding type) when you add it to a collection. Be careful with this though, as there are some catches to using autoboxing.
Eclipse is suggesting you to define generic type so that you can have type safety. You can write
Map m = new HashMap();
which does not ensure type safety but following will ensure type safety
Map<Object,Object> = new HashMap<Object,Object>();
The Object can be any type such as String, Integer etc.
Map.of literals
As of Java 9, there is yet another way to instantiate a Map. You can create an unmodifiable map from zero, one, or several pairs of objects in a single-line of code. This is quite convenient in many situations.
For an empty Map that cannot be modified, call Map.of(). Why would you want an empty set that cannot be changed? One common case is to avoid returning a NULL where you have no valid content.
For a single key-value pair, call Map.of( myKey , myValue ). For example, Map.of( "favorite_color" , "purple" ).
For multiple key-value pairs, use a series of key-value pairs. ``Map.of( "favorite_foreground_color" , "purple" , "favorite_background_color" , "cream" )`.
If those pairs are difficult to read, you may want to use Map.of and pass Map.Entry objects.
Note that we get back an object of the Map interface. We do not know the underlying concrete class used to make our object. Indeed, the Java team is free to used different concrete classes for different data, or to vary the class in future releases of Java.
The rules discussed in other Answers still apply here, with regard to type-safety. You declare your intended types, and your passed objects must comply. If you want values of various types, use Object.
Map< String , Color > preferences = Map.of( "favorite_color" , Color.BLUE ) ;
In answer to your second question: Yes a HashMap can hold different types of objects. Whether that's a good idea or not depends on the problem you're trying to solve.
That said, your example won't work. The int value is not an Object. You have to use the Integer wrapper class to store an int value in a HashMap