Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  About lists and the elements inside of them.  (Read 520 times)
0 Members and 1 Guest are viewing this topic.
Offline EliwoodL

Senior Newbie





« Posted 2013-07-09 05:51:45 »

So I have a List of Component.java, right?  Inside of this list, I want to store a few types of classes all of which extends the Component.java class.  See, that part I can do just fine.  At present, I'm storing Wire.java's and Pipe.java's.

However, when it comes to accessing the different types inside of the list, I'm faced with a dilemma.

First I tried it like this:  for (Wire w : component_list)
However, it can't iterate over only a single type of component inside of the list; it's looking for Wires when the iterator only knows to return Components.

Seeing this, I tried:

for (Component c : component_list) {
     if (c.equals(Wire.class)) {
          Wire w = (Wire) c;
     }
}

However, I'm not sure that it's working properly.  I'm wondering, is the second option possible?
Offline Longarmx
« Reply #1 - Posted 2013-07-09 06:06:59 »

You can use
1  
2  
3  
if(c instanceof Wire){

}

Offline EliwoodL

Senior Newbie





« Reply #2 - Posted 2013-07-09 06:51:59 »

Ahh, thank you very much.  This helps me enormously!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline StrideColossus
« Reply #3 - Posted 2013-07-12 11:20:58 »

Depending on what you're doing with your custom components when you're iterating over them an alternative is to have your classes implement an interface with the operations that you want to perform on them, i.e.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
interface MyCustomInterface {
     void whatever();
}

class MyCustomComponent extends Component implements MyCustomInterface {
    void whatever() { ... }
}

...

List<MyCustomInterface> list = ...

for( MyCustomInterface c : list ) {
    c.whatever();
}


The interface is a sort of adaptor pattern, meaning you get more readable code and no nasty casting.

You could also insert an extra layer with an abstract base class if required.
Offline EliwoodL

Senior Newbie





« Reply #4 - Posted 2013-07-12 16:45:13 »

That's actually a very good tip.  However, isn't it sort of misleading when you're going through the interfaces for each component type rather than the actual object itself?

Also, I've abandoned that method of components for now and instead have a basic VoxelGroup class that has an enum of GroupTypes to determine how it should behave (Another class entirely).  The list of voxels from before is non-existant

With that in mind, would your interface method still work properly?  Or should I change my architecture slightly to accomodate?

And the idea of an abstract base class; would that replace the VoxelGroup class, and then I would create multiple classes for different types of groups, all of which would use an interface for commonly needed methods - that about sum it up?
Offline StrideColossus
« Reply #5 - Posted 2013-07-21 09:31:23 »

That's actually a very good tip.  However, isn't it sort of misleading when you're going through the interfaces for each component type rather than the actual object itself?

It's an example of separation of concerns: the code that is doing the iterating and invoking the method on the interface doesn't care what the actual objects are - this is of polymorphism.

Therefore that code loop is now completely independent of any specifics about your classes that implement that interface.  Thus:

- there are no dependencies between that bit of code and any of your component classes: simpler, cleaner code that is more maintainable.

- you can add (or delete) components without having to change that code.

- you can change the behaviour of those components and that code will still work.

Quote
Also, I've abandoned that method of components for now and instead have a basic VoxelGroup class that has an enum of GroupTypes to determine how it should behave (Another class entirely).  The list of voxels from before is non-existant

With that in mind, would your interface method still work properly?  Or should I change my architecture slightly to accomodate?

Probably not if I understand your new design.  I would imagine you would switch on the enum to implement different behaviour for each voxel group.

The pattern I suggested is a good way of doing things for the reasons listed above but sometimes it's overkill, the enum approach may well be simpler in this case.

Quote
And the idea of an abstract base class; would that replace the VoxelGroup class, and then I would create multiple classes for different types of groups, all of which would use an interface for commonly needed methods - that about sum it up?

Pretty much yes.  The idea of the abstract base class is that it's a template implementation that would implement the interface with default behaviour, and concrete classes would extend (or override) that behaviour.  e.g.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
interface Component {
    render();    
    update( long time );
}

abstract class AbstractComponent implements Component {
    protected long lastUpdate;

    render {
        // do nowt
   }

    update( long time ) {
        lastUpdate = time;
    }
}

class Wire extends AbstractComponent {
    render {
        ...
    }

    update( long time ) {
        super();
        ...
    }
}

...


Again, it's a useful and fairly common practice, but whether it applies to your situation only you can tell Wink

Good luck.

- stride
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (12 views)
2014-07-29 18:09:19

Riven (8 views)
2014-07-29 18:08:52

Dwinin (9 views)
2014-07-29 10:59:34

E.R. Fleming (25 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (27 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!