# Best way to make my prog more OOP friendly

• (2 Pages)
• 1
• 2

## 29 Replies - 1788 Views - Last Post: 05 February 2013 - 10:38 AMRate Topic: //<![CDATA[ rating = new ipb.rating( 'topic_rate_', { url: 'http://www.dreamincode.net/forums/index.php?app=forums&module=ajax&section=topics&do=rateTopic&t=311072&amp;s=04bc6c4a8ed793f2aff493f5c0f2976c&md5check=' + ipb.vars['secure_hash'], cur_rating: 0, rated: 0, allow_rate: 0, multi_rate: 1, show_rate_text: true } ); //]]>

### #16 andrewsw

• I'm not here to twist your niblets

Reputation: 4509
• Posts: 16,578
• Joined: 12-December 12

## Re: Best way to make my prog more OOP friendly

Posted 04 February 2013 - 10:20 AM

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

### #17 tmcraig

Reputation: 0
• Posts: 10
• Joined: 01-February 13

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 01:10 AM

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;}
}

```

### #18 tmcraig

Reputation: 0
• Posts: 10
• Joined: 01-February 13

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 01:18 AM

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

### #19 tmcraig

Reputation: 0
• Posts: 10
• Joined: 01-February 13

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 01:36 AM

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

### #20 jjh08

Reputation: 55
• Posts: 198
• Joined: 13-July 12

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 01:47 AM

```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.

### #21 baavgai

• Dreaming Coder

Reputation: 6235
• Posts: 13,369
• Joined: 16-October 07

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 05:27 AM

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

public ShapesAreUs() {
}

// we show the menu more than once, so it's a method

// we ask the user for a choice
// make sure the choice returned is valid

private Shape getShapeFromUser() {
if (choice == 1){
System.out.println("What is a length of 1 side of the Square?\n");
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

### #22 jjh08

Reputation: 55
• Posts: 198
• Joined: 13-July 12

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 07:45 AM

Quote

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
}
```

### #23 andrewsw

• I'm not here to twist your niblets

Reputation: 4509
• Posts: 16,578
• Joined: 12-December 12

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 08:09 AM

@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

### #24 jon.kiparsky

• Pancakes!

Reputation: 8625
• Posts: 14,892
• Joined: 19-March 11

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 08:27 AM

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

### #25 jjh08

Reputation: 55
• Posts: 198
• Joined: 13-July 12

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 08:28 AM

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.

### #26 jjh08

Reputation: 55
• Posts: 198
• Joined: 13-July 12

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 08:34 AM

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.

### #27 jon.kiparsky

• Pancakes!

Reputation: 8625
• Posts: 14,892
• Joined: 19-March 11

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 09:03 AM

Quote

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.

### #28 baavgai

• Dreaming Coder

Reputation: 6235
• Posts: 13,369
• Joined: 16-October 07

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 09:34 AM

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.

### #29 jon.kiparsky

• Pancakes!

Reputation: 8625
• Posts: 14,892
• Joined: 19-March 11

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 10:25 AM

Quote

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

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.

### #30 baavgai

• Dreaming Coder

Reputation: 6235
• Posts: 13,369
• Joined: 16-October 07

## Re: Best way to make my prog more OOP friendly

Posted 05 February 2013 - 10:38 AM

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.