Slider Image

  • Google Chrome

    Tips, extensiones y trucos para aprovechar al máximo tu navegador Chrome

  • HTML5

    Conoce la nueva versión del lenguaje de programación web por excelencia

  • Java

    Aprende a programar en Java con tutoriales paso a paso, cubriendo desde lo más básico hasta lo más especializado

  • NetBeans

    Conoce este completo IDE para desarrollar en diversos lenguajes, aprende trucos y conceptos que te facilitarán la codificación de cualquier tipo de software

  • Linux

    ¿Eres linuxero o deseas serlo? Hay una sección especialmente para ti.

  • Ahora Mis Ojos Te Ven

    Echa un vistazo a mi nuevo blog 'Ahora Mis Ojos Te Ven' y no dudes en dejarme tu opinión.

Mi experiencia con Dell



Hace aproximadamente un año adquirí una computadora portátil Dell XPS M1210 primeramente por motivos escolares ya que entre el trabajo y la escuela me quedaba muy poco tiempo para realizar mis tareas en casa, ahora dicha computadora se ha vuelto indispensable para mi vida diaria ya que es mi herramienta de trabajo y, por qué no, de entretenimiento algunas veces.

Lo cierto es que mi experiencia con Dell ha sido más que buena, yo diría excelente. He tenido un par de inconvenientes menores con ella pero la respuesta que he tenido por parte del área de garantías ha sido de lo mejor. El primer inciente que tuve fue que la unidad de Cd/Dvd comenzó a grabar discos muy lento, prové con varias marcas de discos y varios programas de grabación y simplemente el problema seguía igual, decidí contactarme con las personas de Dell por medio de correo electrónico y comentarles mi problema, ellos me indicaron algunas soluciones pero yo ya había intentado todo, al final del día me comentaron que me cambiarían la unidad por una nueva, no era la solución que yo esperaba pues a mi punto de vista la unidad funcionaba bien pero confié en la solución que me ofrecieron. Al día siguiente como a eso de las 12:00 p.m. un técnico me llamó a mi celular y me preguntó dónde podría encontrarme para cambiarme la unidad, le dije que en mi casa y le dí la dirección, en menos de media hora llegó a mi casa, sacó la unidad dañada, colocó la nueva, la probé y listo, todo el problema resuelto en menos de 24 horas.

La segunda ocasión que tuve un problema fue apenas hace 2 días, el problema fue que el adaptador de corriente dejó de cargar la batería, el equipo encendía pero la batería nunca cargaba, probé con otro adaptador de un equipo del mismo modelo y todo estaba bien, nuevamente me puse en contacto con Dell, esta vez por chat, les comenté el problema pero al parecer había problemas con el sistema ya que la conexión se caía a cada rato, al final en cuanto me contacté me pidieron mi teléfono para hablarme en caso de que volviera a caerse la conexión ellos me marcarían y así sucedió, el Sr. Abraham Cubas (persona que me estaba atendiendo por chat) se contactó conmigo por teléfono y me dijo que me cambiarían el adaptador de corriente, hoy a las 11:00 a.m. se contactaron conmigo y llegaron a mi trabajo para cambiar la pieza. Problema resuelto en menos de 48 hrs.

Como algunos de ustedes saben estuve trabajando en el área de soporte técnico de HP & Compaq de latinoamérica y conozco cómo es que funciona el trámite de garantías en dicha empresa que es completamente diferente a Dell, en HP con el primer problema se hubieran llevado mi computadora al menos por un mes y me la hubieran devuelto probablemente con el mismo problema, eso si me hubieran querido valer la garantía por el problema que tuve, en el caso del adaptador de corriente me lo hubieran enviado por correo y tardaría aproximadamente 15 días en llegar.

El punto de todo esto es que estoy satisfecho con el trato que tiene Dell con sus clientes y estoy seguro que si el día de mañana tengo que comprar un equipo de marca ésta será Dell, siempre que me pregunten por una recomendación recomendaré Dell por que conozco su forma de trabajar y es excelente.

Habilidad Policiaca

No cabe duda que sólo en México pasan cosas así. La policía de Laredo en una búsqueda intensa de los ladrones de un banco, solo que los tenían frente a ellos y la prisa no les permitió darse cuenta. Bravo por nuestros Polecias!!!

Yo tenía un lindo celular...

Pues sí, yo tenía un lindo celular Nokia 5700 Xpress Music hasta que a un par de ladrones se les ocurrió quitármelo. Todo pasó de la siguiente manera:

Hace aproximadamente 5 días tuve un dolor de riñones provocado por años de trabajar sentado y falta de ejercicio, según me comentaron el problema se resolvía tomando mucha agua y caminando regularmente. Debido a ello, decidí que saliendo del trabajo caminaría aproximadamente 15 cuadras desde el Blvd. Adolfo López Mateos hasta mi casa a través del Blvd. Paseo de los Insurgentes y comencé a hacerlo desde el pasado viernes, cabe mencionar que dicho camino lo he transitado no menos de 30 veces a cualquier hora y nunca había sucedido nada.

Eran como eso de las 6:40 pm cuando yo venía de López Mateos sobre Insurgentes, aproximadamente a algunas 2 cuadras de una tienda Oxxo que existe sobre dicho Blvd., yo tranquilo escuchando música y relajado ya que dichos momentos son de los cuales disfruto mi soledad y aprovecho para pensar en lo que sea. Venía yo cantando en voz baja cuando volteo un poco hacia atrás y veo un tipo de camisa amarilla, pantalón café y cabello pintado con rayos rubios, moreno de estatura media, ojos un poco rasgados y nariz grande aproximadamentede 25 años, como a 5 metros de distancia dirigiéndose hacia mí, posteriormente volteo hacia el frente y veo a otro tipo a la misma distancia, este con pantalón de mezclilla azul oscuro, camisa blanca, desfajado, con una mochila verde, él era un poco más joven, moreno y con un picahielo en la mano.

Repentinamente se me acercaron los dos, el primero me tomó del brazo y me dijo que les diera todo lo que traía, si no lo hacía me darían un 'fierrazo', esto me decía mientras el segundo colocaba el picahielo cerca de mi abdomen de forma amenazadora, con el dolor de mi corazón les entregué la mochila de escuela vieja que tengo, dentro venía mi computadora portátil, posteriormente me quitan mi celular y me piden entregar la cartera, la prisa no les permitió quitarme mi reloj. Les entregué todo lo que traía de valor pero serenamente, no hice gestos ni dije nada, pensé dentro de mí 'si me han de quitar algo que sea lo material, qué mas da, no puedo hacer nada'. Un poco antes de irse, algunos 3 segundos antes, el mayor me entrega mi mochila y me dice que no diga nada por que tienen todos mis datos (en la cartera) y me puede ir mal. En el momento que me entregó mi mochila sentí que el alma volvía a mi cuerpo, un sentimiento repentino de que no me habían robado nada, el pensar primeramente en perder mi computadora era lo que más me dolía, una vez que me la entregaron el dolor fue mucho menor, pero el coraje y el susto aún estaban ahí. Lo primero que pensé fue 'qué traía en la cartera??', recordé que traía mis identificaciones, tarjeta de débito del banco, un recibo de pago del certificado de la escuela, algunas fotos y cosas sin importancia.

