Code Optimization Part 2

[Jhoel Esmejarda]

Hello everyone,

I'm back with my Vending Machine I need again your help, before I posted the my codes here in Java Ranch and I got so many advices regarding how I code. I hope this new codes does some improvements. Okay, here's the program Vending Machine program which gives you food and change if your inserted a big amount of money. I have here 3 Classes. The first one is the Menu Class,

public class Menu{
	
	private String[] productArray = {"Coffee", "Milk", "Chocolate"};
	private double[] priceArray = {10, 15, 20};
	private int num;
	private double prodAmount;
	private double totalAmount;
	private String prodName;

	public void showMenu(){
		System.out.println("============================================");
		System.out.println("=       Welcome to My Vending Machine      =");
		System.out.println("============================================");
		System.out.println(" ");
		
	}

	public void showMenuList(){	
		for (int i = 0 ; i < productArray.length ; i++){
			int sn = i + 1;
			System.out.println("[" + sn + "] " + productArray[i] + ": " + "$" + priceArray[i]);
		}
		System.out.println(" ");
		System.out.println(" ");
		System.out.println("============================================");;		
	}

	public String getProdName(){
		prodName = productArray[num - 1];
		return prodName;
	}
	public int getCheckOrder(){
		return num;
	}

	public int setCheckOrder(int slotNum) {
		if (slotNum > productArray.length){
			System.out.println("Not Available");
		}
		num = slotNum;
		return num;
	}

	public double getProdAmount(){
		prodAmount = priceArray[num - 1];		
		return prodAmount;
	}
}

second one is the Slot Class that gets your order and payment,

import java.io.*;
public class Slot{

	
	public String getProdSlot(){
		String slotNum = null;
		System.out.print("Select slot: ");
		try{
			BufferedReader is = new BufferedReader(new InputStreamReader(System.in));
			slotNum = is.readLine();
			if (slotNum.length() == 0){
				return null;
			}
		}
		catch(IOException e){
			System.out.println("IOException " + e);
		}
		return slotNum;
	}

	public double getPayProd(){
		double payProd = 0;
		System.out.print("Insert amount: ");
		try{
			BufferedReader is = new BufferedReader(new InputStreamReader(System.in));
			payProd = Double.parseDouble(is.readLine());
		}
		catch(IOException e){
			System.out.println("IOException " + e);
		}
		return payProd;
	}
}

and the third one VendingMachine Class with the main() method,

class VendingMachine{
	public static void main(String[] args) {
		Menu m = new Menu();
		Slot s = new Slot();
		double bal = 0;
		double paySlot = 0;

		m.showMenu();
		m.showMenuList();
		int order = Integer.parseInt(s.getProdSlot());
		m.setCheckOrder(order);

		while (order > 3){
			m.showMenu();
			m.showMenuList();
			order = Integer.parseInt(s.getProdSlot());	
			m.setCheckOrder(order);
		}

		String prodName = m.getProdName();		
		System.out.println(m.getProdName() + ": " + "$" + m.getProdAmount());	

		bal = m.getProdAmount();		
		while (bal > 0){
			paySlot = s.getPayProd();
			if(bal > paySlot){
				bal = bal - paySlot;
				if ( bal > 0) {
					System.out.println("Remaining balance: " + bal);
				}
				else{
					System.out.println("Here's your " + prodName + "!");
				}
			}
			else{
				bal = paySlot - bal;
				if (bal > 0){
					System.out.println("Your change: " + bal);
					System.out.println("Here's your " + prodName + "!");
					break;
				}
				else{
					System.out.println("Here's your " + prodName + "!");
					break;
				}
			}
		}
	}
}

Please help me with this, I don't have any formal training with programming nor a graduate of any computer course, I'm just studying by myself and hoping I can get this Java language so that I can start a career. I hope someone bothers to check my codes and explains anything that you think is wrong or on how I code so that I can add this up to my notes. thanks a lot.

[harshvardhan ojha]

