We Keep Coding

Having a method accept different objects as an argument

First I will just put my sample code.
public class Shape {
public String colour;
public Shape(String colour) {
this.colour = colour;
}
}
public class Car {
public String colour;
public Car (String colour) {
this.colour = colour;
}
}
public class Colour {
public static String getColour(Object item) {
return item.**colour**;
}
}
I've read other questions related to this, but I just can't seem to understand. I found their original code was just too complex for me to get around. So I tried to make as simple a code as possible. Anyway, I want getColour to accept both the Shape and Car object. If I use Object like I did in my example, the "colour" in bold is considered an error. The error I get is "colour cannot be resolved or is not a field". What's wrong?
Also, I've heard a lot of "static methods are bad" etc., is this a case of it being bad? Because I find if I don't make it static, then I need to duplicate getColour methods in both the Shape and Car classes. If I should avoid static methods, then please suggest another way to do this.

What you're looking for is the concept of interfaces:
public interface Colourable {
String getColour();
void setColour(String colour);
}
You should modify the Shape and Car classes:
public class Shape implements Colourable {
public Shape(String colour) {
this.colour = colour;
}
private String colour;
public String getColour() {
return colour;
}
public void setColour(String colour) {
this.colour = colour;
}
}
(note that I've made the colour field private; this is common practice and called encapsulation)
You can then define your static method as
public static String getColour(Colourable item) {
return item.getColour();
}
And static methods are definitely not bad, though in this case the method itself is a bit superfluous, because if you already have an Colourable, you know you can call .getColour() to get its color. A bit more useful would be the method
public static boolean isRed(Colourable item) {
return "red".equals(item.getColour());
}

You can "unify" Shape and Car. There are two general approaches:
Inheritance and
Interfaces
Let's look at both.
Inheritance: When a class Porsche inherits (or, in Java syntax, extends) a class Car, you establish an "is-a" relationship. In this case: Porsche is-a Car. Now, the magic comes to work, when you use object references. You can now write something like this:
Car c = new Porsche();
Since a Porsche has everything, a Car has (plus some things on top), you can see a Porsche as a Car (each Porsche is a Car, but not each Car is a Porsche). Reading my last sentence carefully, it is obvious, that the following does not work and, in fact, produces a compile error:
Porsche p = new Car();
What you can now do is write a method, that expects a Car and pass in a Porsche (since every Porsche is a Car).
Coming back to your example. To get this working, you could define a common parent class for Shape and Car, let's call it Colourable and give it a method public Colour getColour(). Then, you could simply change your getColour(Object item) method to getColour(Colourable c).
Remeber the thing I said about the "is-a" relation? Ask yourself: is each Shape a Colourable? Is each Car a Colourable? Why should Car and Shape both be in the same bucket (Colourable)? And what to do, if Car already has a parent class, e.g. Vehicle? This solution is sub-optimal.
Interfaces: This is, where interfaces come into play. Interfaces guarantee, that certain methods are present. Instead of defining a common parent class Colourable, you could simply write Colourable as an interface, containing the method public Colour getColour(). Now Shape and Car can implements this interface. This forces you to implement this method in both classes. The beauty: you can use interfaces just like classes. Meaning your implementation of getColour(Colourable c) does not need to change.
For more details, please read the provided tutorials on Inheritance and Interfaces.

Seems like your trying to use duck typing, which isn't how Java works.
The easiest thing to do, IMHO, would be to define an interface to handle the color. E.g.:
public interface Colourful {
public String getColour();
}
public class Shape implements Colorful {
private String colour;
public Shape(String colour) {
this.colour = colour;
}
#Override
public String getColour() {
return colour;
}
}
public class Car {
private String colour;
public Car (String colour) {
this.colour = colour;
}
#Override
public String getColour() {
return colour;
}
}
Alternatively, if you don't want to change Shape and Car, you could use reflection to extract the colour field, but this is usually considered a bad idea, and you'd probably be better off not using it:
public static String getColour(Object o) {
Field colourField;
try {
colourField = o.getClass().getField("colour");
} catch (NoSuchFieldException e) {
// No such field
return null;
}
Object colourValue;
try {
colourValue = colourField.get(o);
} catch (IllegalAccessException e) {
// The field isn't public
return null;
}
if (!(colourValue instanceof String)) {
// The field isn't a String
return null;
}
return (String) colourValue;
}

The reason an error is thrown is that Object doesn't have a colour field. I wouldn't recommend it, but if you want to move forward with this design, you could make a class called ShapeCarParent (used in this case because I see no clear relationship between the two) and have both the classes inherit from that, and then change getColour, like so:
public class ShapeCarParent{
public String colour;
}
public class Car extends ShapeCarParent
public class Shape extends ShapeCarParent
public class Colour {
public static String getColour(ShapeCarParent item) {
return item.colour;
}
}
This is still pretty poor style, so you can also use an interface which you then implement in each class.
public interface ColorProperties{
public String getColour();
}
public class Car implements ColorProperites{
public String getColour() {
return colour;
}
}
public class Shape implements ColorProperites{
public String getColour() {
return colour;
}
}
Hope this helps.

Is there a certain benefit in declaring an object using a class and assign it to another class?

During a Java course in my University we teach this example. While I certainly understand how this works, I fail to imagine a real life example where this practice might be useful. In my eyes it makes the code harder to understand. More specifically, is there a certain benefit in declaring an object using a class and assign it to another class (Small smallBig = new Big();) and can you give me a simple scenario where this practice might be useful?
The code:
public class Small {
public int value;
public Small() {value = 10;}
public int getValue() {return value;}
}
public class Big extends Small {
public int value;
public Big() {value = 40;}
public int getValue() {return value-10;}
}
public class Main {
public static void main (String args[]) {
Small small = new Small();
Small smallBig = new Big();
Big big = new Big();
System.out.println(small.getValue());
System.out.println(smallBig.getValue());
System.out.println(big.getValue());
System.out.println(small.value);
System.out.println(smallBig.value);
System.out.println(big.value);
small = (Small) big;
System.out.println(small.getValue());
System.out.println(small.value);
big = (Big) small;
System.out.println(big.getValue());
System.out.println(big.value);
}
}
The output:
10
30
30
10
10
40
30
10
30
40

Creating a method that operates on both Bigs and Smalls will help to illustrate the point better.
Assuming the same class definitions you already used in the question, you can create a method that prints both getValue() and value. Because Big extends Small, you need only one method.
public void printValues(Small val) {
System.out.println("getValue() == " + val.getValue());
System.out.println("value == " + val.value);
}
If you didn't have that relationship, and ability to assign Big objects to Small variables (remember: passing a value to a method is the same as assigning a variable), you'd need to have two different methods to handle this situation.
It helps to think of the extends keyword as meaning A Big is a more specific type of Small. In general, it's best to write methods that handle things using the least specific type that you can, because it will allow that method to handle situations you haven't even imagined yet.
For example, suppose that somewhere down the line, somebody decided to write
class Medium extends Small {
public Medium() {value = 20;}
public int getValue() {return value-5;}
}
The printValues() method can already handle this class, even though we didn't know about Mediums when we wrote it.

I think in this senario it'd be useful:
public class Person{
Mobility mobility;
Person(Mobility mobility){this.mobility = mobility;}
}
public class Mobility{
int speed;
public Mobility(int speed){this.speed = speed;}
}
public class Car extends Mobility{
public Car(int speed){super(speed);}
}
public class Main {
public static void main (String args[]) {
Car ferrari = new Car(1000);
Person john = new Person(ferrari);
}
}
Hope i could help you.

Well in this case you are using getValue as Template method "http://en.wikipedia.org/wiki/Template_method_pattern"
Let take you example with little twist
public class Small {
public int value;
public Small() {value = 10;}
public int getValue() {// this method fetches data from database}
}
public class Big extends Small {
public int value;
public Big() {value = 40;}
public int getValue() {//this method fetches data from xml}
public class Big2 extends Small {
public int value;
public Big() {value = 40;}
public int getValue() {//this method fetched data from some server}
}
As u can see the implementation of getValue is changing. Each sub class provides its own implementation of getValue.
Thus it gives my super class an opportunity to use different implementation of this method at run time (in you case). I Hope it makes it clear. Have a look at Template method pattern , you will get a better idea.

OO - Creating object using a method of no argument

I am experience some problems in understanding how the OO pattern works, My lecturer gave me the following question but I cannot solve it after thinking whole day
Scenario for my problems.
There is a class named "ShapeManager" which manages the Shape object. A class named "Shape" has two subclasses named "Circle" and "Rectangle"
The implementation of Shape class as follow
abstract public class Shape {
private String id;
private double length;
public Shape() {
}
public Shape(String id , double length) {
this.id = id;
this.length = length;
}
public void setID(String id) {
this.id = id;
}
public String getID() {
return id;
}
public void setLength(double length) {
this.length = length;
}
public double getLength() {
return length;
}
public abstract String getDetails();
}
The subclass Square as follow
public class Square extends Shape{
public Square() {
super();
}
public Square(String id , double side) {
super(id, side);
}
#Override
public String getDetails() {
return "Square => Id : "+getID() +", Side : "+ getLength() + ",Area : "+(getLength() * getLength());
}
}
The subclass Circle as follow
public class Circle extends Shape{
public Circle(){
super();
}
public Circle (String id, double radius) {
super(id, radius);
}
#Override
public String details() {
return "Circle => Id : "+getID() + ", Radius : "+ getLength() + ",Area: "+(3.14*(getLength() * getLength()));
}
}
The ShapeManager class as follow, this is not a completed class
public class ShapeManager {
public Shape createShape() {
}
public void updateLength(String id ){
}
public void deleteShape(String id) {
}
public void listShapes() {
}
}
ShapeManager have an association with Shape
ShapeManager --1------0..*--> Shape
The design of this package (All the classes above) can not be changed, implementation must be following OCP (Open-Closed Principle).
My question is: How am I suppose to complete createShape method? Without parameter, it is seemingly impossible to create an object either a Rectangle or Circle.

ShapeManager cannot create a shape if not knowing what this shape is (Square, Circle or something else). And it really doesn't know because you say the method createShare has no parameters. Either you misunderstood the question or the lecturer didn't explain it well. You should ask him/her for clarifications. If you look at the libraries of Java or any other OO language, I am pretty sure you won't find such scenario and implementation pattern as the one you gave in your example.
#croraf
You should find some other reading I think e.g. the classic book http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612. The main idea of a factory is that it returns something whose type the caller doesn't know, and doesn't care about. For example, if you have a method createSocket() in some SocketFactory, this method is usually defined to return an interface or an abstract class Socket. But actually it returns new SocketImpl1() and new SocketImpl2() which are concrete classes. What the factory returns may depend on many things - a system property, the underlying OS, anything you can think of. The main idea is that the factory centralizes the creation of Socket objects at one single place. This way, if you need to make a change, you can make it just in the factory. I think this book also has some decent Java counterparts too, you may look around. Other free good sources are referenced here.
Real world examples of Factory Method pattern

I think you should have something like this, similar to how BorderFactory from java API works.
public class ShapeManager {
public Shape createCircle() {
...
return Circle;
}
public Shape createSquare() {
....
return Square;
}
...
public void updateLength(String id ){
}
public void deleteShape(String id) {
}
public void listShapes() {
}
}

You can't create shape without knowing type which shape would You like to create. You can define enumeration for types and pass the type value to the createShape(). And there You can switch between types and create the concrette shape You want.

For me, Its classic Factory pattern.
public class ShapeFactory {
public abstract Shape getShape(int shapeId);
}
public interface Const {
public static final int SHAPE_CIRCLE =1;
public static final int SHAPE_SQUARE =2;
}
public class SimpleShapeFactory extends ShapeFactory throws BadShapeException {
public Shape getShape(int shapeTypeId){
Shape shape = null;
if(shapeTypeId == Const.SHAPE_CIRCLE) {
//in future can reuse or cache objects.
shape = new Circle();
}
else if(shapeTypeId == Const.SHAPE_SQUARE) {
//in future can reuse or cache objects
shape = new Square();
}
else throw new BadShapeException("ShapeTypeId="+ shapeTypeId);
return shape;
}
}
Calling:
ShapeFactory factory = new SimpleShapeFactory();
//returns a Shape but whether it is a Circle or a
//Square is not known to the caller.
Shape s = factory.getShape(1);
s.getDetails(); // circle details called
//returns a Shape but whether it is a Circle or a
//Square is not known to the caller.
s = factory.getShape(2);
s.getDetails(); //Square details called
References:
The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged.

instantiating a class from array of interfaces

SEE THE EDIT HALFWAY DOWN THE POST.
I'm new to java and all the formal declarations of inheritance are getting me a little confused.
I have a interface like so:
public interface A{
public void one();
public void two();
}
and then I have two classes like so:
public class B implements A{
private int num;
public void one(){
...
}
public void two(){
...
}
public B(){
this.num = 1;
}
}
public class C extends B{
public C(){
super();
}
}
then I have a driver class like so:
public class Driver{
public static void main(String [] args){
A a_array[] = new A[5];
for(int i=0; i<6; i++){
if(i%2==0){
a_array[i] = new B();
}
else{
a_array[i] = new C();
}
}
}
}
Basically, given an array of interfaces I am trying to implement various classes that implement that interface.
Now my guess is there are several things wrong with this implementation, but I seem unable to sniff them out. Primarily right now I am getting the error 'B() is not abstract and does not implement method one()'.
EDIT:
alright lets try this...
the interface:
public interface Shape{
public double calcAread();
public double calcPerimeter();
}
the implementing class:
public class Rectangle implements Shape{
private double length;
private double width;
public double calcArea(){
return this.length*this.width;
}
public double calcPerimeter(){
return (this.length*2)+(this.width*2);
}
public Rectangle(double length, double width){
this.length=length;
this.width=width;
}
// then some other methods including the set methods
}
the extending class:
public class Square extends Rectangle{
public Square(){
super();
}
public Square(double sideLength){
super.setLength(sideLength);
super.setWidth(sideLength);
}
// some more methods
}
I can't think of very much more that would be useful other than to mention that there are other inheriting and extending classes off of these but they follow exactly the same design and sentax.
No errors when I compile shape, but the 'Rectangle is not abstract and does not override abstract method calcAread() in Shape' error is tripped when I compile the Rectangle class.
Hopefully this will be more enlightening.
Thanks

the only problem I see in the code is that the i<5 instead if i<6. array size is 5 and the initialization is set to i=0. (loop iterations should be 0,1,2,3,4, otherwise u will get ArrayIndexOutOfBound exception)
I compiled the code and its running fine.

What you've provided as example code will work just fine. My suspicion is that your exact code and your example code differ.
Without seeing the exact error message and B class it's hard to say, but I'm willing to bet you have either a return value or parameter difference between the definition of one in your interface and your one in your implementation.
Edit: Here's what I see as the problem. Your interface's method is called "calcAread". Is that d supposed to be on the end?
public double calcAread();
Because it's missing inside Rectangle
public double calcArea()
That's going to cause a problem. It makes me wonder how #Zohaib managed to compile it actually!

Java overloading vs overriding

Hi I just want to make sure I have these concepts right. Overloading in java means that you can have a constructor or a method with different number of arguments or different data types. i.e
public void setValue(){
this.value = 0;
}
public void setValue(int v){
this.value = v;
}
How about this method? Would it still be considered overloading since it's returning a different data type?
public int setValue(){
return this.value;
}
Second question is: what is overriding
in java? Does it relate to inheritance. Let's I have the following:
public class Vehicle{
double basePrice = 20000;
//constructor defined
public double getPrice(){
return basePrice;
}
}
public class Truck extends Vehicle{
double truckPrice = 14000;
//constructor defined
public double getPrice(){
return truckPrice;
}
}
So now let's say I have the following
Truck truck = new Truck();
if I call
truck.super.getPrice()
this would return the price from the Vehicle class, 20,000
if I call
truck.getPrice()
this would return the price in the truck class, 14,000
Is my knowledge correct for both questions?

You are basically correct. Overloading is having multiple methods in a single class where the method has the same name. However, the return value is not seen as part of the signature of the method. Thus, you cannot overload a method by changing only the return value. You cannot have the following code, from your example:
public void setValue() {
this.value = 0;
}
public int setValue() {
return this.value;
}
This will fail to compile.
As Rob identified, I believe you mean overriding, and you have that correct. Note with overriding, you cannot change the return type. As of Java 5, you can return a derived type of what the base class method returned. Before Java 5, it must be the identical type. That is, you cannot do the below until Java 5 and later:
public class AnimalNoise {}
public class Miaw extends AnimalNoise {}
public class Animal {
public AnimalNoise makeNoise() {
return new AnimalNoise();
}
}
public class Cat extends Animal {
public Miaw makeNoise() {
return new Miaw ();
}
}
However, even in Java 5 and later, you cannot do the following:
public class Animal {
public String makeNoise() {
return "silence";
}
}
public class Cat extends Animal {
public Miaw makeNoise() {
return new Miaw ();
}
}
public class Miaw {}
Finally, a big difference between overloading and overriding that is often overlooked is that overloading is decided at compile time and overriding is decided at runtime. This catches many people by surprise when they expect overloading to be decided at runtime.

Correct; overloading is providing multiple signatures for the same method.
Overriding, which is what I think you mean by "overwriting" is the act of providing a different implementation of a method inherited from a base type, and is basically the point of polymorphism by inheritance, i.e.
public class Bicycle implements Vehicle {
public void drive() { ... }
}
public class Motorcycle extends Bicycle {
public void drive() {
// Do motorcycle-specific driving here, overriding Bicycle.drive()
// (we can still call the base method if it's useful to us here)
}
}

what you have described is correct.
For more clarification take a look at polymorphism concept. The Wikipedia has a good article
http://en.wikipedia.org/wiki/Polymorphism#Computing
http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming