Tom Joe

Arjun Dixit wrote:Hello Everyone,  I have completed my java certification and looking for job. My interview has been scheduled on 15th april 2020. I have covered lots of topics but remain few is left. Could anyone explain various types of Exceptions in Java? Also, tell me about the different ways of handling them. I am so confused about this part. I have checked a few resources like this which is helpful to me for my upcoming interviews. Can anyone suggest me some more tips?

What kind of role are you looking for ? What are the typical requirements of that role, besides knowledge or certification of Java ? Are you looking only for beginner or entry level jobs ?

Consider this code.

public class Container<T> {    private T content;//Correct !    //Compiler error - non-static type variable T cannot be referenced from a static context.    private static T stat;//Incorrect !    public static void statik(){        //Compiler error - Non-static field 'content' cannot be referenced from a static context.        content = null;//Incorrect !    } }

Consider the T stat line only. We can have Containers like Container<Integer>, Container<String> etc. But, "stat" is common to all instances of Container because it is static. Thus, you can't have stat = a Integer AND stat = a String etc. at the same time for all Containers. It has to be a fixed type, i.e. known at compile time.

Hence, T is meant to be used only for member variables (i.e the non-static ones). Java does not allow us to access member or non-static variables from a static context, such as a static method. For the same reason, we see that static method statik() has an error because it tries to access a member variable (T content).

Does this sound correct ?

Paul Clapham wrote:There you go, then. You have made a choice, and you have provided reasons for it. Just what the question asked you to do!

Yes, but I wonder if I missing something important.

Campbell Ritchie wrote:Why didn't they ask you to write a peek() method? Please show us your code.

I looked at the entire set of questions. No more methods need to be added other than the ones in question 1 and 2. Would peek() reveal something about my existing code ?

Paul Clapham wrote:I could tell you which I prefer and why. But that isn't the question they asked you. They asked which do you prefer and why.

But you already wrote both versions of the code, right? Can you develop an opinion about their relative merits?

With ArrayList, I don't need to write extra code to increase the size of the stack when it becomes full. More importantly, I don't need to waste time in in copying a filled array into bigger array. But, I can't think of anything other than that.

PS - I wonder what happens if a Stack with array is increased to a "huge" size and then majority of the elements are popped off. Currently, popping simply moves a pointer to the right index. It does not really remove the popped element from the array. This works, but it will just use memory.

I think I have the answer. It is okay to use Strings instead of custom Classes like Dough, Sauce in the factory method pattern. If we used custom classes, then it would be silly to have just one type of class for sauce, dough. So, its just easier to use a String instead.

I have two questions in my Java book. They ask you to develop the Stack data structure on your own using an array and array list. I have developed the code (and unit tests) successfully.

1. Implement a class Stack<E> that manages an array list of elements of type E. Provide methods push, pop, and isEmpty.

2. Reimplement the Stack<E> class, using an array to hold the elements. If necessary, grow the array in the push method. Provide two solutions, one with an E[] array and one with an Object[] array. Both solutions should compile without warnings.
Which do you prefer, and why?

But, I don't know the answer to this question - "Which do you prefer, and why?". How do I figure out the answer to that ?

Interface gives you an idea about what features/methods/functions a class has, without caring about how the class is implemented. Analogy from real life -

Car interface has :

- startCar(key)
- stopCar(key)
- accelerate(force)
- brake(force)
- getFuelRemainingPercentage()

This interface makes it easy for common people to drive cars. As a driver, we don't care about how Engine is implemented, i.e. Electric engine, Gasoline engine or Diesel engine. We only need to be able to startCar(key) and stopCar(key). We don't care whether car has DiscBrake or DrumBrake. We only care about accelerating and decelerating. We only care about the percentage of fuel in the tank, and not whether it is Gasoline, Diesel, BioFuel, Ampere hours etc.

We could even make our own Key Interface with methods turnOn(), turnOff(). Then we can have concrete classes like MechanicalCarKey and ElectronicCarKey. Both work the same way, i.e. same interface of on or off. The only difference is that in Mechanical, you rotate the key and in electronic, you push buttons. The advantage is that if your car has a mechanical key, you can go to a auto store and update it with an electronic key as long as your key can do "on" and "off".

We can make the above interface inconvenient for users too. For example, we can replace startCar(key) with rotatePiston(), injectFuel(fuel type) etc. With this horrible interface, Drivers will be forced to remember that injectFuel(fuel type) must be called before rotatePiston(). Learning all these internal details about internal combustion engines is useless for him.

When we start making electric cars (like Tesla), different methods will be used to start the engine - turnOnBattery(), turnOnMotors(). This way, we can make the driver's life miserable by now forcing him to also learn basics of electric cars. All he wants to do is start and stop engine etc, and not learn about automobile theory.

Does that help ?

Tim Holloway wrote:The joys of European living.....Ran out of milk.....anyone?

Have you considered freezing milk ? I always buy one extra and freeze it. It works quite well.

Stephan van Hulst wrote:Yeah that's pretty much me.

Although my girlfriend is home more as well, so we play board games or do jigsaw puzzles together more often.

Side note - I have always seen nerdy people & couples playing games that require a lot of thinking, even after their day job of "thinking" (ex. programming). I wonder how they get the energy and will to do even more thinking. I guess I'll never know because I am not really nerdy or sharp.

Campbell Ritchie wrote:Counting loo rolls.

Get a bidet and count liters instead.

I have dog cone around my neck to prevent scratching and 6 foot disc around my belly to enforce social distancing. I am mostly in front of the computer, learning stuff to prepare for interviews.

We could say that learning and using Generics can be hard because of things like type erasure. Many rules to remember. Is there anything that can be done to make generics easier to use ? Is it being done ?

PS - This seems like an ok candidate for meaningless drivel forum.

I am trying to learn the Factory pattern from the Head First Design patterns book for the second time. The book says that there are two types of factory pattern - Factory method and Abstract Factory. The book uses the Pizza and PizzaStore example to illustrate the pattern. Basically, we have a PizzaStore that depends on Pizza objects. We have to develop a generic PizzaStore software which allows people to order pizzas. The logical process/steps of Pizza ordering remain the same - create(String pizzaType), prepare() or setupIngredients(), cut(), box() etc. The create() method belongs to PizzaStore and the other methods belong to Pizza. As we work on the project, we have to add new types of pizzas often. But, we don't want to keep changing our generic PizzaStore code every time a new Pizza is added. After all, the pizza making and ordering process always has the same logical steps.

The book has separate code for each of the two types of factory. For example, the Pizza class below has only String members for name, dough, sauce etc. in factory method. But in abstract factory, it has classes for Dough, Sauce, etc. Why can't Pizza have the same type of members in both patterns ? In factory method, we could have just one type of Dough instance instead of String dough. In abstract factory, we could have any number of Dough instances. I don't understand the reason for this inconsistency. Is that inconsistency required by the example or did the author just do it to save some effort in typing ?

Factory method - Pizza :

public abstract class Pizza { String name; String dough; String sauce; ArrayList<String> toppings = new ArrayList<String>(); public void prepare() { System.out.println("Prepare " + name); System.out.println("Tossing dough..."); System.out.println("Adding sauce..."); System.out.println("Adding toppings: "); for (String topping : toppings) { System.out.println("   " + topping); } } public void bake() {System.out.println("Bake for 25 minutes at 350");} public void cut() {System.out.println("Cut the pizza into diagonal slices");} public void box() {System.out.println("Place pizza in official PizzaStore box");} public String getName() {return name;} public String toString() {//blah} }


Abstract Factory - Pizza :

public abstract class Pizza { String name; Dough dough; Sauce sauce; Veggies veggies[]; Cheese cheese; Pepperoni pepperoni; Clams clam; public abstract void prepare();//Prepares the Dough, Sauce, Cheese etc. public void bake() {System.out.println("Bake for 25 minutes at 350");} public void cut() {System.out.println("Cutting the pizza into diagonal slices");} public void box() {System.out.println("Place pizza in official PizzaStore box");} public void setName(String name) {this.name = name;} public String getName() {return name;} public String toString() {//blah} }

DIAGRAMS :

Factory method -


Abstract factory -

Bear Bibeault wrote:
As Steven pointed out.................It all depends whether you want to be up-to-date with modern tooling, or write code as if it were still 2012.

I want to be up-to-date with modern tooling only.