Terminos que deben(mos) conocer.
Como parte de la segunda clase del PCJ el M Daniel Ramos nos pidió que investigáramos los siguientes términos ( el contexto es Ingeniería del Software por lo que "herencia" no es lo que deja el tío rico McPato al morir )
-
Abstracción - Abstracto
AccesorsAcoplamientoAPICohesión- Concreto
- Contexto
EncapsulamientoFirma- Herencia
- Implementación
- Interface
JavaBean- Lenguaje de Modelado
MensajeMutatorsParadigmaPolimorfismoProgramación Orientada a ObjetosUML
¿Quién quiere participar?. Un término por respuesta. No contesten duplicadas excepto si la anterior es flagrantemente incorrecta.
- Inicie sesión o regístrese para enviar comentarios
API
Application Programming Interface. Normalmente consiste en una serie de interfaces y clases (junto con su documentación), o al menos de una serie de definiciones y especificaciones, para poder invocar cierta funcionalidad de algún sistema desde otro sistema, o de un subsistema de un sistema. Ejemplos: el API de Java para criptografía, el API de Twitter...
Abstracción
Abstracción
La abstracción facilita la fácil conceptualización de los objetos del mundo real, eliminando los detalles innecesarios del objeto.
Una de las formas fundamentales en la cual nosotros manejamos la complejidad es la abstracción. Una abstracción denota las propiedades esenciales y comportamientos de un objeto que lo diferencian de otro. La esencia de POO es modelar abstracciones usando clases y objetos. La parte difícil es encontrar la abstracción correcta.(Khalid A. Mughal)
Mensaje
Dícese del proceso mediante el cual un objeto le envía datos a otro.
En la programación orientada a objetos, los datos y la forma de manipularlos son modelados como si fueran objetos del mundo real ( por eso es "orientado a objetos" ) La forma en la que tienen los objetos de comunicarse es mandándose "mensajes".
Los objetos tienen datos ( llamados atributos en OOP ) y funciones ( llamados métodos en OOP ) para modificar o acceder a esos datos.
Cuando un objeto le pide a otro que invoque un método, le está mandando un mensaje.
Por ejemplo, si se hiciera un programa que llevara el registro de visitantes que llegan a una biblioteca, el programa podría tener una lista donde ir almacenando las visitas y podría borrarlos todos los días para almacenar a los nuevos visitantes.
En vez de que el programa borre el contenido él mismo, podría mandarle el mensaje "limpiar" ( o clear ) a la lista.
En Java se vería así:
Los mensajes por supuesto pueden recibir argumentos. En el mismo programa para registrar un nuevo visitante se puede mandar el mensaje add al objeto listaVisitantes
:)
Accesor (Metodo Accesor)
En programacion orientada a objetos un accesor es un metodo que por lo general tiene el unico proposito de dar "acceso" al estado interno de un objeto, desde otros objetos o partes de un programa. Crear metodos accesores es una practica comun cuando se utilizan tecnicas de encapsulamiento para ocultar el estado de un objeto y solo se desea exponer una interfaz muy especifica para recuperar o manipular el estado de un objeto..
En Java tenemos los famosos getters y setters que pueden ser creados de manera manual, automatizada con ayuda de un IDE o inclusive talves con alguna anotacion especial.
Lenguaje UML
Unified Modeling Language (Lenguaje Unificado de Modelado) es el lenguaje para modelado de sistemas de software más utilizado y reconocido en estos tiempos. En términos generales se utiliza para crear diagramas que permitan visualizar, especificar, desarrollar y documentar un sistema. UML se basa primordialmente en la descripción gráfica de "planos" (modelos) de negocio o sistema, incluyendo aspectos conceptuales como procesos y funciones críticas de negocio; al igual que aspectos concretos como esquemas de base de datos, diagramas de objetos complejos, etc.
¿vale preguntar por un posible concepto?
Si se vale preguntar ¿existe el concepto de contrato?
Según veo en google aparece el concepto de "diseño por contrato" que suena algo avanzado pero ¿se utiliza la palabra 'contrato' para definir algo mas en la POO?
Esta duda me surge recordando los comentarios de alguien conocido que apenas estaba aprendiendo a programar ... y aprendiendo utilizando java en su universidad y siempre mencionaba que debía cumplir el contrato ¿del enunciado?... es que supongo que al ser una persona novata el concepto de "diseño por contrato" debería ser desconocido por ella.
Pues es una duda, puede ser equivocada pero aprovecho para lanzarla. Un saludo.
Mutators
Los mutators son métodos que modifican un atributo, en pocas palabras, es lo que conocemos comúnmente como los setters, que son métodos que permiten modificar atributos que por lo regular siempre son privados.
Design by contract
Creo que sitios de este tipo deben promover más la discusión de conceptos, que son los que aseguran que nuestros programas estén bien escritos. El código debe "cortarse" con cuhillos bien afilados y el filo depende del conocimiento de los conceptos que sustentan la programación, por lo que es muy bueno preguntar por conceptos.
La idea del diseño basado en contratos es muy vieja en programación, aunque es Bertrand Meyer, creador del lenguaje Eiffel el que la hace popular. De hecho, "Design by Contract" es su marca registrada.
Se trata de una forma de asegurar si nuestros programas son correctos, introduciendo en la programación conceptos que en los contratos de la vida real aparecen. Tres de esos conceptos importantes son: las precondiciones, las postcondiciones y las invariantes y la introducción de esos tres conceptos en el lenguaje mediante las aserciones (palabra que no existe en español, pero que persigue algo similar al assert de Java). el diseño por contratos tiene mucho que ver con algo que se conoce como programación defensiva.
Los conceptos de precondiciones y postcondiciones fueron presentados incialmente por Tony Hoare (premio Turing de computación) hace ya 40 años. Hoare es muy conocido por haber inventado el algoritmo Quicksort.
El primer lenguaje que llevó esos conceptos a la programación fue CLU de Barbara Liskov (premio Turing the computacion) en los años 70's. El principio LSP (Liskov substitution principle) es muy conocido en la programación orientada a objetos y sirve como fundamento para diseñar y programar jerarquías correctas de clases.
El diseño por contratos establece como premisa que siempre en un programa hay un componente (objeto, etc.) que pide un servicio y hay un componente que brinda otro servicio. El primero es el cliente y el segundo es el servidor.
Como todo contrato en la vida real, el cliente debe cumplir con ciertos requisitos para solicitar el servicio: debe satisfacer las PRECONDICIONES del servicio. El servidor está obligado a satisfacer el servicio y eso lo demuestra cumpliendo con las PRECONDICIONES.
Los servicios que ofrece el servidor pueden ser variados, y entonces serán varias las precondiciones y las postcondiciones. Sin embargo, conviene especificar qué cosas no cambian y que son independientes del tipo de servicio: esas son las INVARIANTES del servicio.
Hay varias implementaciones en Java del Diseño por Contratos. Por supuesto que la mejor manera de entenderlo es en el lenguaje Eiffel. Por supuesto, para eso habría que saber leer un poco algunos programas escritos en Eiffel, pero quien sabe programación orientada a objetos lo puede lograr en poco tiempo. Convien también un vistazo a JML: Java modeling Language.
Algunas ligas para leer sobre el tema ( en inglés; en español, El Quijote)
Applying Design By Contract
Design by Contract with JML
Java Modelling Language Homepage
Saludos,
Bárbaro
Paradigma
En programación, es el método que usa el código de un lenguaje.
Y en como el el contexto es Ingeniería del Software, entonces sería la metodología que se emplea para llevar a cabo un proyecto ¿no ?.
Por ejemplo: UML (casos de uso)
Firma
En programación, y sobre todo en los lenguajes de programación que soportan la sobrecarga (overloading) de funciones o métodos, la FIRMA se refiere a la forma de identifcar de manera unívoca a un método o función. Casi todos los lenguajes incluyen en la FIRMA al nombre de la función y a la lista de sus argumentos y mediante un proceso conocido como Name Mangling distinguen a funciones con el mismo nombre pero con diferente lista de argumentos.
Generalmente el tipo de retorno no se incluye en la firma, sobre todo en aquellos lenguajes que permiten un casting implícito en la asignación del resultado de una función a una variable.
La FIRMA de la función sirve también para indicar de manera breve el uso que podemos hacer de ella. Algunos lenguajes se refieren a eso como el prototipo de la función cuando incluyen también el tipo de retorno de la función. Se dice por ejemplo, que los archivos de encabezados en C están compuestos, entre otras cosas por prototipos de las funciones que se implementan en algunos de los módulos almacenados en las bibliotecas del lenguaje.
Contrato
Una versión muy simple de contratos en Java son las interfaces, porque una interfaz es solamente la definición de una serie de métodos que un objeto debe implementar si quiere anunciar que la implementa. Ejemplo: la interfaz Runnable define el método run(); puedes implementar el método run() en una clase tuya y no ponerle "implements Runnable" y no pasa nada, pero los otros objetos no saben que implementas Runnable; si le pones "implements Runnable" cualquier objeto que sepa hablar con un Runnable puede hablar con tus objetos. Pero no puedes ponerle a tu clase "implements Runnable" y NO implementar el método run() (a menos que sea una clase abstracta, en ese caso le estás dejando la bronca a las implementaciones concretas).
muy bien :-D , creo que este
muy bien :-D , creo que este concepto de contrato corresponde mas con lo que mi amiga conocida que se iniciaba en programación podría manejar.
Muchas gracias por la ayuda ezamudio, igualmente muchas gracias bferro :-)
Un saludo.
La palabra polimorfismo
La palabra polimorfismo proviene del griego y significa que posee varias formas diferentes. Este es uno de los conceptos esenciales de una programación orientada a objetos. Así como la herencia está relacionada con las clases y su jerarquía, el polimorfismo se relaciona con los métodos.
En general, hay tres tipos de polimorfismo:
* Polimorfismo de sobrecarga
El polimorfismo de sobrecarga ocurre cuando las funciones del mismo nombre existen, con funcionalidad similar, en clases que son completamente independientes una de otra (éstas no tienen que ser clases secundarias de la clase objeto). Por ejemplo, la clase complex, la clase image y la clase link pueden todas tener la función "display". Esto significa que no necesitamos preocuparnos sobre el tipo de objeto con el que estamos trabajando si todo lo que deseamos es verlo en la pantalla.
* Polimorfismo paramétrico (también llamado polimorfismo de plantillas)
El polimorfismo paramétrico es la capacidad para definir varias funciones utilizando el mismo nombre, pero usando parámetros diferentes (nombre y/o tipo). El polimorfismo paramétrico selecciona automáticamente el método correcto a aplicar en función del tipo de datos pasados en el parámetro.
Por lo tanto, podemos por ejemplo, definir varios métodos homónimos de addition() efectuando una suma de valores.
* El método int addition(int,int) devolvería la suma de dos números enteros.
* float addition(float, float) devolvería la suma de dos flotantes.
* char addition(char, char) daría por resultado la suma de dos caracteres definidos por el autor.
* etc.
* Polimorfismo de inclusión (también llamado redefinición o subtipado)
La habilidad para redefinir un método en clases que se hereda de una clase base se llama especialización. Por lo tanto, se puede llamar un método de objeto sin tener que conocer su tipo intrínseco: esto es polimorfismo de subtipado. Permite no tomar en cuenta detalles de las clases especializadas de una familia de objetos, enmascarándolos con una interfaz común (siendo esta la clase básica).
Imagine un juego de ajedrez con los objetos rey, reina, alfil, caballo, torre y peón, cada uno heredando el objeto pieza.
El método movimiento podría, usando polimorfismo de subtipado, hacer el movimiento correspondiente de acuerdo a la clase objeto que se llama. Esto permite al programa realizar el movimiento.de_pieza sin tener que verse conectado con cada tipo de pieza en particular.
Fuente: Kioeskea
Saludos
* Abstracción <- Algo que
* Abstracción <- Algo que se puede abstraer
* Abstracto <- algo ke ya se abstrajo
* Accesors <-lors quers ters ayursdan
* Acoplamiento < del verbo acomplar, to acoplo tu acoplas , nosotros acomplamos etc
* API < Asociacion Politica Inversa - CANACA
* Cohesión < Poner algun alimento sobre una casuela que a su vez esta arriva del fuego
* Concreto < jajajajaaj XD piso!
* Contexto < accion de concatenar un regalo mas texto Con Texto
* Encapsulamiento < Lo que hacia Bulma y su papa en Dragon Ball Z con las naves y todas esas cosas
* Firma < accion de hacer garabatos en una hoja, comunmente llamados bauchers
* Herencia < lo ke me va a dejar mi mama
* Implementación < accion de implementar algo no implementado
* Interface < Equipo de facebook en la liga española ejemplo Inter de Milan, Inter Face
* JavaBean < Frijol proveniente de las islas de Java
* Lenguaje de Modelado < "ashhhh estoy gorda" , "necesito enflacar mas" , " cual vestido me toca ponerme" lo que las modelos dicen
* Paradigma < regado etiquetado hacia la señorita digma ParaDigma
* Polimorfismo < cuando una forma se acuesta con otras formas
* Programación Orientada a Objetos
* UML < Usuario Mamila Lorenzo
Jajajaja
+ 10.
* Cohesión < Poner algun alimento sobre una casuela que a su vez esta arriva del fuego
Estuvo genial.
JavaBean
El concepto de JavaBean lo tengo en ingles y decido no traducirlo para evitar errores al pasarlo a español.
“A Java Bean is a reusable software component that can be manipulated visually in a builder tool.”
This covers a wide range of different possibilities.
The builder tools may include web page builders, visual application builders, GUI layout build- ers, or even server application builders. Sometimes the “builder tool” may simply be a docu- ment editor that is including some beans as part of a compound document.
Some Java Beans may be simple GUI elements such as buttons and sliders. Other Java Beans may be sophisticated visual software components such as database viewers, or data feeds. Some Java Beans may have no GUI appearance of their own, but may still be composed togeth- er visually using an application builder.
Some builder tools may operate entirely visually, allowing the direct plugging together of Java Beans. Other builders may enable users to conveniently write Java classes that interact with and control a set of beans. Other builders may provide a simple scripting language to allow easy high-level scripting of a set of beans.
Individual Java Beans will vary in the functionality they support, but the typical unifying fea- tures that distinguish a Java Bean are:
•Support for “introspection” so that a builder tool can analyze how a bean works
• Support for “customization” so that when using an application builder a user can customize the appearance and behaviour of a bean.
• Supportfor“events”asasimplecommunicationmetaphorthancanbeusedtoconnect up beans.
•Support for “properties”, both for customization and for programmatic use.
• Supportforpersistence,sothatabeancanbecustomizedinanapplicationbuilderand then have its customized state saved away and reloaded later.
bibliografia: Sun Microsystems, JavaBeans-http://java.sun.com/beans
Programación orientada a objetos
La Programación orientada a objetos es un paradigma (modelo o conjunto de reglas) de programación. Es una manera particular de ver las cosas, de entender los problemas para poder dividirlo, simplificarlo y entenderlo. Su característica principal es la de dividir en entidades a los elementos involucrados en el problema.
Es una forma de desarrollar un sistema, es decir, es una herramienta para entender y elaborar un sistema, por lo tanto es independiente del lenguaje de programación empleado. Al separar en entidades, persigue identificar los conceptos relevantes o, en términos propios, las entidades involucradas del problema a resolver: reconocer sus características y la serie de acciones alrededor de ellos, sean efectuadas por ellos o sobre ellos.
Nota: si prestaron atención a la primera sesión, pueden brincarse todo lo que está entrecitado o indentado, se trata de los conceptos sustentantes para entender este paradigma o manera de ver las cosas.
Los principios de la orientación a objetos son la modularidad y la reusabilidad.
Para lograrla, se persiguen ciertos conceptos. Como ya están enunciados por separado en la tarea y desarrollados en las aportaciones anteriores a esta, me remito sencillamente a enumerarlas:
Comunicación:
Características de la orientación a objetos:
Fuentes:
Encapsulamiento
En programación modular, y más específicamente en programación orientada a objetos, se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto.
Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.
De esta forma el usuario de la clase puede obviar la implementación de los métodos y propiedades para concentrarse sólo en cómo usarlos. Por otro lado se evita que el usuario pueda cambiar su estado de maneras imprevistas e incontroladas.
Formas de encapsular:
*Estándar (Predeterminado)
*Abierto : Hace que el miembro de la clase pueda ser accedido desde el exterior de la Clase y cualquier parte del programa.
*Protegido : Solo es accesible desde la Clase y las clases que heredan (a cualquier nivel).
*Semi cerrado : Solo es accesible desde la clase heredada
*Cerrado : Solo es accesible desde la Clase.
Paradigma
Un paradigma es un patrón, modelo o conjunto de reglas aplicada a algún contexto o disciplina. En lingüística tradicionalmente se ha utilizado el término como agrupación de términos símiles. De allí que la psicología neoconductista lo usara para referirse a las ideas, pensamientos, creencias y acepciones inculcadas en nuestra primera infancia, sin cuestionarse. Así también lo ocupan las ciencias, salvo en el sometimiento a análisis. En las ciencias de la computación, un paradigma provee la visión y determina los métodos de un programador al construir una pieza de software.
Diferentes paradigmas resultan de distintos estilos de programación, finalmente resultado de distintos estilos de concebir, organizar, abordar y solucionar problemas. Por eso es tan difícil clasificar un lenguaje de programación en un solo paradigma. Java y Smalltalk fueron pensados en el paradigma orientado a objetos. Scheme, en contraparte, sólo soporta programación funcional. Python, por otro lado, soporta múltiples paradigmas desde su concepción.
Los paradigmas de programación normalmente se dividen en:
Por supuesto, existen "más formas de matar las pulgas": el paradigma orientado al sujeto, el reflejante, basada en reglas, basado en restricciones, en prototipos, etc.
Fuentes:
http://www.scribd.com/doc/9174723/Paradigmas-de-Programacion
http://www.mitecnologico.com/Main/ProgramacionIIIE
http://es.wikipedia.org/wiki/Paradigma_de_programación
valiosa la definición
valiosa la definición exacta de Paradigma funcional ... muchas veces se refieren a "programación funcional" como si fuera la misma programación imperativa y hay un error en ello. Saludo.
Cohesión
Tradicionalmente, la cohesión es la reunión, enlace o adhesión de cosas entre sí. En las ciencias de la computación, es el atributo de las piezas de software que pueden usarse para predecir propiedades de implementaciones que se crearían desde un diseño dado, sobre cuán fuertemente relacionados o enfocados están las responsabilidades de un módulo dado. El criterio debe ser desde el punto de vista del negocio o técnico, y de allí que la definición original no se podía medir. Ahora se examina dependiendo el nivel de información de código, es decir, utilizando un análisis observacional para mostrar o comprobar que la información en el nivel de diseño corresponda formalmente con la lógica de negocio, agregando la flexibilidad o posibilidad para el soporte al diseño del software, mantenimiento y reestructuración.
En la programación orientada a objetos, si los métodos que sirven a una clase determinada tienden a ser similares en muchos aspectos, se dice que tiene una alta cohesión. En un sistema altamente cohesivo, la legibilidad del código y la posibilidad de reuso se incrementan, mientras la complejidad se mantiene aceptable. La cohesión decrece si las responsabilidades (métodos) de una clase tienen poco en común o sus métodos lleven demasiadas actividades, a menudo usando selecciones de información sin relación o demasiado atomizados.
Tipos de cohesión: Según una medida cualitativa (se usa una rúbrica para obtener su clasificación), se clasifican, de la peor a la mejor, como sigue:
Esta clasificación es resultado de diversos estudios (en ambas fuentes se ahonda mucho al respecto). Aunque la cohesión funcional se considere el tipo de cohesión más deseable para un módulo de software, no siempre se puede alcanzar. Hay casos donde la cohesión comunicacional o la procedimental sean los niveles de cohesión más altos que se puedan conseguir, dadas las circunstancias.
La cohesión se contrasta a menudo con el acoplamiento, un concepto diferente, aunque la cohesión alta a menudo se correlacione con un acoplamiento débil, y viceversa. Ambos persiguen buenas prácticas de programación que reduzcan el mantenimiento y costos de modificación.
Fuentes:
http://www.cs.colostate.edu/TechReports/Reports/1997/tr97-113.pdf
http://en.wikipedia.org/wiki/Cohesion_(computer_science) (en inglés)
Acoplamiento
Tradicionalmente es el tipo o el grado de unión de cosas entre sí: granos, provisiones, etc. En ciencias de la computación, acoplamiento o dependencia es el grado en el cual cada módulo del programa confía en cada uno de los otros módulos. Como en el caso de la cohesión, originalmente se medía sólo como "baja" (débil o floja) o alta (fuerte o firme). Posteriores estudios han clasificado el nivel de acoplamiento como sigue, del más alto al más bajo:
En la programación orientada a objetos, hay dos acoplamientos adicionales:
El acoplamiento se contrasta con la cohesión, generalmente. Bajo acoplamiento con alta cohesión, y viceversa. El bajo acoplamiento es a menudo señal de un buen diseño y un sistema computacional bien estructurado, y cuando se combina con la alta cohesión, soporta los objetivos generales de alta legibilidad y baja necesidad de mantenimiento.
de que siver una comunidad hispana mexicana si...
@Raul, solo un comentario de lo que he visto en el foro y las referencias que dan.. primero estoy de acuerdo que para los que trabajamos en las tic's es prácticamente una obligación el saber Ingles y mas si quieres sobre salir... pero ¿Que ondas?.. para que quiero una comunidad Hispana, con hecha por paisano si mi duda me la contestan en Ingles ¬¬...? pues mejor me voy a una comunidad internacional... creo que esta bien decir no lo traduzco para no regarla.. pero pues bien decir este texto lo dice.. lo que yo creo que dice es asi... , mas no hay esta el texto.. y si sabes ingles o le medio entindes bueno y si no pues ya te !·$%$... ¬¬, creo que asi queda lejos los propositos de compartir informacion y de llegar al publico hispano y a los paisanos, digo estoy en una comunidad hispana de mexicanos por algo a de ser..