Hi Jhoel, I appreciate your enthusiasm for learning and want to suggest you PMD for eclipse which will guide you to maintain code quality. Let me know if you are looking beyond coding, i.e. design. You can always use some design patterns for your problems.

[Jesper de Jong]

I haven't looked at your code in detail but what did stand out was that your code is very well formatted, and you're keeping to the "standard" Java conventions for naming variables, classes and methods. So that's one thing you're doing right.

[Jhoel Esmejarda]

@harshvardhan ojha

Yeah I'm very interested in learning that, can you help me with that topic? thanks a lot.

@Jesper de Jong

Woah! lol, thanks a lot for that comments I appreciate it, it really helps.

If there are any other comments and suggestions just post in this topic TIA.

[harshvardhan ojha]

Hi Jhoel, please follow these simple steps and your good to go...
PMD

[Vishal Shaw]

Hi,

Just one more stuff, worthy enough to know. It's not clear from your code whether your classes are in specific packages or in default package.
Putting your classes in specific packages is encouraged as it makes your code more readable and understandable.

But ....... good going by the way

Cheers.
Vishal

[Jhoel Esmejarda]

@Vishal Shaw

Package? uhmm.. I think I should finish first the Head First Java book, I'm stuck in Chapter 5 Extra-Strength Methods, I don't know yet the package but I will try to learn it bit by bit. Thanks with the comments.

[Vishal Shaw]

Jhoel Esmejarda wrote:@Vishal Shaw

Package? uhmm.. I think I should finish first the Head First Java book, I'm stuck in Chapter 5 Extra-Strength Methods, I don't know yet the package but I will try to learn it bit by bit. Thanks with the comments.

That is why I said it is a good practise, that is encouraged. You will learn it eventually. There are lot of pearls on the way, don't forget to collect them as you pass by

[Jhoel Esmejarda]

@Vishal Shaw

Yeah I hope I can understand it thoroughly. Thank you.

[Rajdeep Biswas]

Hi Jhoel,

Its encouraging that you are putting your efforts. I have not gone through your code completely but do have a small recommendation. Creating a lot of objects is not recommended, you know it. So, why create String objects again with same value.

For example, you wrote the following lines in more than one place:

System.out.println("IOException " + e);
System.out.println("Here's your " + prodName + "!");

So, you can introduce a constant file, like following:

public class VendingMachineConstants{
  public static final String EXCLAMATION = "!";
  public static final String HERE_IS_YOUR = "Here's your";
  public static final String BLANK_SPACE = " ";
  public static final String IO_EXCEPTION = "IOException";
}

This is just for example. And you could use these as follows:

System.out.println(VendingMachineConstants.IO_EXCEPTION + VendingMachineConstants.BLANK_SPACE + e);
System.out.println(VendingMachineConstants.HERE_IS_YOUR  + prodName + VendingMachineConstants.EXCLAMATION);

Remember, this just exemplifies, not justifies the requirement. So you have to decide and this way you're spared creating duplicate and used-in-many-places String objects. The same holds for other data types like "int" also.

Best wishes

[Vishal Shaw]

Rajdeep Biswas wrote:Hi Jhoel,

Its encouraging that you are putting your efforts. I have not gone through your code completely but do have a small recommendation. Creating a lot of objects is not recommended, you know it. So, why create String objects again with same value.

For example, you wrote the following lines in more than one place:

System.out.println("IOException " + e);
System.out.println("Here's your " + prodName + "!");

So, you can introduce a constant file, like following:

public class VendingMachineConstants{
  public static final String EXCLAMATION = "!";
  public static final String HERE_IS_YOUR = "Here's your";
  public static final String BLANK_SPACE = " ";
  public static final String IO_EXCEPTION = "IOException";
}

This is just for example. And you could use these as follows:

System.out.println(VendingMachineConstants.IO_EXCEPTION + VendingMachineConstants.BLANK_SPACE + e);
System.out.println(VendingMachineConstants.HERE_IS_YOUR  + prodName + VendingMachineConstants.EXCLAMATION);

