jueves, 7 de diciembre de 2017

Interfaces

Un interfaz es una lista de acciones que puede llevar a cabo un determinado objeto. Sorpresa, ¿eso no eran los métodos que se definen en una clase? Casi, en una clase además de aparecer los métodos aparecía el código para dichos métodos, en cambio en un interfaz sólo existe el prototipo de una función, no su código.
Veamoslo con un ejemplo: Pensemos en un interfaz que en su lista de métodos aparezcan los métodos despegar, aterrizar, servirComida y volar. Todos pensamos en un avión, ¿verdad? El motivo es sencillamente que avión es el concepto que engloba las acciones que hemos detallado antes, a pesar que existan muchos objetos avión diferentes entre sí, por ejemplo Boeing 747, Boeing 737, MacDonell-Douglas.
Lo realmente interesante es que todos ellos, a pesar de pertenecer a clases distintas, poseen el interfaz avión, es decir poseen los métodos detallados en la lista del interfaz avión.
Esto significa también que a cualquier avión le podemos pedir que vuele, sin importarnos a que clase real pertenezca el avión, evidentemente cada clase especificará como volará el avión (porque proporciona el código de la función volar).
En java un interfaz define la lista de métodos, pero para que una clase posea un interfaz hay que indicar explícitamente que lo implementa mediante la claúsula implements. Pero veamos primero la estructura de un interfaz:
          [modif.visibilidad] interface nombreInterfaz [extends listaInterfaces]
         {
          prototipo método1;
          
..
          prototipo método1;
         }
         
Donde modif.visibilidad puede ser public o bien sin especificar, es decir visibilidad pública (desde cualquier clase se puede emplear el interfaz) o de paquete (sólo se puede emplear desde clases del mismo paquete).
nombreInterfaz por convenio sigue las mismas reglas de nomenclatura que las clases, y en muchos casos acaba en able (que podíamos traducir como: ser capaz de).
La claúsula opcional extends se emplea para conseguir que un interfaz hereda las funciones de otro/s interfaces, simplemente listaInterfaces es una lista separaada por coma de interfaces de los que se desea heredar.
En muchas ocasiones un interfaz es empleado para definir un comportamiento, que posteriormente será implementado por diversas clases, que podrían no tener nada que ver entre ellas, pero que todas se comportarán igual de cara al interfaz. Es decir, todas tendrán las funciones indicadas por el interfaz.
Cuando varios objetos de distintas clases pueden responder al mismo mensaje (función), aún realizando cosas distintas se denomina polimorfismo.
Prácticas:
Vamos a definir el interfaz Cantante, un interfaz muy simple que sólo posee un método: cantar.

  • Crear el fichero Cantante.java
  • Agregar el siguiente código:
            public interface Cantante
            {
             public void cantar();
            }
            
  • Cojamos la clase Persona y hagamos que implemente el interfaz Cantante:
            public class Persona implements Cantante
            
  • Además agreguemos el código para el método que define el interfaz cantante:
            public void cantar()
            {
                  System.out.println("La laa la raa laaa!");
            }
            
  • Construyamos ahora una clase con función main (ArranqueInterfaz.java)para ejecutar:
            public class ArranqueInterfaz
            {
             public static void main(String arg[])
             {
              
              Persona p = new Persona();
              hacerCantar(p);
             }
             public static void hacerCantar(Cantante c)
             {
              c.cantar();
             }
            }
            
  • Podemos ver que construimos un objeto (p) de tipo persona y se lo pasamos a la función hacerCantar. Esta función espera recibir un objeto Cantante, y una persona lo es, por tanto la recibe y llama al método cantar del objeto recibido.
  • Probemos a intentar pasar a la función hacerCantar en lugar del objeto Persona (p) un objeto String (texto), resultado: error de compilación.
  • Contruyamos ahora la clase Canario (Canario.java), pensando que también sabe cantar:
            public class Canario implements Cantante
            {
             private int peso;
             /* Aqui vendrían el resto de atributos y funciones propias de un canario */
             

             public void cantar()
             {
              System.out.println("Pio Pio Pio");
             }
            }
            
  • Y ahora agreguemos en la clase ArranqueInterfaz el siguiente código, para crear un objeto canario y pasarselo a la función hacerCantar:
            Canario c = new Canario();
            hacerCantar(c);
            
  • Tras ejecutar comprobaremos que podemos pasar tanto una Persona como un Canario a la función hacerCantar, de tal manera que dentro de dicha función sólo accedamos a las funciones del interfaz y no habrá problemas. Por ejemplo, si pusieramos:
            c.SetNombre("Luis")
            
  • dentro de la función hacerPersona, podría funcionar si pasasemos un objeto Persona, pero no si pasamos uno de tipo Canario.

