|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On September 16 2013 03:39 darkness wrote:I've been wondering how one can keep record of unlimited number of users in a struct way fashion in Java. For example,
class Person {
private String name;
private String surname;
private int age;
Person(String name, String surname, int age) {
this.name = name;
this.surname = surname;
this.age = age;
}
// some getter methods
public int getAge() {
return age;
}
// etc... and setter methods too
public void setAge(int age) {
this.age = age;
}
}
I know I can have a single record by having: Person bill = new Person("Bill", "Gates", 57); How can I have an unlimited number of people though? Is it possible without creating individual objects manually?
Its absolutely possible, how do you think Starcraft handles training troops?
The following code assumes there's some other code generating names and ages:
Person list[] = new Person[n]
for (int i = 0; i < n; i++)
{
Person temp = new Person(generateFirstName(), generateLastName(), generateAge());
list[i] = temp;
}
This code gives you an array "list" containing n Persons. As you can see, none of them are manually created.
|
Awesome. Thank you! I have additional questions if you don't mind. Is ArrayList the way to go in this case? If there's frequent insert/remove, is LinkedList better? How can I use one if needed?
Maybe like this?
Person list[] = new LinkedList();
Or is that not valid?
Thanks!
|
Yeah ArrayList is the way to go since you want "unlimited" and not up to "n" elements using just an array.
For example:
List<Person> myList = new ArrayList<Person>();
Runtime Analysis
|
On September 16 2013 04:18 darkness wrote:
If there's frequent insert/remove, is LinkedList better?
What other operations do you expect to be performed "frequently"? Search? Sorting?
|
The advantage of ArrayList is that you can get an element in O(1), while with a Linked List you need O(n) time. However deleting an element while iterating the list only needs O(1) for a Linked List but O(n) for an Array List.
Both lists are "unlimited" as far as memory goes.
|
On September 16 2013 04:18 darkness wrote:Awesome. Thank you! I have additional questions if you don't mind. Is ArrayList the way to go in this case? If there's frequent insert/remove, is LinkedList better? How can I use one if needed? Maybe like this? Person list[] = new LinkedList(); Or is that not valid? Thanks!
Similar to the post above me, you're going to want to do something like
List<Person> = new LinkedList<Person>()
I'm not sure about the standard java generic library but that is the general idea
|
On September 16 2013 04:18 darkness wrote:Awesome. Thank you! I have additional questions if you don't mind. Is ArrayList the way to go in this case? If there's frequent insert/remove, is LinkedList better? How can I use one if needed? Maybe like this? Person list[] = new LinkedList(); Or is that not valid? Thanks!
Usually the best way to store a potentially unlimited amount of data is a database, but if you need it in the code, there is a lot to think about when choosing the correct data type to store it in.
The easiest are arrays, which have the advantage that you can instantly access any element as long as you know the index. However, they are slow when inserting/deleting elements somewhere in the middle as every element after the inserted/deleted element has to be moved (which happens behind the scenes but still consumes time). They also are relatively slow if you want to search for a specific element since you have to move through each element until you find the one you search for. This can be compensated for by using a sorted list, which speeds up searching but requires the overhead of keeping the array sorted after every change of data. They are the fastest choice if you always have the index to the elements you are looking and when the dataset stays mostly constant and any inserts/deletes are usually near the end of the array.
Another option are linked lists, which have the advantage that inserting/deleting is very fast. However, accessing a specific element always requires searching through all of them to find it, you can't access it directly. Like normal arrays, searching for a specific element also takes time as you need to search through all of them and keeping a sorted list does not speed up searching since you can't look ahead, you have to move through every single element to find the element after it. They are the fastest choice if you insert/delete a lot but don't often search for elements.
A third option are hashmaps/associative arrays, which allow quick access to any element according to the chosen keys and depending on the implementation usually have an insert/delete time close to that of a linked list. Performance wise they are roughly half way between arrays and linked lists in most situations with the advantage that you can search elements very fast if you chose the right keys. A disadvantage is that the order of elements is not guaranteed, so if you just iterate through the data, you might get it in a different order than you created it in. They are good choices if you know what you are usually searching for, e.g. in your case it might be a Lastname + Firstname key which allows you to find a user very fast if you have his name. They are not a good choice if you need your data in a specific order.
The best pick always depends on the use-case and it's impossible to say "X is always better than Y".
|
However in general unless you are trying to launch a rocket into space it is not a good practice to obsess about optimalization so early into development, it is nice to pick a correct list implementation but in the end, the time you can save by having O(1) somewhere instead of Log(n) is usually negligible compared to the access times that will be created by network or database.
Far more important then picking a correct implementation is having a good architecture that can scale easily.
|
You should really read some on mappings (associative array data structures). This way you can not only have nice arrays for multiple things but also store and access data in a much more coherent way. Also, getter and setter methods are bad and should be avoided, more on that here: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html (there's also a link explaining why "extends" is evil).
|
On September 16 2013 03:39 darkness wrote:I've been wondering how one can keep record of unlimited number of users in a struct way fashion in Java. For example,
class Person {
private String name;
private String surname;
private int age;
Person(String name, String surname, int age) {
this.name = name;
this.surname = surname;
this.age = age;
}
// some getter methods
public int getAge() {
return age;
}
// etc... and setter methods too
public void setAge(int age) {
this.age = age;
}
}
I know I can have a single record by having: Person bill = new Person("Bill", "Gates", 57); How can I have an unlimited number of people though? Is it possible without creating individual objects manually?
You seem to be missing several basics in object oriented programming if you do not know that you can simply use Lists of objects or arrays of objects.
There are several good basic guides for starting java and c# programmers that would be really useful to you. I suggest you use google or maybe someone can recommend you a good guide he/she him/herself used.
|
On September 16 2013 05:28 Holy_AT wrote:Show nested quote +On September 16 2013 03:39 darkness wrote:I've been wondering how one can keep record of unlimited number of users in a struct way fashion in Java. For example,
class Person {
private String name;
private String surname;
private int age;
Person(String name, String surname, int age) {
this.name = name;
this.surname = surname;
this.age = age;
}
// some getter methods
public int getAge() {
return age;
}
// etc... and setter methods too
public void setAge(int age) {
this.age = age;
}
}
I know I can have a single record by having: Person bill = new Person("Bill", "Gates", 57); How can I have an unlimited number of people though? Is it possible without creating individual objects manually? You seem to be missing several basics in object oriented programming if you do not know that you can simply use Lists of objects or arrays of objects. There are several good basic guides for starting java and c# programmers that would be really useful to you. I suggest you use google or maybe someone can recommend you a good guide he/she him/herself used.
Yeah, it didn't come to my mind that collections and data structures are built as generic. Then again, I have no experience (or should I say, I didn't have to do it until now), so yeah.. I'm still learning.
I'm definitely up for some revision of my OOP understanding.
If the 'Java, Java, Java' book is ok, then I can have a look at it tomorrow. 
Book: http://books.google.bg/books/about/Java_Java_Java.html?id=k_a0pVRrFVkC&redir_esc=y
|
On September 16 2013 05:28 Holy_AT wrote:Show nested quote +On September 16 2013 03:39 darkness wrote:I've been wondering how one can keep record of unlimited number of users in a struct way fashion in Java. For example,
class Person {
private String name;
private String surname;
private int age;
Person(String name, String surname, int age) {
this.name = name;
this.surname = surname;
this.age = age;
}
// some getter methods
public int getAge() {
return age;
}
// etc... and setter methods too
public void setAge(int age) {
this.age = age;
}
}
I know I can have a single record by having: Person bill = new Person("Bill", "Gates", 57); How can I have an unlimited number of people though? Is it possible without creating individual objects manually? You seem to be missing several basics in object oriented programming if you do not know that you can simply use Lists of objects or arrays of objects. There are several good basic guides for starting java and c# programmers that would be really useful to you. I suggest you use google or maybe someone can recommend you a good guide he/she him/herself used.
I'd suggest Symphony in C++ standard by Jerzy Grebosz (if it's available in English) and Code Complete, 2nd edition by Steve McConnell. This 2 books have truly opened my eyes.
|
Honestly, there are a lot of decent books for your purposes, just pick whatever you have available. Regardless of which source you go for, remain critical. Books aren't full of absolute undeniable truth. Sometimes they are partially outdated, sometimes they advocate debatable things more than appropriate. Books are written by humans after all.
There mainly are two things you are looking for in books:
- what you can do
- what you should or should not do
The latter is where you should be most careful. Words like "never" or "always" should ring alarm bells: Absolutes usually are out of place in the "what you should do" department.
By the way, is "Code Complete" the book where the author says about checked exceptions that "the discussion is over"? Because that sure is a debatable statement (even though there are no satisfying implementations of the concept in popular languages).
|
On September 16 2013 06:05 spinesheath wrote:
Honestly, there are a lot of decent books for your purposes, just pick whatever you have available. Regardless of which source you go for, remain critical. Books aren't full of absolute undeniable truth. Sometimes they are partially outdated, sometimes they advocate debatable things more than appropriate. Books are written by humans after all.
There mainly are two things you are looking for in books:
- what you can do
- what you should or should not do
The latter is where you should be most careful. Words like "never" or "always" should ring alarm bells: Absolutes usually are out of place in the "what you should do" department.
By the way, is "Code Complete" the book where the author says about checked exceptions that "the discussion is over"? Because that sure is a debatable statement (even though there are no satisfying implementations of the concept in popular languages).
To add to your criticism about books, 'Java, Java, Java' suggests ignoring the 0 index of arrays for the sake of readability. I've done this on my own in year 1 at university, and I got marked down for it. I didn't follow this book's advice back then. Feedback was like "do not waste memory" or something.
In other words, you only use the range from index[1] to index[n].
I mean this edition: http://archive.org/details/JavaJavaJavaObject-orientedProblemSolving
PDF, Page: 449/865
|
Actually arrays in the Starcraft 2 Editor are one larger than you declare them. :D
|
On September 16 2013 06:58 darkness wrote:Show nested quote +On September 16 2013 06:05 spinesheath wrote:
Honestly, there are a lot of decent books for your purposes, just pick whatever you have available. Regardless of which source you go for, remain critical. Books aren't full of absolute undeniable truth. Sometimes they are partially outdated, sometimes they advocate debatable things more than appropriate. Books are written by humans after all.
There mainly are two things you are looking for in books:
- what you can do
- what you should or should not do
The latter is where you should be most careful. Words like "never" or "always" should ring alarm bells: Absolutes usually are out of place in the "what you should do" department.
By the way, is "Code Complete" the book where the author says about checked exceptions that "the discussion is over"? Because that sure is a debatable statement (even though there are no satisfying implementations of the concept in popular languages). To add to your criticism about books, 'Java, Java, Java' suggests ignoring the 0 index of arrays for the sake of readability. I've done this on my own in year 1 at university, and I got marked down for it. I didn't follow this book's advice back then. Feedback was like "do not waste memory" or something. In other words, you only use the range from index[1] to index[n]. I mean this edition: http://archive.org/details/JavaJavaJavaObject-orientedProblemSolvingPDF, Page: 449/865
Why would you ignore index[0]? You should always be counting from 0, not 1... It's actually worse for readability if you start with 1 all the time because people who are accustomed to 0 being the beginning of the array (99.9% of coders I believe) will be confused and are going to waste time by checking all the code to see what you use index[0] for (and not finding it).
Personally, I'd be baffled if I came across such a solution.
|
Another downside is that by ignoring the first index, you can get some odd behavior if you try to access the array with an iterator instead of a standard for loop. (for (int myInt : myArray) vs for(int i = 1; i < myArray.length + 1; i++) ) For example, an array of ints initilizes with all values as zero (it seems), so if you then iterate over them, but never did anything with the first index, you will have n+1 elements instead of n, plus an extra 0.
You will also confuse people quite a lot. Sometimes you just do things not because one way is better than the other, but just because that is the way everyone will expect it to work, and may not notice you did it differently, causing problems.
|
Also if you want to initialize an array of size 5 you need to do sth like this
int array[5+1];
Which doesn't make any sense at all
|
Well, I didn't think much like a programmer in year 1. index[1] is more natural to humans than index[0] imho, so my approach was like that back then. I don't do it anymore though. It happened only once anyway.
I am surprised that a book recommended by universities suggests ignoring the 0 index.
|
On September 16 2013 07:59 darkness wrote:
Well, I didn't think much like a programmer in year 1. index[1] is more natural to humans than index[0] imho, so my approach was like that back then. I don't do it anymore though. It happened only once anyway.
I am surprised that a book recommended by universities suggests ignoring the 0 index.
Lua (which was originally designed for non-programmers) starts its string indices at 1 for this exact reason ^^ I was so confused when I started learning Lua but you get used to it pretty quickly, and it IS way more natural. I totally agree with the design decision from the people who designed Lua that way.
That being said, it still confuses the shit out of people who've been learning it with 0 all the time - so while it is probably nicer and easier to pick up for someone who's never programmed before, it's not gonna fly in any workplace =P
|
|
|
|
|
|
EPT