Remember, this just exemplifies, not justifies the requirement. So you have to decide and this way you're spared creating duplicate and used-in-many-places String objects. The same holds for other data types like "int" also.

Best wishes

If that's the point , then instead of constant String objects , a properties file can serve the purpose better.
But as he is still in the beginning stage , so it's not required.

Now someone might suggest using a Design pattern for the same. Some might suggest to use a framework.As I said earlier, there's a lot more to learn , which he will eventually pick up on the way.
For now, he's doing a good job.

[Rajdeep Biswas]

Vishal Shaw wrote:there's a lot more to learn , which he will eventually pick up on the way.
For now, he's doing a good job.

And thats the point to all points here!

[Winston Gutkowski]

Jhoel Esmejarda wrote:The first one is the Menu Class...

Hi Jhoel. Glad to see you're still persevering (and also glad to see you took a couple of my previous suggestions on board ).

Right off the top, I think you would find things a lot easier if you add a Product class, probably with a name and price. That way, instead of two separate arrays to deal with, you have one, viz:

public class Menu {	
	private Product[] productArray = new Product[] {
		new Product("Coffee", 10.0),
		new Product("Milk", 15.0),
		new Product("Chocolate", 20.0)
	};
	...
}

In addition, you might also want to think about an Item class that describes an individual instance of a Product. So, if your Product is "Coffee", your Item is "a cup of Coffee". Maybe not wildly important at this stage, but it might save you some time later on.

second one is the Slot Class that gets your order and payment...

Now here's where you may have a problem. A "Slot" doesn't get your order or take a payment - or at least it shouldn't - it holds a Product (and probably several instances of the same Product (Items?)) and delivers one when told to. The vending machine itself is what gets your order and takes payments; and I still don't see a VendingMachine class.

Have you ever seen a vending machine with its front open?

Basically, it's a big mechanical monster with slots inside that hold product, and also an electronic keypad or a set of buttons that identify each slot. And that's the important part: they identify the Slot; NOT the Product it holds.
When the machine is being stocked, the service person puts a particular Product (and usually several of them) in each Slot, and then sets the price for the Slot according to what Product it contains. Next time the machine is re-stocked, Slot 1, that used to contain Milk, might this time contain Coffee, but if so, the service person has to change the price for Slot 1. For a Java program, I would simply associate a Slot with a Product, so that it temporarily acquires its name and price. This is commonly know as a HAS-A relationship (A Slot "has" a Product).

Also, just a general point: Classes should generally contain both methods AND data. Your Slot class doesn't contain any data, which suggests to me that you're concentrating too much on the procedure (the 'how') and not enough on behaviour (the 'what').

My suggestion: back up a bit and write down a description of each of your classes, and what it does, NOT how it does it. And do in English (or your native language), not in Java-ese.

Example: Vending Machine
WHAT IT IS: A machine that holds several products in numbered Slots, and delivers a single item to a customer upon receipt of (a) a choice of Product and (b) correct payment. It may also calculate and return change in case of an overpayment.
WHAT IT DOES: 1. Allows the customer to select a Product.
2. Detects if there is no more of the chosen Product (ie, the Slot is empty).
3. Determines correct payment, and accepts it.
4. Delivers a single item of the chosen Product.
5. (Optional) Returns change.

The above is a very simple example (and probably incomplete), but you should do this sort of thing with every class you write BEFORE you write a line of code for it.

Please help me with this, I don't have any formal training with programming nor a graduate of any computer course, I'm just studying by myself...

Don't worry, you're doing fine. Programming is NOT easy, so don't expect to 'get it' all at once.
The main piece of advice I would give you is this:
When you run into difficulties, STOP CODING.
Get out a pencil and lots of paper and write down what you're trying to do. Draw diagrams; think of scenarios; write out procedures step-by-step, but don't write them in Java.

Programming is about thinking, not coding; and you will never be able to solve a problem in Java if you can't describe it in English.

Phew. Quite a lot to digest there. Hope it isn't too much. Good luck.

Winston

[Jhoel Esmejarda]

