Quick Java method question

[Satlen]

Hello folks, I am writing a program in java and I was wondering if I had a object inside of another object, can I call that objects method from my main function without creating 2 get methods?

 

For example:

 

main()

new shape

--->shape

     new square

------>square

        getArea

 

Am I able to call getArea from main without having another getArea in shape?

 

Thanks in advance!

[madknight3]

Not unless you were going to make getArea static or square public

// if staticsquare.getArea()// if publicshape.square.getArea()

[Guest]

If, for some reason, the square class is defined inside the shape class, you can simple call square's getArea method from the shape's getArea method. This isn't good design, though.

[madknight3]

This is usually the type of thing that you use a base class for. Instead of the Shape class containing multiple types of shapes, it would be an interface or abstract class that defines functionality that the child classes inherits/implements.

 

For example:

public interface Shape {    double getArea();}public class Square implements Shape {    // ...    @[member='OverRide']    public double getArea() {        // ...    }}

Of course you can do it however you want to.

[Satlen]

This is usually the type of thing that you use a base class for. Instead of the Shape class containing multiple types of shapes, it would be an interface or abstract class that defines functionality that the child classes inherits/implements.

 

For example:

public interface Shape {    double getArea();}public class Square implements Shape {    // ...    @[member=OverRide]    public void getArea() {        // ...    }}

Of course you can do it however you want to.

 

Yeah, the shape and square thing was just a thing I made up real quick. I was just curious to if and how you could call a method from a class inside another class. Thanks!

[Guest]

This is usually the type of thing that you use a base class for. Instead of the Shape class containing multiple types of shapes, it would be an interface or abstract class that defines functionality that the child classes inherits/implements.

 

Just some design philosophy here; an interface is often used to define shared peripheral behavior that is not necessarily fundamental to the base class. In this case, all shapes have area, and moreover it would probably be desirable to enforce that all shapes have a getArea method. It makes more sense in this case to have the getArea method on an abstract shape class, thereby forcing all shapes to implement it. With the interface, there is no requirement for a concrete shape class to have the method.

[Satlen]

Just some design philosophy here; an interface is often used to define shared peripheral behavior that is not necessarily fundamental to the base class. In this case, all shapes have area, and moreover it would probably be desirable to enforce that all shapes have a getArea method. It makes more sense in this case to have the getArea method on an abstract shape class, thereby forcing all shapes to implement it. With the interface, there is no requirement for a concrete shape class to have the method.

Well, my situation was that I had an object creating another object from another class inside an if statement. So the object is not always used hence why it is not implemented. Sort of like radius, not every shape has a radius, but circles do. How would you go about it in this situation?

[Guest]

Well, my situation was that I had a class creating an object from another class inside an if statement. So the object is not always used hence why it is not implemented. Sort of like radius, not every shape has a radius, but circles do. How would you go about it in this situation?

 

It's a matter of semantics. A circle is a special kind of ellipse where the width and height are equal, just as a square is to a rectangle. So the circle would not need to be different than any other two dimensional shape.

[madknight3]

Just some design philosophy here; an interface is often used to define shared peripheral behavior that is not necessarily fundamental to the base class. In this case, all shapes have area, and moreover it would probably be desirable to enforce that all shapes have a getArea method. It makes more sense in this case to have the getArea method on an abstract shape class, thereby forcing all shapes to implement it. With the interface, there is no requirement for a concrete shape class to have the method.

 

In the languages I'm used to (Java and C#) interfaces also force implementation. For example If I remove the overridden method in my above example I get this error

Error:(6, 8) java: Square is not abstract and does not override abstract method getArea() in Shape

If I use an abstract class with an abstract method like so, this also requires that things be implemented or I get the same error.

public abstract class Shape {    public abstract double getArea();}public class Square extends Shape {    @[member='OverRide']    public double getArea() { // wont compile if removed        // ...    }}

However, if inside the abstract class I define getArea, something you can't do with an interface, then I don't need to override the method.

public abstract class Shape {    public double getArea() {        // ...    }}public class Square extends Shape {    // compiles fine    // while still giving choice to override getArea}

In this particular case, unless you wanted to implement some functionality in Shape it probably doesn't matter if you use an abstract class or an interface.

[Guest]

In the languages I'm used to (Java and C#) interfaces also force implementation. For example If I remove the overridden method in my above example I get this error

 

In this particular case, unless you wanted to implement some functionality in Shape it probably doesn't matter if you use an abstract class or an interface.

 

Yes, the interface forces you to implement the methods it defines. However, there is no obligation to implement the interface itself in the first place. I can define new shape classes all day long and none of them need to have a getArea method.

 

However, if I'm working with a system that expects a generic Shape class, then I'm forced to subclass shape as well as implement any abstract methods defined in Shape.

 

Of course, it's possible to combine both methods; an abstract class can implement an interface, forcing concrete subclasses to do the heavy lifting.

[Satlen]

Okay, so to steer away from the shape example for a sec, here is my current assignment I am working on (forgive me if there is bad code, still learning):

 

https://gist.github.com/Nynjah/61d32c32ea40bd3fc1b0

 

In the trip class, I only create a lodge object if the trip is longer than 1 day. Would there be a better way of implementing this? 

[madknight3]

Yes, the interface forces you to implement the methods it defines. However, there is no obligation to implement the interface itself in the first place. I can define new shape classes all day long and none of them need to have a getArea method.

 

However, if I'm working with a system that expects a generic Shape class, then I'm forced to subclass shape as well as implement any abstract methods defined in Shape.

 

Of course, it's possible to combine both methods; an abstract class can implement an interface, forcing concrete subclasses to do the heavy lifting.

 

Hmm, I'm not sure I understand. If I try adding another shape class to my project that already has a shape interface then the compiler wont build because of a duplicate class error.

 

So I'm not sure how you could define new shape classes.

[Guest]

Hmm, I'm not sure I understand. If I try adding another shape class to my project that already has a shape interface then the compiler wont build because of a duplicate class error.

 

So I'm not sure how you could define new shape classes.

 

Meaning new classes that are shapes, not a Shape class. For example Square, Rectangle, Ellipse, and so on.

[madknight3]

Meaning new classes that are shapes, not a Shape class. For example Square, Rectangle, Ellipse, and so on.

 

But couldn't you also ignore an abstract class too? What would require a class, like square, to extend the shape abstract class that wouldn't make it also require an interface?

[Guest]

But couldn't you also ignore an abstract class too? What would require a class, like square, to extend the shape abstract class that wouldn't make it also require an interface?

 

Let's imagine I'm writing some kind of graphics program. For the sake of simplicity, let's say there is some controller class that sends a rendered image to the screen. I define this class so that I can give it various shapes to draw, circles, squares, and so on. Furthermore, I define the class so that it will only accept object instances that are subclasses of the abstract Shape. This ensures that anything that the controller class tries to render will have the necessary methods.

 

Obviously, this is more contractual than actual "enforcement". But it makes for easier development if the API is clear, especially if the code will be reused or used and by developed by different people. You're hopefully catching these things at compile time rather than runtime.

[madknight3]

Furthermore, I define the class so that it will only accept object instances that are subclasses of the abstract Shape. This ensures that anything that the controller class tries to render will have the necessary methods.

 

How would you only accept subclasses of the abstract class? I agree that it makes more sense to use an abstract class in this example, however I don't see why you couldn't use an interface if you really wanted to.

 

If for example you had a method that accepted a Shape class like so

public class Controller {    // ...    public void RenderToScreen(Shape s) {        // ...    }}

Then the class we pass into it would have to be a child of Shape, however there's nothing stopping Shape from being an interface over an abstract class here. It would still make the child class have all the required methods.

[Guest]

How would you only accept subclasses of the abstract class? I agree that it makes more sense to use an abstract class in this example, however I don't see why you couldn't use an interface if you really wanted to.

 

If for example you had a method that accepted a Shape class like so

public class Controller {    // ...    public void RenderToScreen(Shape s) {        // ...    }}

Then the class we pass into it would have to be a child of Shape, however there's nothing stopping Shape from being an interface over an abstract class here. It would still make the child class have all the required methods.

 

Sure you could, if you wanted. Mainly a style thing, I guess. If Shape were an interface in your example, seems like calling it specifically a Drawable or something would be more in line with the use philosophy of an interface.

[madknight3]

Sure you could, if you wanted. Mainly a style thing, I guess. If Shape were an interface in your example, seems like calling it specifically a Drawable or something would be more in line with the use philosophy of an interface.

 

Ok, I just wanted to make sure I wasn't misunderstanding some functionality difference between an abstract class and an interface.

 

I can certainly learn more when it comes to the design philosophy of the topic though.

 

Okay, so to steer away from the shape example for a sec, here is my current assignment I am working on (forgive me if there is bad code, still learning):

 

https://gist.github.com/Nynjah/61d32c32ea40bd3fc1b0

 

In the trip class, I only create a lodge object if the trip is longer than 1 day. Would there be a better way of implementing this? 

 

Sorry for the derail. The current set up seems fine if you plan to add more functionality to the Lodge class. Otherwise it's a simple enough function to implement as a static method so you don't need to create an object to run the calculation.

[Guest]

Okay, so to steer away from the shape example for a sec, here is my current assignment I am working on (forgive me if there is bad code, still learning):

 

https://gist.github.com/Nynjah/61d32c32ea40bd3fc1b0

 

In the trip class, I only create a lodge object if the trip is longer than 1 day. Would there be a better way of implementing this? 

 

This is an interesting question. It would definitely be preferable if you can avoid instantiating the Lodge class inside the Trip class. Aside from the fact that it is going to be unneeded code for any trip less than a day, it's best practice to delegate object instantiation outside of the client class. At the minimum, I would declare the Lodge class instance outside of your Trip class method and pass it as an argument. This would be useful because you can define multiple types of Lodge, for example RegularLodge and PremiumLodge, which is more elegant than passing a boolean to the Lodge constructor.

 

As to your main question, how to calculate the lodging cost, if you stay 0 days somewhere, the lodging cost will still be zero. 0 days * $10 = $0. It works out the same whether you evaluate the equation or not, so you don't need the conditional.

class Trip {  public function getTripCost(Lodge lodge) {    return lodge.getLodgeCost();  }}// In use, assume someTrip is defined elsewhere:someTrip.getTripCost(new PremiumLodge(someTrip.days));  

[Satlen]

Sorry for the derail. The current set up seems fine if you plan to add more functionality to the Lodge class. Otherwise it's a simple enough function to implement as a static method so you don't need to create an object to run the calculation.

Yeah, this is just for an assignment, so I am not worried too much about it.

 

This is an interesting question. It would definitely be preferable if you can avoid instantiating the Lodge class inside the Trip class. Aside from the fact that it is going to be unneeded code for any trip less than a day, it's best practice to delegate object instantiation outside of the client class. At the minimum, I would declare the Lodge class instance outside of your Trip class method and pass it as an argument. This would be useful because you can define multiple types of Lodge, for example RegularLodge and PremiumLodge, which is more elegant than passing a boolean to the Lodge constructor.

 

As to your main question, how to calculate the lodging cost, if you stay 0 days somewhere, the lodging cost will still be zero. 0 days * $10 = $0. It works out the same whether you evaluate the equation or not, so you don't need the conditional.

I actually just made that change before you posted as I finally realized it would be a good idea to have it as an argument like my automobile. Also, nice catch on the if statement.

 

Thanks guys!