[andrewsw]

Mmm I think this would be more detailed than I first thought. I believe I was thinking of Homeomorphism:

Wiki

Quote

Roughly speaking, a topological space is a geometric object, and the homeomorphism is a continuous stretching and bending of the object into a new shape. Thus, a square and a circle are homeomorphic to each other, but a sphere and a donut are not.

So, in this world, a square would be the same as a circle. Mmm have to think about grouping them in a different way.. Maybe lines, blocks and curves, as indicated by jon?

This post has been edited by andrewsw: 04 February 2013 - 10:23 AM

[tmcraig]

just started to have another look at this, so should there be 3 class files? 1 for shape 1 for main and 1 for square? i have square extending Shape, and all sit in same package.

If i set it up as you have i get the below error

private Shape getShapeFromUser(double choice)

"illegal modifier for paremeter getShapeFromUser; only final is permitted."

also shape.getName() & shape.getArea() show "shape cannot be rsolved"

package areaprog;


import java.util.Scanner;



public class ShapesAreUs {

	
	public static void main(String[] args) {
		
	 private Shape getShapeFromUser(double choice){
			if (choice ==1){
				System.out.println("what is the length of 1 side of the square?\n");
				
			}
		
		}
		System.out.println("The area of your " + shape.getName() + " is: " + shape.getArea());
	}

}

package areaprog;

public class Shape {
	
class shape {
	 public String getName() {return "Shape";}
	 public double getArea() {return 0;}
	 		
	 
             }

}

package areaprog;

class Square extends Shape{
	private final double side; //only 1 property needed for this formula
	
	public Square(double side) {this.side = side;} //constructor
	
	public String getName() {return "Square";}
	public double getArea() {return this.side * this.side;}
}

[tmcraig]

ignore previous... me being a tit. i was putting the getShapeFromUser method in the main method.... like i said im new and still learning

Craig

[tmcraig]

think i will bang my head against the desk and go back to reading some books. I'm obviously messing up with the overall structure of it all.

Craig

[jjh08]

package areaprog;


import java.util.Scanner;



public class ShapesAreUs {

	
	public static void main(String[] args) {
		
	 private Shape getShapeFromUser(double choice){
			if (choice ==1){
				System.out.println("what is the length of 1 side of the square?\n");
				
			}
		
		}
		System.out.println("The area of your " + shape.getName() + " is: " + shape.getArea());
	}

}

You probably want to give getShapeFromUser() public access.

package areaprog;

public class Shape {
	
class shape {
	 public String getName() {return "Shape";}
	 public double getArea() {return 0;}
	 		
	 
             }

}

Why do you have a nested class called shape inside of public class Shape. In this case, you can probably remove it. The name is redundant anyway.

[baavgai]

In Java, you can't put methods in methods. Well, you can do strange anonymous things, but we aren't there yet. Be consistent in your indents and you'll see what's going on:

public class ShapesAreUs {
	// ok, entry point for program
	public static void main(String[] args) {
		// start of new method, but we're not done with the old one yet
		private Shape getShapeFromUser(double choice){
			if (choice ==1){
				System.out.println("what is the length of 1 side of the square?\n");
				
			}
		} // end getShapeFromUser, is would actually work
		// now we're kind of lost
		System.out.println("The area of your " + shape.getName() + " is: " + shape.getArea());
	}
}

I'd do the framework of your program like so:

package areaprog;

import java.util.Scanner;

public class ShapesAreUs {
	// we will try to kill as much static as possible
	// we also want main rather lean
	// let's make Mainprog an object
	
	// you only need one reader in your program
	private Scanner reader;
	
	public ShapesAreUs() {
		// init reader in constructor
		this.reader = new Scanner(System.in);
	}
	
	// we show the menu more than once, so it's a method
	private void showMenu() { /* your code here */ }
	
	// we ask the user for a choice
	// make sure the choice returned is valid
	private int menuChoice() { /* your code here */ }
	
	private Shape getShapeFromUser() {
		int choice = menuChoice();
		if (choice == 1){
			System.out.println("What is a length of 1 side of the Square?\n");
			double side = reader.nextDouble();
			return new Square(side);
		} else if (choice == 2) {
			// ...
		}
		return null;
	}
	
	public void run() {
		// with methods in place, the general logic of the program is simpilar to follow
		Shape shape = getShapeFromUser();
		// a null shape means they chose exit
		if(shape!=null) { 
			System.out.println("The area of you " + shape.getName() + " is: " + shape.getArea());
		}
	}

	public static void main (String [] args){
		// avoid static land
		// here we make an instance of ShapesAreUs and then call the method run
		new ShapesAreUs().run();
	}
}

Hope this helps.

This post has been edited by baavgai: 05 February 2013 - 05:27 AM

[jjh08]

Quote

Be consistent in your indents

Great point, baavgai. I didn't even notice that one myself because of the way the code is indented. When I study Java books, they always indent like this:

public static void main(String [] args){
//...do something
}

or

public class MyClass{
//...do something
}

However, the authors of the books I've read said that indenting in that manner allows them to save space and put more code on the page, but in reality, I believe its better to indent on the next line following the class or data member such as a method, initialization block, for loop, etc. Something like this:

public class MyClass
{
//...do something
}

or

public static void main(String [] args)
{
//...do something
}

[andrewsw]

@jjh08 I assume you meant to display the code as:

public class MyClass
{
    //...do something
}

I found this Oracle documentation but it hasn't been edited since 1999

[jon.kiparsky]

Quote

