Stack Implementando una interface Iterable<E>
Nodo<Item> primerNodo;
private int N;
public Stack() {
primerNodo = null;
N = 0;
}
public boolean isEmpty() {
return primerNodo == null;
}
public boolean empty() {
return N==5;
}
public int size(){
return N;
}
public Item peek() {
return primerNodo.item;
}
private void push(Item item) {
if(empty()){
throw new RuntimeException("Stack underflow");
}
else{
Nodo<Item> AnteriorPrimero = primerNodo;
primerNodo = new Nodo<Item>(item);
primerNodo.item = item;
primerNodo.siguienteNodo = AnteriorPrimero;
N++;
}
}
public Item pop() {
if (isEmpty())
throw new EmptyStackException();
Item item = primerNodo.item;
primerNodo = primerNodo.siguienteNodo;
N--;
return item;
}
public Iterator<Item> iterator() {
return new StackIterator();
}
private class StackIterator implements Iterator<Item> {
Nodo<Item> ActualNodo = primerNodo;
public boolean hasNext(){
return ActualNodo != null;
}
public void remove(){
throw new UnsupportedOperationException();
}
public Item next() {
if (!hasNext()) throw new NoSuchElementException();
Item item = ActualNodo.item;
ActualNodo = ActualNodo.siguienteNodo;
return item;
}
}
Clase Nodo.class
public Nodo<Item> siguienteNodo;
Item item;
public Nodo(Item item){
this.item=item;
}
public Nodo(Item item,Nodo<Item> siguienteNodo){
this.item=item;
siguienteNodo=null;
}
}
- JaimeItlzc's blog
- Inicie sesión o regístrese para enviar comentarios
Comentarios
Que tal Jaime. Aquí te van
Que tal Jaime. Aquí te van algunas observaciones ( nada graves por cierto )
Lineas / Comentario:
2,14 primerNodo y empty() deberían de ser privados
3, la variable N debería de ser minúscula ( pues la mayúsculas se usan para constantes )
5, puedes prescindir del constructor, pues el default hace exactamente lo mismo
26,
push debería de ser público
31
AnteriorPrimero
debería de ser anteriorPrimero40,41, usa llaves, siempre, aunque tu if sea de una sola linea
53, ActualNodo, debería de ser "actualNodo" ( con minúscula ) y debería de ser privado
Los atributos en Node deben de ser privados y con un método para accederlos.
Final prefiere una letra para el elemento generico, como E, T, I, etc, en vez de item.
Que bueno que lograste hacer tu pila.
Espero que esta revisión de código te ayude, y no te pongas loco como otras personas.
:)
Chau!
No para nada
No para nada Oscar, asi aprendo aun mas y lo llevo ala practica. Solo no me queda claro una cosa sobre: con un metodo para accederlos hay como que me revolvi no entiendo aparte del constructor hago metodos para acceder alos Nodos?
Gracias de antemano.
Saludos.
Aclaracion
Se refiere a que implementes los metodos get para la clase nodo
Exacto, tienes los atributos
Exacto, tienes los atributos como publicos, lo cual le resta flexibilidad. Si la clase es privada, puede que no haya mucho problema, pero si es publica, es mejor que accedas a ellos por métodos.
Sobre si es un getter o no, personalmente, no me gustan mucho, pero definitivamente, es un estándar en la industria.
Por ejemplo:
private int speed;
public int speed(){
return this.speed;
}
}
Yo prefiero, eso, al clásico
return this.speed;
}
Asi al usarlo, se lee:
disableSpoiler();
}
ObjC
Oscar eso es porque te quedaste con la costumbre de Objective-C, donde el getter se llama igual que la propiedad porque simplemente haces [car speed]. En Java el estándar es car.getSpeed() sin embargo los lenguajes de expresión como los de JSTL, Spring EL, el de Tapestry, etc interpretan "car.speed" como "invocar el método getSpeed() en el objeto car". Incluso en Groovy si tienes un objeto de Java con el método getSpeed(), puedes invocar car.speed y funciona sin broncas.
Y bueno si nos vamos a otros lenguajes... en C# está esa sintaxis de Speed { set {speed=value;} get { return speed; }} para que a tu objeto le puedas hacer car.Speed=5 o int x=car.Speed y se invoca el código dentro de los segmentos de set y get (y "value" en el set es una variable mágica que contiene lo que le quieren asignar a la propiedad).
jajaj, si, más o menos.
jajaj, si, más o menos. Imagínate:
[cat getSpeed];
yiack. Son métodos al fin y al cabo. Esa convención se quedo desde los JavaBeans y es demasiado tarde para quitarla.Pero definitivamente, lo mejor será siempre usar getXyz y setXyz ( o isXyz si es un booleano ) por fuchi que me parezca.
Chau!
Yo tengo una duda, segun
Yo tengo una duda, segun algunos libros de spring si pones nada mas
return this.speed;
}
no lo reconoce como una propiedad porque no tiene el prefijo "get", es cierto?, no sé si con anotaciones lo soluciones, pero antes que no habia anotaciones alguien sabe si era obligatorio hacerlo asi? o por ejemplo también me ha tocado leer que por definición todos los JavaBean deben de implementar Serializable, tener un constructor por default (sin argumentos) y sobrecargarlo con tus propiedades y asi, que tan valido es eso actualmente?
No tenia conocimiento sobre eso
No tenia conocimiento sobre eso Oscar la verdad pero que bien que me lo comenta los voy a aplicar en mis futuros programas y gracias alos demas por sus comentarios son de gran ayuda ya que asi aprendo aun mas cosas y cuando salga una duda de esa pues contestar me pondre a investigar tambien,
Saludos.
Yo también...
tengo que repasar esto Jaime, pero te dejo la liga va, son las normas de estilo: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html , http://java.sun.com/docs/books/jls/index.html