Llegué a mi casa que está a unas 5 cuadras del lugar a dejar las cosas que aún me quedaban, posteriormente me salí a llamar a la línea de emergencias al 066, aún con el coraje estaba ansioso por que me contestaran y reportar el incidente pero me llevé una desilusión, en lugar de contestarme una persona servicial y dispuesta a ayudar, me contesta una señorita que estaba platicándole su vida a una compañera, se dio cuenta que tenía una llamada y simplemente colgó el teléfono, ahora mi coraje era mayor, volví a marcar y ahora sí fuí atendido con amabilidad y una actitud de servicio de otra señorita. Mientras marcaba pasó una patrulla de la policia, les hice señas con las manos pero no me hicieron caso. Al final reporté el incidente y me dijeron que para recuperar mis cosas debía de levantar una denuncia en el ministerio público lo cual me abstuve de hacer.

Mi confianza en la seguridad pública (supongo que al igual que todos los mexicanos) es cada vez menor, no entiendo cómo es posible que en lugar de atender una emergencia como lo que es se le pague a una señorita por estar platicando sobre su vida a sus compañeras y que cuando se le hable a una patrulla de la policía simplemente hagan caso omiso, no sé por qué las cosas cada vez están peor en este país. No me duele tanto mi celular, ni mi cartera (traía como 300 pesos solamente), lo que realmente me da coraje es que una persona cualquiera te pueda quitar algo que es tuyo por derecho, aunque fuera un chicle pero es tuyo, pagado con dinero que fue ganado honestamente y con sacrificios, no es posible que por que a un raterito se le ocurre portar un picahielo y pedirte lo que traigas tengas que hacerlo, como decía cantinflas 'No hay derecho'.

Ahora supongo que lo que nos queda es salir a la calle con lo menos posible, no portar documentos importantes en la cartera ni nada que revele tu información personal, cambiar nuestro celular de alta tecnología y valor por uno que apenas y sirva para lo indispensable, no vaya a ser que se le antoje a un individuo, saque el picahielo y te lo quite. De milagro no se llevaron la computadora (gracias a Dios que me la regresó), de lo contrario no tendría con qué estar escribiendo esto.

Envié un mensaje a la presidencia municipal de León indicando lo sucedido y este comentario:

No puedo creer que haya gente con esa actitud atendiendo la línea de emergencias o patrullando por la ciudad. Al final de cuentas no me importa tanto lo que me quitaron sino el darme cuenta de qué seguridad goza la ciudad en la que vivimos, está muy lejos de ser 'La mejor ciudad para vivir', no solamente basta con anunciarlo por todos los medios sino hacer todo lo posible por que sea una realidad.

Ya sé que puedo ser uno más del montón al que le suceden estas cosas en las calles de nuestro León que ya no es tan nuestro, puede que ni siquiera lean con atención lo que estoy escribiendo, no nos basta solo con promesas de campaña o eslogans promocionales, personas amenazan a plena luz del día con ponernos un 'fierrazo' como ellos lo nombran solo por que nos ven en la calle con audífonos puestos, me da tristeza el pensar que esto es en lo que se ha convertido mi ciudad.

Ahora supongo que lo que nos queda es salir a la calle con lo menos posible, no portar documentos importantes en la cartera ni nada que revele tu información personal, cambiar nuestro celular de alta tecnología y valor por uno que apenas y sirva para lo indispensable, no vaya a ser que se le antoje a un individuo, saque el picahielo y te lo quite.

Espero respuesta aunque sea para saber que ha leído mi mensaje y le invito a visitar mi página web donde narro la historia completa de lo sucedido y narraré lo que sucederá con este mensaje.

http://monillo007.blogspot.com/2008/01/yo-tena-un-lindo-celular.html


Actualizaré la información en cuanto reciba respuesta. Te invito a que dejes tu comentario, por si el alcalde se toma el tiempo de visitar mi sitio y ver lo que opinamos al respecto.

Si tú me olvidas.

Quiero que sepas
una cosa.

Tú sabes cómo es esto:
si miro la luna de cristal, la rama roja
del lento otoño en mi ventana,
si toco junto al fuego
la impalpable ceniza
o el arrugado cuerpo de la leña,
todo me lleva a ti,
como si todo lo que existe,
aromas, luz, metales,
fueran pequeños barcos que navegan
hacia las islas tuyas que me aguardan.

Ahora bien,
si poco a poco dejas de quererme
dejaré de quererte poco a poco.

Si de pronto me olvidas
no me busques,
que ya te habré olvidado.

Si consideras largo y loco
el viento de banderas
que pasa por mi vida
y te decides
a dejarme a la orilla
del corazón en que tengo raíces,
piensa que en ese día,
a esa hora levantaré los brazos
y saldrán mis raíces
a buscar otra tierra.

Pero si cada día,
cada hora
sientes que a mí estás destinada
con dulzura implacable.
Si cada día sube
una flor a tus labios a buscarme,
ay amor mío, ay mía,
en mí todo ese fuego se repite,
en mí nada se apaga ni se olvida,
mi amor se nutre de tu amor, amada,
y mientras vivas estará en tus brazos
sin salir de los míos.

Pablo Neruda

Magia sorprendente!

Criss Angel, un famoso ilusionista parte a una mujer en 2 frente a varios espectadores. No hay duda de que esto no es posible realmente, lo que sorprende del acto es que lo hace a plena calle y (al menos así lo parece) sin ayudantes.

Sin duda es un video que ha impactado a más de alguno, es el estilo de Criss Angel.

Sobrecarga de métodos en Java(Overloading)

Un método sobrecargado se utiliza para reutilizar el nombre de un método pero con diferentes argumentos (opcionalmente un tipo diferente de retorno). Las reglas para sobrecargar un método son las siguientes:

+ Los métodos sobrecargados debeb de cambiar la lista de argumentos.
+ Pueden cambiar el tipo de retorno.
+ Pueden cambiar el modificador de acceso.
+ Pueden declarar nuevas o más amplias excepciones.
+ Un método puede ser sobrecargado en la misma clase o en una subclase.

Veamos un método que se desea sobrecargar:

public void cambiarTamano(int tamano, String nombre, float patron){ }

Los siguientes métodos son sobrecargas legales del método cambiarTamano():

public void cambiarTamano(int tamano, String nombre){}
public int cambiarTamano(int tamano, float patron){}
public void cambiarTamano(float patron, String nombre) throws IOException{}


Cómo invocar un método sobrecargado::

Lo que define qué método es el que se va a llamar son los argumentos que se envían al mismo durante la llamada. Si se invoca a un método con un String como argumento, se ejecutará el método que tome un String como argumento, si se manda a llamar al mismo método pero con un float como argumento, se ejecutará el método que tome un float como argumento y así sucesivamente. Si se invoca a un método con un argumento que no es definido en ninguna de las versiones sobrecargadas entonces el compilador arrojará un mensaje de error.

Ejemplo de una clase con un método sobrecargado:

public class Sobrecarga {
public void Numeros(int x, int y){
System.out.println("Método que recibe enteros.");
}
public void Numeros(double x, double y){
System.out.println("Método que recibe flotantes.");
}
public void Numeros(String cadena){
System.out.println("Método que recibe una cadena: "+ cadena);
}
public static void main (String... args){
Sobrecarga s = new Sobrecarga();
int a = 1;
int b = 2;
s.Numeros(a,b);
s.Numeros(3.2,5.7);
s.Numeros("Monillo007");
}
}


Al ejecutar el código anterior obtendremos lo siguiente:

Método que recibe enteros.
Método que recibe flotantes.
Método que recibe una cadena: Monillo007


Al utilizar objetos en lugar de tipos primitivos o cadenas se vuelve más interesante. Veamos lo que sucede cuando se tiene un método sobrecargado que en una de sus versiones toma un Animal como parámetro y en otra un Caballo.

class Animal { }

class Caballo extends Animal{ }