Hi Winston,

Thanks for the post, actually I've been waiting for your comments . For now I will try my best to improve on things that you pointed out. Is there any book that you can recommend that can give me (as a beginner) a good start on things about Programming in Java?

[Winston Gutkowski]

Jhoel Esmejarda wrote:Thanks for the post, actually I've been waiting for your comments . For now I will try my best to improve on things that you pointed out. Is there any book that you can recommend that can give me (as a beginner) a good start on things about Programming in Java?

I believe you already mentioned you're using Head First Java which is a pretty good choice; however, it's mainly concerned with teaching you the mechanics of the language (and, from what I've heard, it does that very well).

What you have here is a design issue; and that really has nothing to do with Java (or at least, not a lot); and I'm afraid that most of the design books I read when I was starting out are probably old hat by now. However, some of the authors that were around in my time were Grady Booch, Donald Knuth, Edgar Dijkstra and Edgar Codd; and they all dealt with different aspects of design. I'd also suggest getting a copy of Design Patterns, which is the granddaddy of "design pattern" books.

The trouble with all the above is that they're mostly theoretical: they deal with design theory, when what you want is the answer to the question "How do I do this?". And I hate to say, but the answer is: slowly (unless you're an absolute genius).

Forget your program for a moment, and imagine you were designing a kitchen. What would you do?
Probably get an electrician in to see that you've got sufficient outlets; a plumber to make sure you've got enough water; possibly an architect or interior designer to make it look good and make sure it's going to last; maybe even (if you can afford it) a chef to suggest improvements for you; and lastly, a carpenter to actually build the darn thing.
But before all that, you have to have a "vision". You have to explain to all these 'techies' what you want - and the final result will depend almost entirely on how well you're able to describe your "vision" to them.

The same is true of programming, except that YOU are ALL of the above, so it's doubly important that you can describe your problem before you code (ie, start building). When you're coding, you're ONLY the carpenter; and a carpenter can't solve electrical problems.

I don't know if any of that above is any help, but trust me, coding is less than 20% of the average programmer's life. In fact, if I were God, I'd say that every programmer should have a statuette of The Thinker on their desktop.

Winston

[Junilu Lacar]

Winston Gutkowski wrote:WHAT IT IS ... WHAT IT DOES ... (and lots of other good stuff)

This is exactly what Jim Coplien says in his book "Lean Architecture." It's useful to think about what something is (its form) vs what it does (its structure) to be better able to separate the stable aspects from the more dynamic aspects of a system. Some of what Winston wrote under "IS" is actually "DOES" though. I would offer this refinement:

WHAT THE SYSTEM IS: A holder for Products. A dispenser of Products. An automated cashier.

WHAT THE SYSTEM DOES:
1. Contains products
2. Makes availability of product known to customer
3. Accepts money
4. Accepts choice of product input
5. Dispenses product
6. Returns change when appropriate
7. Returns money when appropriate

All of the above things that the system does can be combined in various ways to account for a number of use cases.

As Winston said, programming is about thinking. I like to say it this way:

Programming is about telling a story. Code is the programmer's interpretation of what the system should do, written as formal instructions that a computer can interpret and execute. Design is how the story is told and how the plot unfolds. As with any good story, well-crafted code should be engaging and help the reader understand exactly what the author was trying to say.

H. Abelson and G. Sussman (in "Structure and Interpretation of Computer Programs") wrote:Programs are meant to be read by humans and only incidentally for computers to execute.

Edit: BTW, Dijkstra's first name was Edsger

[Winston Gutkowski]

Junilu Lacar wrote:Some of what Winston wrote under "IS" is actually "DOES" though.

Quite right. I was never formally trained in this stuff; just acquired it by osmosis. But, to me, it's the process that's important: if you never stop to think about what you're doing, you're bound to make mistakes; and some of them may be BIG.

Edit: BTW, Dijkstra's first name was Edsger

Hey, we just called him 'Ed' (or 'Dijks'); hopefully, he never took offense.

Winston