Results 1 to 8 of 8
  1. #1
    johto760 is offline Member
    Join Date
    Oct 2010
    Posts
    3
    Rep Power
    0

    Default Methods that are NOT defined in interface

    Hello To all.

    Why can't other methods (in this case the main method) call a myMethod() that is NOT defined in an interface implemented by a class, where the class that implements it have such a method: myMethod() here's my code:

    Java Code:
    //This is the Interface
    public interface [COLOR="#808000"]TileCollection [/COLOR]{
    	public void setTile(Tile myTile);
    	public Tile getTile(int i);
    }
    The upper code shows the interface I'm talking about

    Java Code:
    //Here's the Class that implements TileCollection,
    public class [COLOR="Olive"]TacTileCollection[/COLOR] implements TileCollection{
    
    	private ArrayList<Tile> myTiles = new ArrayList<Tile>();
    
    	@Override
    	public void setTile(Tile myTile) {
    		// TODO Auto-generated method stub
    		this.myTiles.add(myTile);
    	}
    
    	@Override
    	public Tile getTile(int i) {
    		// TODO Auto-generated method stub
    		return this.myTiles.get(i);
    	}
    	
               // Here's the method that is not defined in the interface
    	public void myMethod(){
    		System.out.println("myMethod");
    	}
    }
    The code above is the class implementing the interface above it
    Java Code:
    //Here's my main method
    public static void main(String[] args) {
    		// TODO Auto-generated method stub
    		Tile myTile = new TacTile();
    		TileCollection myTiles = new TacTileCollection();
    		myTiles.setTile(myTile);
    		myTiles.[COLOR="Red"]myMethod()[/COLOR];
    	}
    }
    I'm using Eclipse, here's the error: The method myMethod() is undefined for the type PlayerCollection

    I've been at this for hours now. ^_^,, thanks for taking the time...
    Last edited by johto760; 10-27-2010 at 12:13 PM.

  2. #2
    j2me64's Avatar
    j2me64 is offline Senior Member
    Join Date
    Sep 2009
    Location
    Zurich, Switzerland
    Posts
    962
    Rep Power
    5

    Default

    Quote Originally Posted by johto760 View Post
    I'm using Eclipse, here's the error: The method myMethod() is undefined for the type PlayerCollection

    first of all there is no Tile class, so all statements that receference the class Tile produce an error like "Tile cannot be resolved to a type". now to your myMethod() problem: when you instatiate your myTiles with

    TileCollection myTiles = new TacTileCollection();

    then myTiles can see only members of the interface in TileCollection and not those in the TacTileCollection. comprende?

  3. #3
    Fubarable's Avatar
    Fubarable is offline Moderator
    Join Date
    Jun 2008
    Posts
    19,316
    Blog Entries
    1
    Rep Power
    25

    Default

    The variable, myTiles is a TileCollection variable, and even though it references a TacTileCollection object, the only visible methods for this variable are the methods declared in the TileCollection interface. You can use the TacTileCollection if you first cast the variable as a TacTileCollection object, but if you have to do this, it may give your code a bad smell suggesting that a redesign is in order.

  4. #4
    johto760 is offline Member
    Join Date
    Oct 2010
    Posts
    3
    Rep Power
    0

    Default New Design

    Quote Originally Posted by Fubarable View Post
    The variable, myTiles is a TileCollection variable, and even though it references a TacTileCollection object, the only visible methods for this variable are the methods declared in the TileCollection interface. You can use the TacTileCollection if you first cast the variable as a TacTileCollection object, but if you have to do this, it may give your code a bad smell suggesting that a redesign is in order.
    Thanks for spotting the redesign issue, I figured to use an interface that extends the "TileCollection" interface that contains "myMethod()", so whenevery I need an object to use "myMethod()" I could instantiate that object with this new interface:


    Java Code:
    public interface TileCollAddOn extends TileCollection{
           public void myMethod();
    }
    Java Code:
    //The TacTileCollection would look like:
    public class TacTileCollection implements TileCollAddOn{
    
    	private ArrayList<Tile> myTiles = new ArrayList<Tile>();
    
    	@Override
    	public void setTile(Tile myTile) {
    		// TODO Auto-generated method stub
    		this.myTiles.add(myTile);
    	}
    
    	@Override
    	public Tile getTile(int i) {
    		// TODO Auto-generated method stub
    		return this.myTiles.get(i);
    	}
    	
               // This would be visible if I were to use the TileCollAddOn interface..
    	public void myMethod(){
    		System.out.println("myMethod");
    	}
    }
    Java Code:
    // the main would look like:
    public static void main(String[] args){
           TileCollAddOn myTiles = new TacTileCollection();
    }
    I don't want to have to downcast every TileCollection that comes along the way, so I'm just going to have to use TileCollAddOn to interface with main whenever I need a new TileCollection Object... (let's just assume that I've written a Tile object with a proper interface, which I have ^_^)

    could this somehow be the "redesign" you were looking for?

  5. #5
    tashimoto is offline Member
    Join Date
    Sep 2010
    Location
    Oregon, usa
    Posts
    69
    Rep Power
    0

    Default

    I'm not experienced with implementing interfaces, and your posts have brought up many questions for me. I was able to figure out most from this link: Interfaces (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance) (for others that have questions about interfaces, too :) ); but I still have one question that I haven't yet found the answer to:

    why do you instantiate the myTiles object like this:
    Java Code:
    TileCollAddOn myTiles = new TacTileCollection();
    instead of like this:
    Java Code:
    TacTileCollection myTiles = new TacTileCollection();

  6. #6
    Singing Boyo is offline Senior Member
    Join Date
    Mar 2009
    Posts
    552
    Rep Power
    6

    Default

    I'll speculate that there's really no reason, other than the tendency of those of us programming with interfaces frequently to use the interface rather than the class as the variable type. Interfaces are an abstraction over the implementation.

    Most design strategies that involve a large number of interfaces also include factory classes, so that you can have one place where you instantiate objects, and if you change the implementation class for the interface, or add the ability to use different implementations, your 153 other places where you use the interface don't change.

    So, if I have a Tile interface, a TileImpl class, and a TileFactory class with a method for creating TileImpls, then everywhere I need a tile, I can call TileFactory.getNewTile(). Then, if for some reason I need a new implementation but want to keep my old Tile implementation, I can add a NewTileImpl class and change my factory method (getNewTile) to return a NewTileImpl instead of a TileImpl. A lot easier than going through all my code making it create NewTileImpl objects instead of TileImpl objects.
    If the above doesn't make sense to you, ignore it, but remember it - might be useful!
    And if you just randomly taught yourself to program, well... you're just like me!

  7. #7
    johto760 is offline Member
    Join Date
    Oct 2010
    Posts
    3
    Rep Power
    0

    Default because of design patterns

    Quote Originally Posted by tashimoto View Post
    I'm not experienced with implementing interfaces, and your posts have brought up many questions for me. I was able to figure out most from this link: Interfaces (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance) (for others that have questions about interfaces, too :) ); but I still have one question that I haven't yet found the answer to:

    why do you instantiate the myTiles object like this:
    Java Code:
    TileCollAddOn myTiles = new TacTileCollection();
    instead of like this:
    Java Code:
    TacTileCollection myTiles = new TacTileCollection();


    I don't know a lot of patterns yet, but what I do know is that there are rules in Design Patterns suggesting that:

    1.) I design to an interface, and
    2.) Favor aggregation over inheritance,

    basically, I don't let Client Objects (in this case the one with the main method) know that there is actually an object implementing/deriving from an interface/abstract class, I normally use a Factory Class to handle the instantiation, but I figured I just make it so that I directly reference a "new TacTileCollection()", so that I wouldn't have to explain why there is a Factory class in there.

    I can't exactly explain it more than this book: Design Pattern Explained: A New Perspective on Object Oriented Design Second Edition by: By Alan Shalloway, James R. Trott,

  8. #8
    tashimoto is offline Member
    Join Date
    Sep 2010
    Location
    Oregon, usa
    Posts
    69
    Rep Power
    0

    Default

    Many thanks to you both for your explanations! I will ponder over them and check out that book, too! :)

    Chris

Similar Threads

  1. JAVA_HOME is not defined correctly.
    By mail2vs.dvg1 in forum Advanced Java
    Replies: 2
    Last Post: 06-08-2010, 05:08 PM
  2. User Defined Method
    By overcranked in forum New To Java
    Replies: 6
    Last Post: 04-09-2010, 01:02 AM
  3. JSP with user-defined java classes
    By adammyth in forum JavaServer Pages (JSP) and JSTL
    Replies: 2
    Last Post: 03-05-2010, 06:13 PM
  4. Accessing class defined within a constructor
    By kwaspl in forum New To Java
    Replies: 4
    Last Post: 12-21-2009, 02:35 PM
  5. Why methods in an interface cannot be static?
    By cbalu in forum Advanced Java
    Replies: 2
    Last Post: 12-12-2007, 07:57 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •