Doubt on allocating objects at runtime

[Dev Choudhary]

I just had a doubt in what way objects can be allocated at run-time, I mean if the number of objects to be created is not known at development time but is dependent on user input.
Does such need occurs in any case in programming?

Actually the thought came into my mind when I came across this programming problem which was to be done using object oriented design.

The problem was to maintain information of number of Employees like ID, Name, Salary, etc. by taking input from the user and then it required to print the Employee names in the order of descending order of their Salary. I know that we can create a class Employee and set the required fields by setters methods. But what about creating exact required number of 'Employee objects' (as the information will be feed by user)? Need to allocate objects dynamically at run-time, right ? Is there any methodology other than allocating objects at run-time (but using object oriented principles) that can be used?

Also about sorting the Salary, I will get it sorted, but how to print Employee names according to the descending order of their Salary.

Any suggestions will be helpful.

[Les Morgan]

You can do a horrible design and make a set number of objects and hold them in an ArrayList, but that is no better than just making an array--except that your ArrayList implements Collection, so you can have it order by fields in the objects in the ArrayList.

For your second part of your question, store your objects in a structure that implements Collection, like ArrayList, and you can have them sort as you desire to do so.

[Campbell Ritchie]

I think you have given an example where the number of objects created is determined at runtime!

int numberOfEmployees = myScanner.nextInt();
for (int i = 0; i < numberOfEmployees; i++)
{
   Employee e = new Employee(...);
   staffList.add(e);
}

If you look in the Collectors class, they give an example of summating salaries by department. You can try this sort of thing:-

import static java.util.stream.Collectors.toList;
// ...
List<Employee> bySalary = staffList.stream()
                                   .sorted(e::getSalary)
                                   .collect(toList());

Since toList is a static method of the Collectors class, it is usual to import something; see line 1 above. You must use Java8 to get that code to work.

[Les Morgan]

Oh, ya, you could also use a database and not have to worry about most of the problem, the DB will save how ever many you send to it, and you can have the DB order by any field you want.

[Campbell Ritchie]

You can sort arrays as well. But you are right to put things into a Collection<Employee>. I hadn't realised you wanted reverse order. You will have to sort on something like
(e1, e2) -> (e2.getSalary() - e1.getSalary())
… but that is error‑prone unless you are sure the salaries are all positive.

[Campbell Ritchie]

I like the suggestions about databases.

[Dev Choudhary]

Les Morgan wrote:but that is no better than just making an array.

Do you mean allocating objects at run-time and storing them into array dynamically ?
Can you please give code snippet for that ? Actually I am beginner to Java.

[Les Morgan]

Problem is, you still have to create at least one Employee object at runtime to use OOP, but I guess you could just have the fields as members of a different object--actually hurts my brain to try to think of it that way now.

Campbell Ritchie wrote:I like the suggestions about databases.

[Les Morgan]

Dev Choudhary wrote:

Les Morgan wrote:but that is no better than just making an array.

Do you mean allocating objects at run-time and storing them into array dynamically ?
Can you please give code snippet for that ? Actually I am beginner to Java.

//WARNING UNTESTED CODE FOLLOWS;
ArrayList<Employee> emp = new ArrayList<Employee>();
for(int k=0;k<100;k++) emp.add(new Employee());

[Les Morgan]

Dev Choudhary wrote:

Les Morgan wrote:but that is no better than just making an array.

Do you mean allocating objects at run-time and storing them into array dynamically ?
Can you please give code snippet for that ? Actually I am beginner to Java.

or for the array:

//WARNING UNTESTED CODE FOLLOWS;
Employee[] emp = new Employee[100];
for(int k=0; k<100; k++) emp[k] = new Employee();

[Dev Choudhary]

Thanks guys for the suggestions.

Les Morgan wrote:

//WARNING UNTESTED CODE FOLLOWS;
ArrayList<Employee> emp = new ArrayList<Employee>();
for(int k=0;k<100;k++) emp.add(new Employee());

But that will create 101 objects, right ?

[Les Morgan]

Dev Choudhary wrote:Thanks guys for the suggestions.

Les Morgan wrote:

//WARNING UNTESTED CODE FOLLOWS;
ArrayList<Employee> emp = new ArrayList<Employee>();
for(int k=0;k<100;k++) emp.add(new Employee());

But that will create 101 objects, right ?

nope, just 100... 0 thought 99. because it is <100 so at 100, there is no loop executed.

[Les Morgan]

Les Morgan wrote:

Dev Choudhary wrote:Thanks guys for the suggestions.

Les Morgan wrote:

//WARNING UNTESTED CODE FOLLOWS;
ArrayList<Employee> emp = new ArrayList<Employee>();
for(int k=0;k<100;k++) emp.add(new Employee());

But that will create 101 objects, right ?

nope, just 100... 0 thought 99. because it is <100 so at 100, there is no loop executed.

if you did this:

int k=0;
for(k = 0; k<100; k++) emp.add(new Employee());

You would still only get 100 objects in the ArrayList, but when you exit, you could see that k was actually at 100, so k is incremented to 100 and the loop does 101 tests, but the condition, k<100, only lets the loop execute 100 times.

[Dev Choudhary]

Les Morgan wrote:

Dev Choudhary wrote:Thanks guys for the suggestions.

Les Morgan wrote:

//WARNING UNTESTED CODE FOLLOWS;
ArrayList<Employee> emp = new ArrayList<Employee>();
for(int k=0;k<100;k++) emp.add(new Employee());

But that will create 101 objects, right ?

nope, just 100... 0 thought 99. because it is <100 so at 100, there is no loop executed.

Yes exactly. Got it.

But one more thing - How can we exactly allocate objects at run-time on user input. For example how to achieve this - we can show message "Enter employee details" and the object will be created and then we can ask if more employees details are to be feeded and then objects will created accordingly. Or is there any better way of creating objects other than this.

[Les Morgan]

Dev Choudhary wrote:

Les Morgan wrote:

Dev Choudhary wrote:Thanks guys for the suggestions.

Les Morgan wrote:

//WARNING UNTESTED CODE FOLLOWS;
ArrayList<Employee> emp = new ArrayList<Employee>();
for(int k=0;k<100;k++) emp.add(new Employee());

But that will create 101 objects, right ?

nope, just 100... 0 thought 99. because it is <100 so at 100, there is no loop executed.

Yes exactly. Got it.

But one more thing - How can we exactly allocate objects at run-time on user input. For example how to achieve this - we can show message "Enter employee details" and the object will be created and then we can ask if more employees details are to be feeded and then objects will created accordingly. Or is there any better way of creating objects other than this.

Unless you know the number of objects to read in, then you are guessing and you are trying to make the pool of objects arbitrarily large enough to take into account all possible numbers of object to be input. Of course you cannot do that, because the only way to make that number arbitrarily large enough would be to make it infinite, in any case workably infinite which is past the amount of memory you have in the computer. So instead of doing that we use databases and create just 1 object, read that object in, then store it in the database or make a pool of objects as a cache to allow greater efficiency when we write the objects to the DB.

Data input needs to handled as a black box as far as numbers go, what ever limit you put on the number you'll accept is always broken at some point in time. So never limit.

Back in the 80's MS said you'll never need more then 640K of RAM, so DOS had that limit. Then they went to 1024K, 1 MB, and they said you'll never need more. It took years and years to get to a place where Windows was not running out of resources because MS thought finitely--640K, 1MB, and then 3 internal stacks each of 1MB to handle resources. Real world use has throughout computer history shown that what ever you put a limit on, somebody is going to break it, then you'll have to fix it.

Don't put a limit on it to start with.