However, the authors of the books I've read said that indenting in that manner allows them to save space and put more code on the page... I believe its better to indent on the next line following the class or data member such as a method, initialization block, for loop,

Yes, the only reason for same-line opening braces - often called "K&R style" - is to reduce vertical space. This is much more important for a publisher, who can save a lot of money by cutting a few pages out of a book, than it is for live code.
The correct brace style - often called "Allman style" - puts the opening brace on the next line, aligned with the closing brace. This is correct for live code because it makes the structure of the code obvious, which is what you need. You should never have to worry about losing that line of vertical space because of some fundamental characteristics of methods. First, a method should never be longer than one screenful - if it is, you're doing something wrong, or more likely several things. Refactor that. (Really, one screenful is far too much for most methods - a method should do just one thing). Second, a method should be self-contained: you should not need to refer to anything else to understand this method. If this doesn't hold, then you're making your life more difficult than it needs to be. Third, a method should communicate its purpose clearly through its name and parameters. When I see a method call, I should be able to make a good, quick, and correct guess as to what I'm getting back, or what's going to happen, when I call that method. (needless to say, object names should also communicate well, so I should also be able to tell from the call what object is performing the action, and what its role in the whole business might be).

If all of those characteristics hold, saving a few lines in a method will never matter to you, so you can use the correct brace style. As an added bonus, following these rules will naturally limit your nesting, which will mean your block structure will be cleaner anyway.

This post has been edited by jon.kiparsky: 05 February 2013 - 08:29 AM

[jjh08]

andrewsw, on 05 February 2013 - 08:09 AM, said:

@jjh08 I assume you meant to display the code as:

public class MyClass
{
    //...do something
}

I found this Oracle documentation but it hasn't been edited since 1999 />

Yes, I was typing too fast.

[jjh08]

jon.kiparsky, on 05 February 2013 - 08:27 AM, said:

Quote

However, the authors of the books I've read said that indenting in that manner allows them to save space and put more code on the page... I believe its better to indent on the next line following the class or data member such as a method, initialization block, for loop,

Yes, the only reason for same-line opening braces - often called "K&R style" - is to reduce vertical space. This is much more important for a publisher, who can save a lot of money by cutting a few pages out of a book, than it is for live code.
The correct brace style - often called "Allman style" - puts the opening brace on the next line, aligned with the closing brace. This is correct for live code because it makes the structure of the code obvious, which is what you need. You should never have to worry about losing that line of vertical space because of some fundamental characteristics of methods. First, a method should never be longer than one screenful - if it is, you're doing something wrong, or more likely several things. Refactor that. (Really, one screenful is far too much for most methods - a method should do just one thing). Second, a method should be self-contained: you should not need to refer to anything else to understand this method. If this doesn't hold, then you're making your life more difficult than it needs to be. Third, a method should communicate its purpose clearly through its name and parameters. When I see a method call, I should be able to make a good, quick, and correct guess as to what I'm getting back, or what's going to happen, when I call that method. (needless to say, object names should also communicate well, so I should also be able to tell from the call what object is performing the action, and what its role in the whole business might be).

If all of those characteristics hold, saving a few lines in a method will never matter to you, so you can use the correct brace style. As an added bonus, following these rules will naturally limit your nesting, which will mean your block structure will be cleaner anyway.

Great insight, Jon. When the authors put that opening brace on the same line with the method, it makes me rage . All about the $$ LOL.

[jon.kiparsky]

Quote

All about the $$ LOL.

Well, it also makes the book a little more portable, which is nice. The right style for the right deployment, that's what we're after.

[baavgai]

jon.kiparsky, on 05 February 2013 - 10:27 AM, said:

Yes, the only reason for same-line opening braces - often called "K&R style" - is to reduce vertical space.
...
The correct brace style - often called "Allman style"

You're normally such a smart guy. And yet, here, you are so profoundly incorrect.

I've never seen Allman style style called the "correct brace style," though I have no doubt it can be found in less informed corners of the net. On the other hand, K&R is known far and wide as "the one true brace style."

I use this style not for printing ( you kill a tree, you fail ) but because it's so much easier to read.

In any case, the official Java docs prefer K&R. http://www.oracle.co...ons-141270.html

Also, NetBeans, the Java IDE from Oracle, defaults to it.

I'm afraid you've mistaken this for a C++ forum, where all the syntax sucks.

[jon.kiparsky]

Quote

You're normally such a smart guy. And yet, here, you are so profoundly incorrect.

Thank you, infidel dog. The depth of your error is distressing, but I admire your persistence.

Quote

I've never seen Allman style style called the "correct brace style,"

That's because it's not a convention, but a description. It's not called "correct", it's just correct.

Quote

I use this style not for printing ( you kill a tree, you fail ) but because it's so much easier to read.

I would love to read @baavgai's guide to writing proper code, dammit, by @baavgai. And I'd buy it in paper form, because you'd get better royalty, and because you can't really sign an electronic copy. And yes, I'd expect K&R braces on the printed copy.

But easier to read? Not at all. Visual cues allow you to offload the cognition to the layout. This means that you know the structure of the code before you start reading it, which makes it easier to get straight to the issues in the code. Correct braces provide better visual cues, hence, they're easier to read. Surely even a heretic and an infidel can see that?
There is a difference between persistence and mulish obstinacy!

Quote

Also, NetBeans, the Java IDE from Oracle, defaults to it.

Well, every program has its bugs.

[baavgai]

LOL

jon.kiparsky, on 05 February 2013 - 12:25 PM, said:

Correct braces provide better visual cues, hence, they're easier to read.

I couldn't agree more.