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
  • Accesors
  • Acoplamiento
  • API
  • Cohesión
  • Concreto
  • Contexto
  • Encapsulamiento
  • Firma
  • Herencia
  • Implementación
  • Interface
  • JavaBean
  • Lenguaje de Modelado
  • Mensaje
  • Mutators
  • Paradigma
  • Polimorfismo
  • Programación Orientada a Objetos
  • UML

¿Quién quiere participar?. Un término por respuesta. No contesten duplicadas excepto si la anterior es flagrantemente incorrecta.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

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...

Imagen de mathemathician

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í:

listaVisitantes.clear();

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

listaVisitantes.add( nuevoVisitante );

:)

Imagen de checotaku

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.

Imagen de Jhanno

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.

Imagen de samz550a

¿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.

Imagen de Jvan

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.

public class Persona{
    private String nombre;

//Mutator que modifica el atributo nombre, también conocido como setter
   public void setNombre(String nombre){
      this.nombre = nombre;
   }
}

Imagen de bferro

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)

Imagen de bferro

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.

Imagen de ezamudio

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).

Imagen de samz550a

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.

Imagen de Shadonwk

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

Imagen de klone

* 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

Imagen de francisco.santiagoj

Jajajaja

+ 10.

* Cohesión < Poner algun alimento sobre una casuela que a su vez esta arriva del fuego
Estuvo genial.

Imagen de Raul

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

Imagen de Miguel-1.mx

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.

En esta división cualquier problema se reduce a objetos que, como vimos en la primera sesión, puede ser cualquier cosa. Cualquier ente (cosa, idea) que pueda enunciarse por palabras y encierren un concepto o idea. El mundo está lleno de objetos, y todos ellos se pueden representar para dar una solución en un sistema computacional (¡Qué elegante se escuchó...!).

Gracias a la maravilla del lenguaje (natural o artificial), podemos encerrar en una palabra toda una serie de concepciones, ideas, connotaciones y cargas culturales: todo eso en una palabra (por eso los filósofos, los lingüistas, los comunicólogos, los psicólogos y tantos otros han estudiado al lenguaje).

Me daré la libertad de dar un ejemplo. Consideremos una palabra cualquiera: pájaro. Cuando alguien menciona "pájaro" se realiza un proceso mental en diezmilésimas de segundo (superen eso, Macs) para juntar las imágenes, ideas, conceptos, experiencias y todo lo que avoque el objeto preconcebido. Un pájaro.

Cada tipo distinto de pájaro sigue siendo un objeto pájaro pues comparten particularidades que los agrupan a todos en ese concepto conocido. A esa agrupación de objetos, tanto en las ciencias del lenguaje, en las ciencias naturales, como en la programación, le llamamos clase (como también se enunció en la sesión 1).

Una clase es el modelo base que engloba todas las características que cada objeto (en nuestro caso el pájaro) debe tener, sin ser el objeto real.

La clase no determina nada distintivo del objeto: ni el tamaño, ni el tono de color, ni su altura "levantado", ni el ancho de sus venas... ni sus plumas, ni su timbre (¿En qué pensaban?). Los objetos son todos los "especímenes" que podemos crear mentalmente basándonos en la mencionada clase.

Ya se enunciaron algunas características de la clase "pájaro". Dependiendo el problema, serán relevantes algunas particularidades y otras no. Ahora tomemos un ejemplo de objeto y llamémosle canario. Su tamaño es mediano (en relación a otras aves, es decir, mide 12 centímetros y "levantado" alcanza los 15), su tono de color es amarillo, sus venas miden (según su localización) entre 0.15 milímetros, un cabello humano, y 0.5 (una mina de lapicero). Su timbre se clasifica como gorjeo y suena similar al jilguero, y sus plumas se clasifican como medianas a pequeñas (entre 2, 3.5 y 5.5 cm.).

Una clase está compuesta por características (atributos o propiedades) y por comportamientos (acciones y métodos relacionados). Las caracterísiticas se determinan por el contexto o escenario donde se presentan. Reitero, dependiendo el problema también sería el grado de especificidad para describir los objetos. Para un biólogo se requeriría más que sencillamente "amarillo" (hay plumas blancas, con tonalidades ligeramente verdes...) o su clasificación de Linneo (Serinus canaria); para un diseñador gráfico, pudieran ser los gradientes de las plumas en RGB, etc. Por cierto, el contexto en nuestro ejemplo es el de las aves en general, por eso hay que ser cuidadosos con las palabras que elegimos, ¿verdad? Ese es el estudio de la pragmática, las palabras en contexto.

Entonces, en programación sólo implementamos los atributos y métodos relacionados con el contexto del problema que estamos solucionando.

A los valores que tienen los atributos de un objeto les llamamos el estado del objeto, y a los métodos que ofrece les llamamos interfaz (en ciencias de la comunicación e informática, una interfaz es la conexión física y funcional entre dos sistemas o aparatos independientes), mientras que al código que usamos para construir las clases le nombramos la implementación de la clase.

Tomando el concepto revisado de la sesión anterior, los objetos se comunican entre sí utilizando mensajes. En ciencias de la comunicación, un mensaje es la comunicación dirigida a un objeto. En computación, además, es una petición para que se ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó (Cuán técnico...).

Los objetos tienen distintos tipos de relaciones: de asociación y de composición/agregación.