class Animales{
public void MetodoSobrecargado(Animal a){
System.out.println("Método de parámetro Animal...");
}
public void MetodoSobrecargado(Caballo c){
System.out.println("Método de parámetro Caballo...");
}
public static void main(String... args){
Animales as = new Animales();
Animal objetoAnimal = new Animal();
Caballo objetoCaballo = new Caballo();
as.MetodoSobrecargado(objetoAnimal);
as.MetodoSobrecargado(objetoCaballo);
}
}


Al ejecutar el código anterior obtenemos:

Método de parámetro Animal...
Método de parámetro Caballo...


Como era de esperarse, cada objeto manda a llamar al método que le corresponde de acuerdo a su tipo, pero qué pasa si creamos una referencia Animal sobre un objeto Caballo...

Animal objetoAnimalRefCaballo = new Caballo();
as.MetodoSobrecargado(objetoAnimalRefCaballo);


El resultado es:

Método de parámetro Animal...

Aunque en tiempo de ejecución el objeto es un Caballo y no un Animal, la elección de qué método sobrecargado invocar no se realiza dinámicamente en tiempo de ejecución, el tipo de referencia, no el objeto actual, es el que determina qué método es el que se ejecutará.

Reglas de la sobrecarga y sobreescritura de métodos::

Ahora que hemos visto ambas formas de reescribir métodos, revisemos las reglas y diferencias entre ambos tipos de reescritura:

+Argumentos: En un método sobrecargado los argumentos deben de cambiar mientras que en un método sobreescrito NO deben cambiar.

+ El tipo de retorno: En un método sobrecargado el tipo de retorno puede cambiar, en un método sobreescrito NO puede cambiar, excepto por subtipos del tipo declarado originalmente.

+ Excepciones: En un método sobrecargado las excepciones pueden cambiar, en un método sobreescrito pueden reducirse o eliminarse pero NO deben de arrojarse excepciones nuevas o más amplias.

+ Acceso: En un método sobrecargado puede cambiar, en un método sobreescrito el acceso NO debe de hacerse más restrictivo(puede ser menos restrictivo).

+ Al invocar: En un método sobrecargado los argumentos son los que determinan qué método es el que se invocará, en un método sobreescrito el tipo de objeto determina qué método es elegido.

Esto es todo con la sobrecarga de métodos en Java. ¿Alguna duda? deja tu comentario.

Más sobre programación en Java aquí.

Batman Vs Depredador Vs Alien

Un muy buen cortometraje de mucha calidad. Simplemente fenomenal.





Más videos aquí.

Evita ser víctima de un fraude

Esta mañana me llegó un correo de Santander-Serfin en el cual advierten sobre una nueva forma de fraude con las tarjetas de crédito y débito, me pareció sumamente interesante y decidí publicarlo por si acaso tu banco no te avisa sobre cosas al respecto. Copio y pego.

Para Santander la Seguridad de sus clientes es de suma importancia, es por esta razón que te damos a conocer algunas medidas de seguridad para evitar ser víctima de la siguiente modalidad de fraude con Tarjetas Bancarias.

Ejemplo:

Recibes una llamada y el defraudador te dice: "Estamos llamando del Departamento de Seguridad de VISA (por ejemplo). Soy Fulano de Tal y mi número de identificación funcional es 12460. ¿Usted compró (cualquier cosa) un sistema de video con un valor de US $3,000 en una tienda en Chicago, USA?"

Obviamente respondes que no, y el delincuente te responde lo siguiente:"Probablemente su tarjeta fue clonada y estamos llamando para verificar. Si lo confirmamos estaremos emitiendo un crédito a su favor". Este tipo de transacción está sucediendo con gastos que varían de US $297 a US $499, justamente por debajo de US $500 que es cuando acciona la mayoría de las alertas.

Antes de procesar el crédito, nos gustaría confirmar algunos datos:

¿Su dirección es tal?" (Esto puede ser sacado fácilmente de las guías telefónicas vía Internet).

Al decir que sí el tipo continúa: "Cualquier pregunta que Usted tenga, deberá llamar al número 01 800 que se encuentra en la parte trasera de su tarjeta y pedir por el Departamento de Seguridad. Por favor, tome nota del siguiente número de protocolo" El estafador le da, entonces, un número de 6 dígitos y pide: "¿Podría leérmelo para confirmar?"

Aquí viene la parte más importante del fraude.

Él dice: "Disculpe, pero tenemos que verificar que el Sr. o Sra. está en posesión de la tarjeta. Por favor tome su tarjeta y léame su número"...

Hecho esto, continúa:

"Correcto. Ahora de vuelta a su tarjeta y léame los 3 últimos números (o 4, dependiendo de la tarjeta)"

Estos son los 'Números de Seguridad' (Pin Number) que usas para hacer compras vía Internet, para probar que tienes la tarjeta.

Después que le das los números referidos el dice: "Correcto. Entienda que era necesario verificar que la tarjeta no estaba extraviada, ni robada y que Usted la tenía en su poder. ¿Tiene alguna duda?"

Después que le dices que no, el ladrón agradece y finaliza.

Probablemente, en menos de 10 minutos, una compra será hecha con la tarjeta, y muchas más si es que uno no se da cuenta del fraude hasta la llegada del estado de cuenta.

¿Cómo protegerse?

  • En caso de recibir este tipo de comunicación se le puede decir al defraudador que cuelgue, que tu vas a llamar al 01 800 mencionado en la tarjeta de crédito y ahí aclararas la situación de tu tarjeta.


  • Se cuidadoso en la custodia de tus identificaciones como: credencial de elector (IFE), pasaporte, licencia de conducir, credenciales de empleo o escuela, etc.


  • Ten cuidado con tu correspondencia y destruye completamente la información antes de tirarla a la basura.


  • Nunca proporciones información de tus tarjetas de crédito o tus cuentas solicitada por teléfono.


  • Evita proporcionar datos confidenciales en Centros Comerciales, con el pretexto de ingresar a sorteos o promociones con casas comerciales de dudosa procedencia.


  • Mantén la información personal de tus tarjetas y de tus cuentas en un lugar seguro.


  • Ten a la mano los teléfonos de Superlínea para reportar en forma inmediata tus tarjetas en caso de pérdida o robo.


  • Pon atención en los cortes y entregas de tus estados de cuenta y reporta los que no recibas en forma regular (pueden estar llegando a otro domicilio).


  • Solicita información al Buró de Crédito, para verificar créditos existentes a tu nombre.
Evita ser víctima de la delincuencia o del descuido, para mayor información consulte el Site de Seguridad en el portal Santander, donde encontrarás una serie de recomendaciones para mantener tu seguridad.

Sin duda una serie de recomendaciones bastante interesantes. Nunca se es demasiado cuidadoso cuando se trata de nuestro patrimonio.

El video de René Núñez y de Alfredo Castellanos Castro

Normalmente no acostumbro publicar cosas relacionadas con la política pero en esta ocasión me pareció pertinente hablar un poco al respecto.

Si bien sabemos todos los mexicanos que no vivimos en un país perfecto (muy lejos de serlo) creo yo que todos nosotros (o al menos la mayoría) estamos interesados en mejorar la situación actual de México, tanto politica como socialmente, la cuestión es que año con año suceden escándalos sumamente alarmantes, y no solo escándalos sino video-escándalos, que nos hacen pensar si nuestros politicos escogieron la carrera correcta ya que muchos parecen más bien actores de cine (y algunos de cine porno).

Sobrescritura de métodos en Java (Overriding)

Cada vez que se tiene una clase que hereda un método de una superclase, se tiene la oportunidad de sobreescribir el método (a menos que dicho método esté marcado como final). El beneficio clave al sobreescribir un método heredado es la habilidad de definir un comportamiento específico para los objetos de la subclase.Veamos un ejemplo de la sobreescritura de un método heredado:

public class Animal {

public void comer(){
System.out.println("Animal comiendo...");
}
}

class Caballo extends Animal{
public void comer(){
System.out.println("Caballo comiendo...");
}
}


Al momento de que Caballo hereda de la clase Animal obtiene el método comer() definido en Animal, sin embargo, se desea especificar un poco más el comportamiento de Caballo al momento de llamar a comer(), por lo tanto se define un método con el mismo nombre dentro de la clase Caballo. Debido a que ambos métodos tienen el mismo nombre, para saber qué método se invocará en tiempo de ejecución es necesario saber a qué objeto se está refiriendo. P. ej.:

public static void main(String... args){
Animal a = new Animal();
Caballo c = new Caballo();
a.comer();
c.comer();
}



Al ejecutar el código anterior obtenemos lo siguiente:

Animal comiendo...
Caballo comiendo...


Ahora en su versión polimórfica:

public static void main(String... args){
Animal a = new Caballo();
Caballo c = new Caballo();
a.comer();
c.comer();
}

Obtenemos lo siguiente:

Caballo comiendo...
Caballo comiendo...


En la primera ejecución del método tenemos una referencia a un Animal pero el objeto es un Caballo, por lo tanto, el método invocado es la versión definida en la clase Caballo. Es importante mencionar que al momento de invocar un método sobre una referencia Animal en un objeto Caballo solamente se podrá ejecutar el métodos si la clase Animal lo define, p. ej.:

class Animal {

public void comer(){
System.out.println("Animal comiendo...");
}
}

class Caballo extends Animal{
public void comer(){
System.out.println("Caballo comiendo...");
}
public void relinchar(){
System.out.println("Caballo relinchando...");
}
}

class ProbarMetodos{

public static void main(String... args){
Animal a = new Caballo();
Caballo c = new Caballo();
a.comer();
c.comer();
a.relinchar();
//error!
}
}


Aún cuando la clase Caballo define un método llamado relinchar(), la clase Animal no sabe que dicho método existe, por lo tanto, el compilador arrojará un error cuando se intente invocar al método relinchar() desde una referencia Animal, no importa que el objeto Caballo sí lo tenga.

Reglas para sobreescribir un método::

Las reglas básicas para la sobreescritura de métodos son las siguientes:

+ La lista de argumentos del método debe ser exactamente la misma.
+ El tipo de retorno debe de ser el mismo o un subtipo del tipo de retorno declarado originalmente.
+ El nivel de acceso no debe de ser más restrictivo.
+ El nivel de acceso puede ser menos restrictivo.
+ Los métodos de instancia pueden ser sobreescritos solamente si han sido heredados por la subclase.
+ Los métodos sobreescritos pueden arrojar cualquier excepción no verificada(de tiempo de ejecución) por el compilador.
+ Los métodos sobreescritos NO pueden arrojar excepciones verificadas por el compilador.
+ No se puede sobreescibir un método marcado como final.
+ No se puede sobreescibir un método marcado como estático (static).
+ Si un método no puede ser heredado, no puede ser sobreescrito.

Invocar la versión de la superclase de un método sobreescrito::

En algunas ocasiones necesitamos invocar al método escrito en la superclase en lugar de la versión que hemos sobreescrito, para ello se utiliza la palabra super seguida de un punto(.) y posteriormente el nombre del método a invocar, p. ej.:

class Caballo extends Animal{
public void comer(){
super.comer();
}
}


Hasta aquí llegamos con este tema. ¿Alguna duda? deja tu comentario.

Más sobre programación en Java aquí.

Terminar Super Mario Bros en 5 minutos!

Para aquellos fanáticos de este tipo de videojuegos os presento un video en el que se muestra cómo terminar Super Mario Bros. en nada más y nada menos que 5 minutos. Increíble verdad? hay quien piensa que es falso, en lo personal creo que es verdad pero juzgad por vosotros mismos.

Si quieres ver más videos interesantes da clic aquí...

Polimorfismo

Prácticamente todos los objetos en Java (excepto aquellos tipo Object) tienen formas múltiples debido a que todas las clases en Java heredan de la clase Object. El polimorfismo recae particularmente en la relación IS-A (es-un) que existe entre 2 o más objetos, veamos un poco acerca de este tipo de relación.

La relación IS-A entre objetos::

En la programación orientada a objetos el concepto IS-A (es-un) está basado en la herencia de una clase o implementación de una interfaz. Es una manera de decir "esta cosa es un tipo de esta otra". P. ej., un Tsuru es un Carro y un carro a su vez es un Vehiculo. En Java la relación IS-A se expresa por medio de la palabra extends (cuando hablamos de clases) e implements (cuando hablamos de interfaces).

class Vehiculo{
//cosas de un vehiculo
}

class Carro extends Vehiculo{
//codigo de carro además de cosas
//heredadas del Vehiculo
}

class Tsuru extends Carro{
//cosas específicas de un Tsuru además de
//cosas heredadas de la clase Carro
}

En programación orientada a objetos podemos decir en base a lo anterior que:

- Vehiculo es la superclase de Carro
- Carro es una subclase de Vehiculo
- Carro es la superclase de Tsuru
- Tsuru es una subclase de Vehiculo
- Carro hereda de Vehiculo
- Tsuru hereda tanto de Vehiculo como de Carro
- Tsuru es un derivado de Carro
- Carro es un derivado de Vehiculo
- Tsuru es un derivado de Vehiculo
- Tsuru es un subtipo de Carro y Vehiculo

Regresando a la relación IS-A:

- "Carro extends Vehiculo" significa "Carro es un (IS-A) Vehiculo"
- "Tsuru extends Carro" significa "Tsuru es un (IS-A) Carro"

Si seguimos el árbol de herencia podemos deducir a su vez que "Tsuru es un (IS-A) Vehiculo". Ahora tenemos un solo objeto que tiene muchas formas, el Tsuru es un Tsuru(valga la redundancia), un Carro y un Vehiculo, además en Java es también un objeto tipo Object ya que toda clase hereda de la clase Object, a esto es lo que llamamos polimorfismo.

Polimorfismo::

Todo objeto que puede pasar más de una vez una prueba IS-A es considerado polimórfico, es decir, tiene muchas formas. Recordemos que la única manera de acceder a un objeto es a través de una variable de referencia, analicemos algunas características básicas de este tipo de variables:

+ Una variable de referencia solo puede ser de un tipo, una vez declarada, dicho tipo no puede cambiar pero sí el objeto hacia el cual refiere.
+ Una referencia es variable, por lo tanto, esta puede ser reasignada a otros objetos (a menos de que la variable sea marcada como final).
+ Una variable de referencia puede referir a cualquier objeto del mismo tipo declarado en la referencia o puede referir a cualquier subtipo del tipo declarado.
+ Una variable de referencia puede ser declarada de tipo clase o interfaz, si la variable es de tipo interfaz, puede referenciar a cualquier objeto que implemente dicha interfaz.

Un ejemplo basado en lo anterior:

class Vehiculo{
//Funcion predeterminada de un Vehiculo
}

class Carro extends Vehiculo{
//Funcion predeterminada de un Carro
//así como cosas heredadas de un Vehiculo
}

public class Tsuru extends Carro{

public Tsuru() {
}

public static void main(String[] args){
Vehiculo vh = new Carro();
Carro ct = new Tsuru();
Vehiculo vt = new Tsuru();

System.out.println(vh.toString());
System.out.println(ct.toString());
System.out.println(vt.toString());
}

}

Al ejecutar lo anterior obtendremos algo parecido a:

Carro@1d9dc39
Tsuru@93dcd
Tsuru@b89838

De igual manera sucede si implementamos el polimorfismo con interfaces:

interface Rodable{
//métodos de la interfaz Rodable
}

class Vehiculo{
//Funcion predeterminada de un Vehiculo
}

class Carro extends Vehiculo implements Rodable{
//Funcion predeterminada de un Carro
//así como cosas heredadas de un Vehiculo
}

public class Tsuru extends Carro{

public Tsuru() {
}

public static void main(String[] args){
Rodable rd1 = new Carro();
Rodable rd2 = new Tsuru();

System.out.println(rd1.toString());
System.out.println(rd2.toString());

}

}

Al ejecutar lo anterior obtenemos algo así:

Carro@93dcd
Tsuru@b89838

En el ejemplo anterior no podemos utilizar una referencia a un objeto tipo Vehiculo para una variable de tipo Rodable ya que Vehiculo no implementa dicha interfaz, si lo hacemos obtendremos un error indicando que existen tipos incompatibles en el código.

Es todo lo que veremos sobre polimorfismo. ¿Alguna duda? deja tu comentario.

Más sobre programación en Java aquí.

Encapsulamiento en Java


Anteriormente hemos hablado del encapsulamiento sin ahondar mucho en el tema. En este artículo vamos a profundizar un poco más.

Imaginemos que se crea una clase, una docena de programadores tienen acceso a dicha clase y la utilizan a discreción, posteriormente dicha clase comienza a comportarse de una manera inesperada debido a que los valores que algunas variables han tomado no fueron anticipados y todo comienza a desmoronarse. Para corregir el problema se crea una versión más nueva de dicha clase y listo.

Bueno, a esto le llamamos flexibilidad y capacidad de mantenimiento, ambas son características y beneficios de la programación Orientada a Objetos (OO) pero para que una clase pueda cumplir dichas funciones los programadores debemos de hacer algo. Imaginemos que creamos una clase con variables de instancia públicas a las cuales podemos acceder sin problemas desde fuera de la misma clase...

public class MiClase{
public int tipo;

}


class AccesoDirecto{

public static void main(String[] args){

MiClase mc = new MiClase();


mc.tipo = -5; //1

}
}


Analizando el código anterior podemos darnos cuenta de que las variables enteras tipo y clase son públicas y pueden ser accedidas directamente a través de una instancia de la clase MiClase, esto compila sin ningún problema, digamos que es 'legal', sin embargo, ¿qué pasa si ingresamos un valor que no se supone debe de tener una variable (en este caso el -5 que le asignamos a tipo)?, simplemente no hay nada que nos detenga para hacerlo. La única manera de proteger el código es escribiendo un método que nos permita regular los valores que cada variable puede tener y escondiendo las variables para que no se pueda acceder a ellas de manera directa, esto es el principio básico de encapsulamiento.

Si se desea flexibilidad, buen mantenimiento y extensibilidad, nuestro diseño en el código debe de incluir encapsulamiento, para ello debemos de hacer lo siguiente:

* Mantener las variables de instancia protegidas (puede ser con un modificador de acceso, p.ej., private)
* Hacer métodos de acceso públicos para forzar al acceso a las variables por medio de dichos métodos en lugar de acceder directamente.
* Utilizar las convenciones de código para los nombres de los métodos, p. ej., set y get.

El ejemplo anterior modificado para un buen encapsulamiento quedaría así:

public class MiClase{
private int tipo;

public void setTipo(int t){
tipo = t;
}


public int getTipo(){

return tipo;

}

}


class AccesoIndirecto{


public static void main(String[] args){
MiClase mc = new MiClase();

mc.setTipo(5);
System.out.println("El tipo es:" + mc.getTipo());

}


}


Si nos fijamos un poquito, en el método setTipo() no existen validaciones para prevenir que un valor no válido sea asignado a la variable, sin embargo, el proveer de un método de este tipo desde el diseño inicial de la aplicación nos permite posteriormente modificar el comportamiento de la misma sin afectar los métodos utilizados, tal vez en un futuro se desee que dicha variable solamente pueda tener uno entre un rango de valores y se podrán aplicar posteriormente los cambios sin que haya repercusiones negativas.

Esto es todo con respecto al encapsulamiento. ¿Alguna duda? deja tu comentario.

Más sobre programación en Java aquí.

El pájaro más listo del mundo!

Los pájaros no podrían quedarse atrás en esta batalla por decidir qué animal es el más listo del mundo. Este perico es simplemente sorprendente...


Si quieres ver más videos interesantes da clic aquí...

El perro más inteligente del mundo...

Este sí es un perro inteligente, hace de todo para sacar la pelota sin mojarse. Seguramente es más inteligente que muchos de sus amigos gringos.

Si quieres ver más videos interesantes da clic aquí...

Convertir archivos de audio y video a diferentes formatos.

Últimamente se está dando mucho la necesidad de convertir archivos de audio y video desde y hacia diferentes formatos (mpeg, avi, wmv, 3gp, mp3, ogg, mp4, etc). Lo cierto es que la gran mayoría de las aplicaciones dedicadas a esto son alguna o varias de las siguientes cosas:

- No son gratuitas.
- Tienen funcionalidad muy limitada.
- Solo convierten ciertos tipos de archivos.
- No permiten extraer el audio solamente de un video.
- Son tardadas.
- etc.

Hace ya algún tiempo compré un psp (que posteriormente vendí) y estuve buscando alguna aplicación que me permitiera convertir mis videos en formato avi o mpeg a mp4 que era lo que dicho aparatito reproducía y me encontré (después de mucho batallar con aplicaciones molestas) con Super.

Super es una aplicación freeware (osea, gratis) que permite realizar la conversión entre audio y video desde cualquier formato hasta cualquier formato, incluso te permite seleccionar el códec de salida, la resolución, extraer solo el audio o el video, etc. Es ideal para convertir videos y reproducirlos en tu celular, psp o ipod, incluso puede convertir sin problemas los videos en formato flv que se pueden descargar de Youtube. El único inconveniente al momento de descargar Super es que la liga de descarga está un poco escondida en el sitio pero con un poquito de esfuerzo se descarga sin problemas.

Os dejo una captura de pantalla.

Los tipos enumerados (enums) en Java

Tipos Enumerados

En Java 5 se permite que una variable tenga solo un valor dentro de un conjunto de valores predefinidos, en otras palabras, valores dentro de una lista enumerada. Los tipos enumerados sirven para restringir la selección de valores a algunos previamente definidos, p. ej., si tenemos una aplicación para la venta de café en vasos de diferentes tamaños pero no queremos que los tamaños sean diferentes a CHICO, MEDIANO y GRANDE, podemos crear un tipo enumerado para delimitar dicha selección:


enum TamanoDeCafe{CHICO,MEDIANO,GRANDE};

Clases en Java parte 2

Declarar miembros de una clase::

Debido a que las variables y los métodos dentro de una clase utilizan el mismo control de acceso, se tratará a ambos de la misma manera cuando hablemos de los modificadores de acceso.

Mientras que una clase solamente puede utilizar 2 niveles de acceso (público y por defecto), los métodos y variables pueden usar los 4 que son:

+ público (modificador public)
+ por defecto (cuando se omite algún modificador)
+ protegido (modificador protected)
+ privado (modificador private)

Al hablar de que la clase A tiene acceso a un miembro de la clase B (independientemente si es una variable o método) decimos implícitamente que el miembro de B al que se está accesando es 'visible' para A. Cuando se trata de acceder a un miembro que no es visible, el compilador mandará un error y no se podrá ejecutar la aplicación. Para poder entender el comportamiento y acceso de ciertos miembros de una clase debemos entender 2 cosas:

