This question already has answers here:
What is a raw type and why shouldn't we use it?
(16 answers)
Closed 9 years ago.
Which would be better in generics? Seems same to me, but eclipse complains to just plain List, but not with List<Object>.
Parameterzation should be used. It provides the compiler with details for things such as casting and autoboxing.
With this, especially when types other than Object are used, the compiler can handle the casting and ensuring compatibility. Especially with return values and method signatures, the true type parametrized may not be exposed out of bytecode to other classes.
Do note that List<Object> is semantically and programatically almost as useless as List. Make sure that if you can, use a more specific type. If declaring a class or method, make sure to use a proper, specific wildcard.
Neither. It is better to specify the specific generic type of the list contents if possible. At the very least a common interface should be used.
Related
This question already has an answer here:
Passing parameterized Class instance to the constructor
(1 answer)
Closed 8 years ago.
I wanted to obtain class object of Iterator and discovered that
Iterator<String>.class
is not valid. This highlighted a question if its possible at all to use
".class"
syntax for
Object<T>
kind of objects in Java.
If yes, then how it can be done?
If not, what are the alternatives ?
I am doing Mocking for Iterator using Mockito's
Mockito.mock(Class<T>)
syntax.
You can't do this because generics in Java are implemented using erasure i.e. you don't get specialized version of your classes for each type parameter used at runtime. Take a look at this answer in case it didn't turn up in your search.
It is not possible. The way that generics are implemented in Java, they only exist at compile time, for the purpose of type checking.
This question already has answers here:
"Program to an interface". What does it mean? [duplicate]
(8 answers)
Closed 8 years ago.
I've seen many times statements like this:
List list = new ArrayList<String>();
What's the point of writing like this? I mean setting the type of object a super class or implemented Interface of it. Is this makes a difference or improves performance or things like that?
Note
My English is poor and I've probably written the question title and body confusing. Please edit that and then remove this line.
That statement means that you can use all of the features of List that are implemented using ArrayList but you could also use the features inside LinkedList. Although there is no harm if you have the object type as ArrayList, it could be useful for example, if you have a method that takes in a List parameter instead of an ArrayList, your choices have expanded and you can have other classes that implement that type, e.g LinkedList.
To put it simply, if you are using the interface List as its type, you are saying: "I want to use any class that does these things to do my own" as List is an interface. But if you just use ArrayList, you are saying: "I want to use just this specific class to to my things". In summary, it gives you more flexibility.
Other than that, there isn't much of a difference using the super class as the type or using ArrayList or other subclass as itself.
Hope that this is what you are asking about, and hope that it makes sense. If not, feel free to ask any questions.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is there any way to enforce typing on NSArray, NSMutableArray, etc.?
I'm Java programmer and I'm starting on Obj-C, in java i can create a mutable array with determined type of class, like as follow:
ArrayList<MyClass> list;
in Obj-c I know the NSMutableArray but i don't know and not found how to determinate the type of class into it.
Have a way of make this with it or other class without NSMutableArray which can do this?
Thanks a lot.
No, Cocoa/Objective-C doesn't offer typed collections like this. All objects in the collection must inherit from NSObject (which is basically everything besides primitives and structs), but beyond that, it's up to you to understand/manage what is going on in the array. Objects in an NSMutableArray are represented in its interface by the generic type id.
From a design standpoint, collections in Cocoa typically do contain homogeneously-typed objects. The name of the array is often used to indicate what's inside it (just as in Java), e.g. bookTitlesArray or just bookTitles (i.e. strings). Additionally, from an abstraction standpoint, sometimes lightweight classes are used to "wrap" a raw NSMutableArray to enforce type checking at the interface. As in, a new class called BookTitleList which offered a subset of the add, lookup, remove methods and passed them through to an internal array after e.g. validation. But YMMV depending on your needs.
Although there are no type parameters in Objective C, you'll find it much less of a nuisance than in Java because you don't have to downcast to call a method. Objective C is more like JavaScript in this respect.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why aren't Java Collections remove methods generic?
I noticed that few of the LinkedList operations take Generic parameter type E, while a few take 'Object' as the parameter. For ex,
add(E e)
remove(Object o)
Is there a specific reason to do that? Why not make 'remove' take a generic type E. (I know it doesn't matter after type erasure, but just wondering).
This is because removal operation checks for equality using equals() method and equals() method takes in an Object as parameter not generic .
Both the add and remove methods are inherited from the Collection interface. The remove method was not retrofitted with a generic argument presumably because it wouldn't matter. Remove doesn't affect the type safety of the collection and when you're changing one of the most popular APIs on the planet, fewer changes are better. You'll see that the contains method suffered the same fate as well.
Because the caller can call remove or contains using any type of object and the code will still perform just fine. The compile time contract that the type parameter of collections uses just guarantees* that anything in the collection will be of the given type. It doesn't care about whether you ask it if it contains an object of a different type.
*Nitpicker's Corner, I know that Java generics really aren't a guarantee. More of syntactic sugar I suppose.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Question marks in Java generics.
I'm editing someone else's code for an assignment and I'm trying to clean it up to get rid of the dozens of warnings in it and Eclipse was giving warnings for the use of Collections as a raw type. When I took it's suggested fix it created this.
Collections<?>
Example
public static String separatedString(Collection<?> c, String separator) {
return separatedString(c, "", separator, "", new StringBuffer())
.toString();
}
I was just wondering exactly what this did and whether or not it was safe.
This ist the concept of generics.
Its all about object oriented programming
For example if i declare a variable as Collection<MyClass> ONLY and ONLY objects that are of declared Type or Subtype of MyClass may be put in it.
This is good to keep things straight and put constraints on the way this code should be used.
The question mark stands for class of your choice.
When you initialise the class you can ... whoops just seeing there is an exact duplicate here:
What does the question mark in Java generics' type parameter mean?
Adding
MyClass<?>
adds generics to the code, but doesn't really add much benefit since the naked question mark can mean any class. Google and read up on generics, and you'll learn how to create generics that do constrain what classes may be used and how this adds the benefit of compile-time type checking.
e.g.,
MyClass<? extends Comparable>
Which will constrain coders to only using Comparable types with MyClass. A basic tutorial starts here: Java Generics Tutorial