martes, 5 de diciembre de 2017

Mostrar imagen dentro un jPanel

Se crea un nuevo proyecto en Netbeans y en vista de diseño se agrega un jButton y un jPanel.
Una vez hecho esto se crea una nueva carpeta llamada "Images". Dentro esta carpeta le agregamos una imagen en formato .PNG (se inserta directamente arrastrando la imagen a la carpeta).





















Codigo 1. (Principal.java):

package Imagen1;

public class Principal extends javax.swing.JFrame {
    
    public Principal() {
        initComponents();
        this.setLocationRelativeTo(null); // Centrar pantalla 
    }
                            
    private void initComponents() { ... // Codigo generado automaticamente.                        

    private void jButtonIniciarActionPerformed(java.awt.event.ActionEvent evt) {
        Imagen im = new Imagen(jPanel1);
        jPanel1.add(im).repaint();
    }                                              

    public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new Principal().setVisible(true);
            }
        });
    }

    // Variables declaration - do not modify                     
    private javax.swing.JButton jButtonIniciar;
    private javax.swing.JPanel jPanel1;
    // End of variables declaration                   

}


Codigo 2. (Imagen.java):

package Imagen1;

import java.awt.Graphics;
import javax.swing.ImageIcon;
import javax.swing.JPanel;

public class Imagen extends javax.swing.JPanel {
    int x, y;

    public Imagen(JPanel jPanel1) {
        this.x = jPanel1.getWidth();
        this.y = jPanel1.getHeight();
        this.setSize(x, y);
    }

    @Override
    public void paint(Graphics g) {
        ImageIcon Img = new ImageIcon(getClass().getResource("/Images/imagen1.png"));
        g.drawImage(Img.getImage(), 0, 0, x, y, null);
    }    

}


Resultado:

SOLID

S.O.L.I.D
Single Responsibility
Open Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

1.- Single Responsibility Principle
Una clase jamás debería tener mas de una razón por la cual cambiar.
·         Responsabilidad= Razón para cambiar
·         Si una Clase asume mas de una responsabilidad, entonces tendrá mas de una razón para cambiar.
·         Acoplamiento de responsabilidades.



2.- Open Closed Principle
Entidades de software deberían estar abiertas para extensión pero cerradas para modificación
·         Si 1 cambio a varios módulos, entonces la aplicación no esta bien diseñada.
·         Debemos diseñar módulos que nunca cambien.
Cuando realizas un sistema de una empresa y tienes que tenerun ril basado “puede realizar un pago, mañana me solicitan que cree un nuevo rol, por ejemplo “devolución” . Lasolucion actual seria crear un método mas, pero el problema radica en que nuestra clase tiene que impremntar mas código. “abierto para la extensión pero cerrado para la modificación. Por lo tanto no modifiques nada y extiende la funcionalidad.
3.- Principio de Sustitución de Liskov
El principio de Liskov nos ayuda a utilizar la herencia de forma correcta.
Bien, tenemos una clase base abstracta que será un Robot y este puede realizar una cantidad X de punto de año al momento de atacar, pero necesita ser heredada par ser usada.
Asimismo, la tecnología avanzado y llegaron 2 modelos nuevo pero van a heredar las características del Robot. La diferencia es que estos tienen más poder de ataque, por lo tanto habremos que sobrescribir sus métodos.
4.- Principio de Segregación de Interfaces
Nos ayuda a no obligar a ninguna clase a implementar métodos que no utiliza.

5.- Principio de Inversión de Dependencias
Gracias al principio de inversión de dependencias, podemos hacer que el código que es el núcleo de nuestra
aplicación no dependa de los detalles de implementación, como pueden ser el framework que utilices,
 la base de datos, cómo te conectes a tu servidor


Interfaces

Un interfaz es una lista de acciones que puede llevar a cabo un determinado objeto. Sorpresa, ¿eso no eran los métodos que se definen en un...