+ Cuándo una clase puede acceder a un miembro de otra.
+ Cuándo una clase puede heredar a otra algún miembro.

Lo primero se refiere a cuando una clase puede acceder al miembro de otra clase por medio del operador punto (.), ya sea para invocar un método o retribuir el valor de una variable. P. ej.:

package paqueteUno;

public class ControlAcceso {

public static void main(String[] args)
{
MiembrosDeClase mdc = new MiembrosDeClase();

System.out.println("Default: "+ mdc.enteroPorDefecto);
System.out.println("Protected: "+ mdc.enteroProtegido);
System.out.println("Default: "+ mdc.enteroPublico);
System.out.println("Private: "+ mdc.enteroPrivado); //1
}
}

class MiembrosDeClase{
public int enteroPublico = 1;
protected int enteroProtegido = 2;
private int enteroPrivado = 3;
int enteroPorDefecto = 4;
}

Si compilamos el código anterior, al llegar a la línea 1, el compilador mandará un error debido a que se quiere acceder a una variable privada desde otra clase...

ControlAcceso.java:26: enteroPrivado has private access in paqueteUno.MiembrosDeClase
System.out.println("Private: "+ mdc.enteroPrivado);
1 error

Si quitamos el código que manda a llamar la variable enteroPrivado no aparecerán errores al momento de compilar y se imprimirán los valores de las variables sin problemas:

Default: 4
Protected: 2
Default: 1

En caso de querer ver el valor de las variables desde una clase fuera del paquete paqueteUno, solo podremos acceder a aquellas marcadas como públicas y protegidas, ya que el control de acceso por defecto solamente proporciona visibilidad a aquellas clases dentro del mismo paquete y los miembros privados solamente pueden ser accedidos desde la misma clase que los define, en pocas palabras:

+ Acceso público (modificador public): Cualquier clase dentro del universo de Java podrá tener acceso a un miembro público.

+ Acceso por defecto (cuando se omite algún modificador): Solamente se podrá acceder a dicho miembro si se pertenece al mismo paquete.

+ Acceso protegido (modificador protected): Solamente se podrá acceder a un miembro protegido cuando se está en el mismo paquete o a través de la herencia.

+ Acceso privado (modificador private): Solo se puede acceder dentro de la misma clase.


Acceso a variables locales::

Las variables locales son aquellas que están declaradas dentro de un método, las variables de instancia son aquellas dentro de la clase pero fuera de los métodos. P.ej.:

public class Variables{
int variableDeInstancia = 1;

public void verVariables(){
int variableLocal = 0;
}
}

Es importante tomar en cuenta que las variables de instancia pueden controlar su acceso con los modificadores que hemos visto anteriormente, sin embargo, las variables locales no, al intentar hacerlo el compilador mandará un error. P.ej.:

public class Variables{
private int variableDeInstancia = 1; //no hay problema

public void verVariables(){
protected int variableLocal = 0; //error!
}
}

El único modificador aplicable a una variable local es final.

Métodos y variables finales::

Anteriormente hemos mencionado cómo es que se comporta una clase marcada con el modificador final, ahora es el turno de los miembros de una clase.

Al marcar un método con el identificador final estamos indicando (al igual que en las clases) que dicho método no puede ser sobreescrito, sino que debe de quedarse tal cual se definió originalmente. P.ej.:

class SuperClase{

public final void metodoFinal(){
//hacer algo
}

}

class SubClase extends SuperClase{

public void metodoFinal(){
//hacer otra cosa
}

}

Al tratar de compilar el código anterior, aparecerá un error que indica que no se puede sobreescribir el método final...

FinalTest.java:5: The method void metodoFinal() declared in class
SubClase cannot override the final method of the same signature
declared in class SuperClase.
Final methods cannot be overridden.
public void metodoFinal() { }
1 error

Así como los métodos, las variables pueden utilizar el modificador final, en su caso, al declarar una variable final significa que no se puede cambiar su valor una vez que fue asignado. P. ej.:

class EjemploVariableFinal{

final int f = 4;

public void cambiarValor(){
f +=2; //error!
}

}

En el código anterior, se define y asigna un valor a la variable final f, posteriormente el método cambiarValor() intenta incrementar el valor de f, al momento de llegar a esta línea, el compilador arrojará un error indicando que no es posible reasignar un valor a una variable final.

Es importante mencionar que cuando se trata de una variable de instancia final(dentro de la clase pero fuera de un método), antes de compilar, se debe de definir su valor, de lo contrario, aparecerá un mensaje de error indicando que no ha sido inicializada, no así con las variables locales.

Métodos abstractos::

Un método abstracto es aquel que se define dentro de una clase pero no se especifica su comportamiento, en lugar de utilizar llaves para definir el código de su comportamiento de finaliza su declaración con un punto y coma (;). Se definen métodos abstractos cuando se quiere forzar a todas las clases que heredan de la clase que tiene dicho método a implementar cierto comportamiento. P. ej.:

public abstract void metodoAbstracto();

Cuando se define al menos un método abstracto dentro de una clase, la clase debe a su vez ser abstracta, de lo contrario el compilador arrojará un error. Asimismo, una clase abstracta podrá no tener ningún método abstracto. Una clase que herede a otra clase abstracta, debe de implementar todos los métodos abstractos de la clase heredada, a menos de que la clase que está heredando sea a su vez abstracta. La regla es la siguiente:

"La primera clase no abstracta que herede a una clase abstracta deberá definir todos los métodos abstractos que le han sido heredados".

En caso de que una clase no abstracta no implemente los métodos abstractos definidos en su superclase habrá un error de compilación.

Por último, nunca se debe de utilizar el modificador abstract con el modificador static...

abstract static void metodo();

...ya que de igual manera habrá un error al momento de compilar.

Hasta aquí le dejamos con este tema. ¿Alguna duda? deja tu comentario.

Más sobre programación en Java aquí.

Clases e interfaces en Java

Cuando se escribe código en Java, se están escribiendo clases e interfaces. Dentro de dichas clases, los métodos y las variables, además de algunas otras pocas cosas. El cómo se declaran las clases, interfaces, métodos y variables afecta dramáticamente el comportamiento del código. Por ejemplo, un método marcado como público (public) puede ser accesado desde cualquier parte de la aplicación, no así cuando es privado (private). Analicemos entonces poco a poco la declaración de clases en Java.

Reglas para declarar archivos fuente::

Antes de infiltrarnos en el extenso mundo de las clases, veamos una serie de reglas importantes asociadas con la declaración de clases, sentencias import y package en un código fuente:

+ Sólo puede haber una clase pública por cada archivo fuente.
+ Los comentarios pueden aparecer en el principio o final de cualquier línea de código, son independientes de las reglas que se mencionan.
+ Si existe una clase pública en un archivo, el nombre del archivo debe de coincidir con el nombre de dicha clase.
+ Si una clase es parte de un paquete, la sentencia package debe de aparecer en la primera línea de código, antes de cualquier sentencia import o declaración de clases y métodos.
+ Si existen sentencias import, debe de aparecer después de la declaración del paquete (en caso de haber alguno) y antes de la declaración de la(s) clase(s). Si no hay una declaración de paquete, la sentencia import debe de ser la primera en aparecer en el código. Si no hay sentencias package o import, la declaración de la clase debe de aparecer primero.
+ Las declaraciones de paquete e import aplican para todas las clases nombradas en un archivo, no es posible tener varias clases en un archivo y que cada clase pertenezca a un paquete diferente o utilice diferentes import's.
+ Un archivo puede tener más de una clase NO pública.
+ Un archivo sin clases públicas puede tener cualquier nombre, aunque no coincida con el nombre de ninguna de sus clases.