Los principios de la orientación a objetos son la modularidad y la reusabilidad.

  • La modularidad significa trabajar por partes: entre más sencillos se enuncien los componentes, mejor. Si no se puede explicar en una operación o enunciado, requiere una división adicional.
  • La reusabilidad significa no reinventarse la rueda: lo que está hecho es para usarse, debe construirse pensando que alguien lo necesitará usar alguna vez. Incluye ser ordenado, limpio, comentar lo que se esté implementando y usar las convenciones.

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:

  • Alta cohesión,
  • Bajo acoplamiento.

Características de la orientación a objetos:

  • Abstracción,
  • Encapsulamiento,
  • Herencia,
  • Polimorfismo.

Fuentes:

Imagen de jujogoru

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.

Imagen de Miguel-1.mx

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:

  • Programación imperativa o por procedimientos: una serie de comandos que la computadora ejecuta en orden claro y específico, llevando al programa a través de distintos estados, p. ej., de "flojo" a "productivo". Su contrario es el declarativo.
  • Programación declarativa: describe las propiedades de la solución buscada, sin determinar exactamente el algoritmo (conjunto de instrucciones) utilizado para encontrar la solución. Es mucho más complicado de implementar y no es tan eficiente, pero tiene ventajas para solucionar ciertos problemas.
  • Paradigma estructurado: se divide en bloques (funciones y procedimientos) que pueden o no comunicarse entre sí. Se controla por secuencias, selecciones e iteraciones. Permite reutilizar código ya programado y permite comprender de mejor manera la programación.
  • Paradigma por bloques: también llamado inestructurado, es un bloque sin estructura. El ejemplo más típico son los batch (.bat) de DOS.
  • Paradigma funcional: concibe la computación como la evaluación de funciones matemáticas y evita declarar y cambiar datos. Hace hincapié en la composición y aplicación de las funciones, más que la ejecución secuencial o cambios de estados del paradigma procedimental. Resuelve determinados problemas elegantemente y evitan los efectos que provocan los errores en la determinación de tipos de datos.
  • Paradigma orientado a objetos: se basa en la idea de encapsular estado y operaciones en objetos. Resuelve los problemas comunicando los objetos mencionados mediante mensajes. La herencia y los subtipos entre objetos, así como soluciones, la "programación orientada a mensajes" son su característica principal. Su principal ventaja es el reuso de códigos y su facilidad para implementar soluciones a determinados problemas.
  • Paradigma lógico: define las reglas lógicas para responder preguntas al sistema y resolver los problemas mediante un motor de inferencias lógicas. El lenguaje representativo es prolog.

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

Imagen de samz550a

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.

Imagen de Miguel-1.mx

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:

  • Cohesión coincidente (la peor): las partes de un módulo se agrupan arbitrariamente (al azar) sin relación significativa (p. ej., un módulo con las funciones usadas más frecuentemente).
  • Cohesión lógica: las partes de un módulo se agrupan cuando se procesan en algún tiempo particular en la ejecución del programa (p. ej., las funciones que se llaman tras atrapar una excepción que cierra la apertura de archivos, crean un informe de error y notifican al usuario).
  • Cohesión procedimental: las partes de un módulo se agrupan porque operan en la misma información (p. ej., un módulo que opera en el mismo registro de información).
  • Cohesión secuencial: las partes de un módulo se agrupan porque la salida de una de sus partes es la entrada de la siguiente, como en una línea de ensamblado (p. ej., una función que lee datos desde un archivo y procesa su información).
  • Cohesión funcional (la mejor): las partes de un módulo se agrupan porque todas contribuyen a una tarea única y bien definida (p. ej., analizar sintácticamente XML como en el caso de la biblioteca "Expat parser" de XML (http://expat.sourceforge.net/).

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)

Imagen de Miguel-1.mx

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:

  • Acoplamiento de contenido (alto): un módulo modifica o confía en el trabajo interno de otro módulo (p. ej., obtiene información local de otro módulo), por lo tanto, al cambiar la manera sobre cómo produce información el segundo módulo (lugar, tipo, tiempo) llevará a tener que cambiar al módulo dependiente.
  • Acoplamiento común: dos módulos comparten la misma información global (p. ej., una variable global). Cambiar el recurso compartido implica cambiar todos los módulos que lo usan.
  • Acoplamiento externo: dos módulos comparten un formato de información impuesto, protocolo de comunicación o interfaz de dispositivo.
  • Acoplamiento de control: un módulo controla el flujo de otro, pasándole información sobre qué hacer (p. ej., pasar una bandera sobre qué hacer).
  • Acoplamiento de información estructurada (o de estampilla): módulos que comparten una estructura de información y utilizan sólo una parte de ella, posiblemente una parte distinta (p. ej., pasar todo un registro a una función que sólo requiere un campo de ella). Puede conducir a tener que cambiar la manera de cómo un módulo lee un campo, el cual no necesite, porque se haya modificado en otro lado.
  • Acoplamiento de información: los módulos comparten información, por ejemplo, mediante parámetros. Cada dato es una pieza elemental, y esas son el único dato compartido (p. ej., pasar un número entero a una función que computa una raíz cuadrada).
  • Acoplamiento de mensajes (bajo): Este es el más débil. Los módulos no son dependientes del otro. En lugar de ello, usan una interfaz pública para intercambiar mensajes sin parámetros (llamados eventos).
  • Ningún acoplamiento: Los módulos no se comunican entre sí.

En la programación orientada a objetos, hay dos acoplamientos adicionales:

  • Acoplamiento de subclase: describe la relación entre un "hijo" y "padre". El hijo se conecta al padre, pero el padre no se conecta al hijo.
  • Acoplamiento temporal: cuando dos acciones se ensamblan dentro de un módulo sólo porque ocurren al mismo tiempo.

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.

Imagen de fcodiaz

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..