Concepto, Paradigma, Lenguaje y Modelo de Programación

Transcripción

1 Concepto, Paradigma, Lenguaje y Modelo de Programación Definiciones Cada problema a resolver requiere de diferentes conceptos, cada paradigma ofrece un enfoque y un conjunto de mecanismos de razonamiento. Ejemplos son: OOP (programación orientada a objetos) = gran cantidad de abstracciones organizadas en jerarquías. LP (programación lógica) = navegar estructuras simbólicas complejas según un conjunto de reglas lógicas FP (programación funcional) = algoritmos complejos resueltos a partir de composición de funciones. La mayor parte de estos conceptos son soportados parcialmente (uno o dos de los tres) por algunos lenguajes de programación. Los otros deben ser resueltos por parches implementados por los diferentes mecanismos de estos lenguajes, lo que implica una limitación a veces inaceptable. El ejemplo típico es la validación lógica utilizando lenguajes concebidos para escribir sistemas (ingeniería) como C, C++ o Java. Al conjunto de técnicas de programación y principios de diseño para construir programas es lo que llamamos un modelo de programación ; cada lenguaje tiene un Modelo de Programación asociado. El modo de razonamiento lo aporta el paradigma soportado y la sintaxis y semántica lo aporta el lenguaje utilizado. Un sistema de software requiere de una plataforma que provea los servicios generales de la arquitectura (protocolos de comunicación, persistencia, armado de las interfaces de presentación, creación y destrucción de objetos, establecimiento de relaciones y ruptura de las mismas entre objetos) y además los escenarios y mecanismos de programación para el procesamiento de datos y validación de reglas de negocio. Por lo tanto el modelo de programación para su implementación requiere que por un lado posea propiedades de abstracción para armar jerarquías, modularidad para ser componible, administración de concurrencia para permitir multiprocesamiento y además la capacidad de resolver

2 algoritmos complejos y de realizar busquedas y validaciones de reglas. Esto nos lleva a concluir que es necesario contar con un lenguaje no asociado a un único paradigma, es decir un lenguaje multiparadigma; o la utilización de varios lenguajes de programación, cada uno para la implementación del código que requiera de los mecanismos que éste aporte. Propiedad Paradigma OOP (objetos) FP (funcional) LP (lógica) Abstracción Componibilidad Encapsulamiento Estados Concurrencia Declarativo Impl. Algoritmos Validar Reglas Lenguaje Clojure Scala C++11 Java8 Ruby Common Lisp Mercury Curry Mozart Racket

3 Iterativos vs Declarativos Java abstract public class GenericClass<E exts Number> { protected abstract E product(e x, E y); public class MyInteger exts GenericClass<Integer> { protected Integer product(integer x, Integer y) { return x * y; public interface MiFunctorInterface<S> { S execute(s element, S factor); public class MiFunctorClass exts MyInteger implements public Integer execute(integer element, Integer factor) { return this.product(element, factor); import java.util.vector; public class PruebaFunctor { static public void main(string [] args){ Vector<Integer> datai = new Vector<Integer>(); for(int i = 1; i <= 5; i++){ datai.add(new Integer(i)); Vector<Integer> datao = new Vector<Integer>(); for(integer integer: datai){ datao.add(new MiFunctorClass().execute(integer, new Integer(7))); System.out.println(dataO.toString()); C++ #ifndef MIFUNCTOR_HPP_ #define MIFUNCTOR_HPP_ template<typename T, typename S> class MiFunctor{

4 public: T operator()(t t, S s){ return t * s; ; #if /* MIFUNCTOR_HPP_ */ #include "mifunctor.hpp" #include <vector> #include <iostream> int main(){ std::vector<int> datai; for(int i = 1; i <= 5; i++){ datai.push_back(i); std::vector<int> datao; MiFunctor<int, int> functor; for (std::vector<int>::iterator it = datai.begin(); it!= datai.(); ++it) { datao.push_back(functor(*it, 7)); for (std::vector<int>::iterator it = datao.begin(); it!= datao.(); ++it) { std::cout << *it << "\n"; return 0; Lisp (defun proc(x factor) (* x factor)) (defun aplica(proc items factor) (if (null items) nil (cons (proc (car items) factor) (aplica proc (cdr items) factor)))) (aplica #'proc (list ) 7) ( ) Prolog mifunctor([], [], _). mifunctor([h T], [Head Tail], K) :- Head is H * K, mifunctor(t, Tail, K). :-mifunctor([1, 2, 3, 4, 5], L, 7). L = [7, 14, 21, 28, 35].

5 Programación declarativa = > definiciones => representación del conocimiento externo al sistema + argumentos => sin estados explícitos Programación iterativa/imperativa => comandos => representación interna del sistema => con estados explícitos Concurrencia y estados Estado = secuencia de valores cronológicos que representan resultados intermadios. Procedimientos en la programación funcional. Símbolos representan valores con los que se opera; no hay memoria donde se depositen valores que puedan accederse y cambiarse. defun(f(x, y, z) (... )) defun(g(x, y, z) (... )) (f(2, 35, 8)) 78 Analizar la ausencia del tiempo (estado) Estado implícito fun {Sum s A case s of r then {Sum r A+ nil then A Los dos argumentos s y A representan los estados implícitos s A [ ] 0 [2 3 4] 1 [3 4] 3 [4] 6 nil 10

6 No necesita soporte de cálculo programado y existe en la mente del programador. Estado explicito Tres desarrolladores P, U1 y U2 desarrollaron y usan el módulo M. fun {ModuleMaker fun {F % Definition of F fun {G % Definition of G in themodule(f:f g:g) M={ModuleMaker % Creation of M Para que U2 pueda monitorear cuantas veces se invoca a F la única forma es fun {F... Fin Fout Fout=Fin+1... con lo cual cambia la interfaz y por lo tanto tanto U2 como U1 deben cambiar su código, el que usa al módulo M. La forma de uso sería A={F... F1 F2 B={F... F2 F3 C={F... F3 F4 Esta no es la solución, la cual se logra de la siguiente manera fun {ModuleMaker ={NewCell 0 % Create cell referenced by fun {F... :=@+1 % New content of is old plus 1... % Original definition of F fun {F % Original definition of G fun % Return content of in themodule(f:f g:g c:count) M={ModuleMaker Esto implica la introducción de estados e implica además el logro a través de la modularidad. Se ha

7 introducido en el modelo eventos temporales del proceso en el modelo de programación. Ahora U2 tiene la nueva funcionalidad a partir de la consulta del estado a través de Count, U1 no debe cambiar su código porque para él la interfaz de M no ha cambiado. El cambio anterior resolvió un problema pero introdujo otro, se rompió con la facilidad de la programación concurrente ya que ahora deberá protegerse la variable. Los estados explícitos necesitan soporte de cálculo programado y existe explícitamente en el modelo programado por el programador. class Class Model Estado Estado Modulo M Modulo M Estado En la figura se puede ver esquemáticamente las dos diferentes situaciones. De lo anterior se concluye que la modularidad permite el manejo de estados explícitos. La programación orientada a objetos tiene esta propiedad. Programación en chico y en grande

8 class Class Model Estados Modular Objetos Arquitectura Programación en Grande ( Sistema) Concurrente Programación en Chico ( Negocio) Validación de Reglas Procesamiento de Datos Lógica Funcional