Declaraciones de clases y modificadores::

La declaración general de una clase se hace de la siguiente manera:

class NombreDeMiClase { }

Además de lo anterior puedes agregar modificadores antes del nombre de la misma. Los tipos de modificadores (no todos aplicables a una clase) son:

1. Modificadores de acceso: public, protected, private.
2. Modificadores que no son de acceso: strictfp, final y abstract.

Los modificadores de acceso nos ayudan a restringir-permitir el acceso a una clase, métodos, variables, etc. que se ha creado. Existen 4 niveles de acceso pero solo 3 modificadores de acceso, el cuarto nivel de acceso que no está representado con ningún nombre de modificador es aquel que se obtiene cuando no estableces ningún modificador de acceso (llamado el acceso por defecto o default). En otras palabras, todas y cada una de las clases y componentes de las mismas en Java tienen control de acceso, independientemente si lo estableces manualmente o no.

Acceso a las clases::

Qué significa acceder a una clase? Cuando decimos que el código de una clase A tiene acceso a otra clase B, significa que A hizo una de tres cosas:

+ Creó una instancia de la clase B.
+ Extendió o heredó a la clase B (A es una subclase de B).
+ Accedió a ciertos métodos dentro de la clase B, dependiendo del control de acceso de dichos métodos y variables.

Acceso significa 'visibilidad'. Para que A pueda usar el código de B tiene que poder 'verlo', para ello son los modificadores de acceso que describiré a continuación:

Acceso por defecto (modificador default): Una clase con control de acceso por defecto significa una de dos cosas:

+ Se omitió la especificación de un modificador de acceso.
+ Se escribió la palabra default como modificador de acceso.

El control de acceso por defecto brinda un control a nivel de paquete, es decir, solo las clases dentro del mismo paquete podrán acceder a los métodos, variables y demás cuestiones definidas dentro de la clase. P. ej.: Si A está en el paquete Uno y B está en el paquete Dos, entonces no hay manera de que B sepa de la existencia de A cuando A tiene control de acceso por defecto. Si se trata de utilizar una A dentro de B, el compilador arrojará un error.

Acceso público (modificador public): Una declaración de una clase pública proporciona el acceso a todas las clases de todos los paquetes, todas las clases en el Universo Java (JU) tienen acceso a una clase pública. No debemos olvidar que, aunque se trate de una clase pública, aún necesitamos importar el paquete en el que se encuentra (en caso de que tratemos de acceder a ella desde un paquete distinto) para que podamos utilizarla. P. Ej.:

Código de la clase MiClaseA:---

package paqueteUno;

public class MiClaseA {
//métodos y comportamiento de la clase
}

Código de la clase MiClaseB:---

package paqueteDos;

import paqueteUno.MiClaseA;

public class MiClaseB{
//métodos y comportamiento de la clase
}

Es importante mencionar que en el código de MiClaseB podemos sustituir import paqueteUno.MiClaseA; por import paqueteUno.*; para poder así importar todas las clases dentro de paqueteUno.

Otros modificadores::

Existen otros modificadores que no controlan el acceso a la clase pero sí el cómo es que esta se comporta al momento de ser extendida o instanciada. Estos modificadores son: final y abstract. Analicemos un poco la función de cada uno de ellos.

Nota: el modificador strictfp es utilizado muy pero muy poco y no es de suma utilidad, por lo cual no ahondaremos en describir su función.

Clases finales (modificador final): Cuando el modificador final es utilizado en la declaración de una clase, significa que dicha clase no puede ser heredada, es decir, que no puede haber subclases de dicha clase, y para utilizarla debemos de crear una instancia de la misma. Esto se utiliza normalmente cuando queremos que los métodos y función de nuestra clase se queden tal como están, sin que haya otra clase que herede el comportamiento de la que acabamos de definir ni pueda sobreescribir los métodos que contiene. Muchas clases en Java son finales, un ejemplo es la clase String que no puede ser heredada, imaginemos un poco la situación en caso de que pudieramos sobreescribir los métodos de la importantísima clase String, si lo hacemos de manera irresponsable estaríamos afectando el comportamiento tal vez no solo de una clase o una aplicación, sino de todas aquellas clases que utilicen los métodos definidos por String.

Clases abstractas (modificador abstract): Contrario al modificador final, abstract indica que una clase no puede ser instanciada sino que su única razón de existir es ser heredada. Un ejemplo de la utilidad de una clase abstracta podría ser la clase Carro, sabemos que todos los carros tienen características generales que los describen, sin embargo, existen ciertas cosas que distinguen a uno de otro, como la marca, modelo, número de vehículo, etc. Por ello, podríamos definir una clase abstracta Carro, que define métodos y variables que cualquier carro puede poseer pero que necesita de alguna otra información que distinga a un carro de otro.

En este punto es importante hablar un poco más a fondo de las interfaces, anteriormente he mencionado información general sobre ellas pero ahora que hemos tocado el modificador abstract es posible que las interfaces se vuelvan un poquito más fáciles de entender.

Interfaces::

Una interfaz es una plantilla que define métodos acerca de lo que puede o no hacer una clase, se puede definir meramente como una clase abstracta al 100%, por ejemplo, si definimos la interfaz Animal, podremos deducir que todos los animales pueden comer, respirar, etc. pero puede ser que cada uno lo haga de manera diferente, por ello, en la interfaz definimos el comportamiento que todos los animales pueden tener pero no el cómo hacen las cosas ya que cada animal lo realiza de manera diferente. En código se traduce así:

interface Animal{
void comer();
int respirar();
}

class Perro implements Animal{

public void comer(){
//definimos cómo come el perro
}

public int respirar(){
//definimos cómo respira el perro
}

public String ladrar(){
//definimos un método exclusivo del perro
}

}

Como podemos observar en el código anterior, en la interfaz existen un par de métodos que definen lo que cualquier animal puede hacer, pero no especificamos cómo es que lo hace, dentro de la clase Perro que implementa la interfaz Animal es que hemos sobreescrito los métodos que se definieron en la interfaz y le dimos un comportamiento un poco más específico de un perro, así mismo, creamos el método ladrar() en el cual se describe cómo es que un perro ladra, dicho método no fue definido en la interfaz Animal por que no todos los animales ladran.

Es importante mencionar algunos puntos importantes con respecto a las interfaces:

+ Todos los métodos de una interfaz son abstractos y deben de ser sobreescritos por la clase que implemente dicha interfaz, asimismo, todos los métodos de una interfaz son públicos, independientemente si se ha especificado manualmente o no con los modificadores public y abstract.
+ Todas las variables contenidas en una interfaz deben ser públicas, estáticas y finales, no existen variables de instancia dentro de una interfaz.
+ Los métodos de una interfaz NO deben ser estáticos.
+ Debido a que los métodos de una interfaz son abstractos, NO deben ser marcados finales.
+ Una interfaz puede extender una o más interfaces.
+ Una interfaz no puede extender o heredar nada que no sea una interfaz.
+ Una interfaz no puede implementar nada.
+ Una interfaz se define con la palabra interface.
+ Las interfaces pueden usadas polimórficamente.

Declarar constantes dentro de interfaces::

Es posible alojar constantes dentro de las interfaces, al hacerlo, se garantiza que todas las clases que implementen dicha interfaz tendrán acceso a la misma constante. Al momento de declarar una constante, esta implícitamente es pública, estática y final, aunque no se especifíque manualmente con los modificadores public, static y final, debido a lo anterior, es imposible cambiar el valor de una constante declarada dentro de una interfaz, al intentar hacerlo, el compilador arrojará un error. P. ej.:

interface MiInterfaz{
int CONST = 12;
void hacerAlgo();
}

class MiClase implements MiInterfaz{
public void hacerAlgo{
CONST = 14;//al llegar a esta línea aparecerá el error
}
}

Hasta aquí le dejamos en este artículo. ¿Alguna duda? Deja tu comentario.

Más sobre programación en Java aquí.

La Miss Teen USA Carolina del Sur

Y luego por qué decimos que la belleza y la inteligencia están peleadas, esta bonita señorita cantinfleó de tal manera que ni ella misma supo lo que dijo, lo bueno es que sus paisanos gringos comparten su nivel de inteligencia en su gran mayoría.

Soneto XXV

Antes de amarte, amor, nada era mío:
vacilé por las calles y las cosas:
nada contaba ni tenía nombre:
el mundo era del aire que esperaba.

Yo conocí salones cenicientos,
túneles habitados por la luna,
hangares crueles que se despedían,
preguntas que insistían en la arena.

Todo estaba vacío, muerto y mudo,
caído, abandonado y decaído,
todo era inalienablemente ajeno.

Todo era de los otros y de nadie,
hasta que tu belleza y tu pobreza
llenaron el otoño de regalos.

Pablo Neruda

Los gringos NO son estúpidos. O sí???

A raíz del video visto ayer acerca del culto gringo Glenn Beck con su memorable mensaje al presidente Felipe Calderón me surgieron algunas dudas, ¿será que todos los gringos son igual de tontos que este? o ¿será nuestro amigo Glenn el único?, bueno, las respuestas a tan intrigantes preguntas las ha resuelto un video de Youtube, desafortunadamente no encontré alguno con subtítulos en español pero espero que entiendas un poco el idioma. Juzgad por vosotros mismos.

Actualización 18/01/08:::

He encontrado el video subtitulado. Disfrutadlo.

Mensaje de Glenn Beck al presidente Felipe Calderon

Comentario original del mail donde recibí este video:

"Para variar creo que nuestros gobernantes solo se haran mensos y no diran ni pio.
Este monigote ignoro cual sea su dolo o que se crea, pero es evidente que de frente ante un mexicano se hara del baño y terminara por pedir una riata charra.
Que razonen es algo que no se les da. No puedo pedir imposibles a quienes por disposicion global debieramos pintarle un simbolo de discapacitados en su bandera, en lugar de tantas estrellas. Las lineas rojas podrian servir para envolver el signo y las estrellas para decirle a todos, que si bien los latinos buscan ir hacia su nacion, es tambien cierto que ellos necesitan mas de nuestras micro economias que nosotros de su estupida presencia. Y que si cada estrella representa un estado de la union americana, entonces la discapacidad mental es nacional".

Es tiempo de decir YA BASTA gringuitos, creen que por que están un poco más al norte están por encima de cualquier otra nación y pueden pisotear a quien deseen. Si no fuera por la mano de obra latina su país desde hace mucho se hubiera ido al carajo tal como está empezando en este año, con un dólar más pequeño frente al euro e incluso frente al dólar canadiense. No son más que nadie pero sus pocas neuronas en el cerebro no les alcanzan para entender eso y luego se preguntan el por qué naciones completas les tienen un odio inmenso y les andan tumbando las torres cuando ellos mismos crean una cultura anti-gringos con sus comentarios idiotas que no hacen más que dejar ver su inmensa ignorancia y poca (ma..) conciencia como país.

Clases internas en Java(Inner/nested classes) 2

Clases internas de métodos locales::

Una clase interna regular se encuentra dentro de la clase pero afuera de cualquier método de dicha clase. En Java existe lo que llamamos clases internas de métodos locales, las cuales pueden ser definidas dentro de los métodos como se muestra en el siguiente ejemplo:

public class Externa2 {

private String x = "Externa2";

void hacerAlgo(){
class Interna{
public void verExterna(){
System.out.println("La variable x es: " + x);
}//cerramos el método de la clase interna
}//cerramos la clase interna
}//cerramos el método local de la clase externa
}//cerramos la clase externa

El código anterior declara una clase Externa2, con una variable privada de tipo cadena que contiene la palabra "Externa2" y un método llamado hacerAlgo(), dentro de dicho método se define una clase interna de método local de nombre Interna que a su vez tiene un método llamado verExterna() que nos permite ver el contenido de la variable x imprimiéndolo en pantalla.

De cualquier manera el código anterior es legal pero inútil ya que nunca instanciamos la clase Interna y por lo tanto no podemos acceder su método definido. Si queremos utilizar la clase Interna definida anteriormente debemos de crear una instancia de dicha clase dentro del método pero debajo de la definición de la clase como se muestra en el siguiente código:

public class Externa2 {

private String x = "Externa2";

void hacerAlgo(){
class Interna{
public void verExterna(){
System.out.println("La variable x es: " + x);
}//cerramos el método de la clase interna
}//cerramos la clase interna
Interna i = new Interna();
i.verExterna();
}//cerramos el método local de la clase externa
}//cerramos la clase externa

Una clase interna de un método local puede ser instanciada solo dentro del método donde la clase interna fue definida. Una clase interna no puede utilizar las variables locales del método en el cual está definida, si se trata de utilizar alguna se obtendrá un error al compilar más o menos así:

local variable z is accessed from within inner class;
needs to be declared final

Deducimos entonces que sí es posible utilizar una variable local dentro de una clase interna de método local, pero solamente si dicha variable está marcada como final, por lo tanto, no podremos cambiar su contenido sino solamente utilizarlo o imprimirlo. Una clase interna de método local no puede ser marcada con public, protected, private, static, transient o algo por el estilo, solamente puede ser final o abstracta pero no ambas al mismo tiempo.

Clases internas anónimas::

Existen algunas clases internas en Java a las cuales no es necesario nombrar, pueden ser declaradas no solo dentro de un método sino dentro de un argumento para un método. Veamos el código:

public class ClaseAnonima {

Comida c = new Comida(){
public void comer(){
System.out.println("Clase comida anónima");
}
};
}

class Comida{
public void comer(){
System.out.println("Comiendo");
}
}

¿Qué fue lo que hicimos aquí?:
+ Definimos 2 clases, ClaseAnonima y Comida.
+ La clase comida tiene el método comer().
+ ClaseAnonima tiene una variable de instancia de Comida.
+ La ClaseAnonima no tiene métodos.

La variable de instancia de Comida no hace referencia a una instancia de Comida sino a una clase anónima que es una subclase de Comida. Veamos el código de la clase anónima solamente:

Comida c = new Comida(){
public void comer(){
System.out.println("Clase comida anónima");
}
};

La declaración de la variable de instancia c no termina con un punto y coma(;) sino con una llave abierta({), al final se cierra la declaración de la clase anónima con una llave cerrada(}) seguida de un punto y coma(;).

Se puede utilizar lo mismo con interfaces, solo que al utilizarlo con una interface anónima no se extiende la interface de la cual se está creando sino que se implementa. P. ej.:

interface Cocinable{
public void cocinar();
}

class Comida{
Cocinable co = new Cocinable(){
public void cocinar(){
System.out.printl("Implementación anónima de la interfaz Cocinable");
}
};
}

Aunque parece que la interface está siendo instanciada, no es así. Todas las interfaces son abstractas, por lo tanto, no se pueden instanciar, aunque en el código anterior lo parezca.

Hasta aquí llegamos con clases internas en Java. ¿Alguna duda? deja tu comentario.

Más explicaciones de Java aquí...
 
Monillo007 © 2010 | Designed by Trucks, Manual Bookmarking | Elegant Themes