Paradigmas de Prog

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 53

Paradigmas y

Programación
Orientada a
Objetos
PARADIGMAS DE PROGRAMACIÓN

 “Un paradigma de programación indica un método de


realizar cómputos y la manera en que se deben
estructurar y organizar las tareas que debe llevar a cabo
un programa ”
 se asocian a un determinado estilo de programación.
 Los lenguajes de programación suelen implementar, a
menudo de forma parcial, varios paradigmas.
Programación Estructurada

 Procedural / también :
 Diseño de arriba hacia abajo.
 Reutiliza código
 Complejiza el código de la
aplicacion
Clasificación de Paradigmas
Ejemplo de lenguajes
Definición de Paradigma
 Un paradigma de programación es un modelo básico de
diseño e implementación de programas, que permite
desarrollar software conforme a ciertos principios o
fundamentos específicos que se aceptan como válidos.
 Otra definición lo expresa como un marco conceptual
que determina los bloques básicos de construcción de
software y los criterios para su uso y combinación.
 En otras palabras, es una colección de modelos
conceptuales que juntos modelan el proceso de diseño,
orientan la forma de definir los problemas y, por lo
tanto, determinan la estructura final de un programa.
Nos sirven para:
 Plantear modelos cercanos a la realidad que permitan abstraerse de
las especificaciones computacionales y lograr una relación lo más fluida
posibles entre el dominio de aplicación y el programa.
 Diseñar implementaciones de manera que puedan ser extendidas y
modificadas con el mínimo impacto en el resto de su estructura, ante
cambios en la realidad o nuevos requerimientos.
 Dar flexibilidad a las soluciones para que puedan ser reutilizadas en
múltiples contextos, incluso diferentes a los que les dieron origen.
 Diseñar una articulación funcional adecuada de las diferentes entidades
que conforman el sistema.
 Desarrollar un código claro, simple y compacto.
 Construir soluciones genéricas que permitan abstraerse de las
particularidades propias de cada tipo de entidad de software y a la vez
atender a la especificidad de cada una de ellas.
 Focalización de las funcionalidades y componentes del sistema para
poder trabajar sobre eficiencia.
Primeros paradigmas

 Los primeros lenguajes de programación se basaron


sobre un conjunto de premisas de funcionamiento que
luego, con el correr de los años, se fueron
complejizando y ampliando, pero que comparten
suficientes características en común para considerarlas
parte de un mismo paradigma que se denomina
imperativo o procedural, según el énfasis que se haga
en un aspecto u otro.
 En un programa tienen un papel dominante los
procedimientos compuestos por sentencias imperativas,
es decir aquellas que indican realizar una determinada
operación que modifica los datos guardados en memoria
Primeros Paradigmas

 Los lenguajes de este paradigma que siguen vigentes en


la actualidad, lo han logrado por su simplicidad, su
versatilidad y robustez. Además, sus elementos
característicos siguen siendo retomados por numerosos
lenguajes de otros paradigmas, por lo que tiene una
gran importancia dentro de las ciencias de la
computación.
Primeros Paradigmas

 Posteriormente, surgieron diferentes corrientes que


objetaron los fundamentos de la programación del
momento y plantearon otras premisas desde las cuales
desarrollar programas. En consecuencia, se crearon
nuevos lenguajes de programación, que en la actualidad
se los puede conceptualizar en el marco de los
paradigmas declarativos, incluyendo al paradigma lógico
y al paradigma funcional.
Paradigma Imperativo
Dentro de este paradigma surgieron diferentes etapas, primero
surgió el paradigma lineal donde los programas eran un solo
bloque, con instrucciones para:
 Ejecutar un conjunto de instrucciones, encabezadas por
una etiqueta (label)
 Ejecutar un rango de instrucciones definido por etiquetas
desde/hasta.
 Derivar el flujo de control a determinada etiqueta. (Go
to, go to .. depending).
 Realizar el uso intensivo de banderas para la detección de
eventos anteriores.
 Entre otros. Luego apareció el paradigma estructurado,
que a continuación detallaremos
Paradigma Imperativo

 El paradigma imperativo describe paso a paso un


conjunto de instrucciones que deben ejecutarse para
variar el estado del programa y hallar la solución, es
decir, un algoritmo en el que se describen los pasos
necesarios para solucionar el problema.
PARADIGMA ESTRUCTURADO

 Algoritmo + Estructura de Datos =


programa
Describe la programación en términos del estado del
programa y sentencias que cambian dicho estado.
Los programas imperativos son un conjunto de
instrucciones que le indican al computador cómo realizar
una tarea. La implementación de hardware de la mayoría
de computadores es imperativa; prácticamente todo el
hardware de los computadores está diseñado para ejecutar
código de máquina, que es nativo al computador, escrito en
una forma imperativa.
Paradigma Estructurado

 Desde esta perspectiva de bajo nivel, el estilo del


programa está definido por los contenidos de la
memoria, y las sentencias son instrucciones en el
lenguaje de máquina nativo del computador. Los
lenguajes imperativos de alto nivel usan variables y
sentencias más complejas, pero aún siguen el mismo
paradigma.
 Las recetas y las listas de revisión de procesos, a pesar
de no ser programas de computadora, son también
conceptos familiares similares en estilo a la
programación imperativa; cada paso es una instrucción,
y el mundo físico guarda el estado.
Paradigma Estructurado
 El conjunto de instrucciones del programa es más cercano al
conjunto de instrucciones de código de máquina, por
consiguiente el código es más directo y es más rápida su
ejecución.
 Si el programa está bien modularizado, es más fácil de
corregir los errores de ejecución y su mantenimiento.
 La estructura del programa puede ser clara si:
 Se hace hincapié en la modularización del programa, existen
niveles, puede distribuirse la codificación siguiendo un diseño Top
Down. (La codificación distribuida en módulos va de un nivel
general al de máximo detalle).
 La cantidad de niveles que usamos para modularizar es la
adecuada (No está limitada por los lenguajes).
 Los nombres de los módulos (Procedimientos, funciones),
definidos por el programador, son representativos de lo que el
módulo realiza.
 Hay suficiente documentación adjunta al código.
Paradigma Estructurado

 Limitaciones: La complejidad de muchos sistemas


actuales hace que sea complicado definir la distribución
del código en módulos. Este paradigma posibilita
modularizar la codificación, pero no define cual es el
criterio a seguir. (Como si lo hace el paradigma
Programación orientada a Objetos)
 No se adapta a todos los tipos de problemas.
 Aplicaciones:
 Sistemas de bajo nivel
 Sistemas de tiempo real
 Programación de micro controladores
 Máquinas de estado
 Desarrollo de video juegos de consola
 Aplicaciones que deben manejar recursos limitados
Lenguajes y Paradigmas

 El Paradigma de Programación condiciona la forma en


que se expresa la solución a un problema.
 El Lenguaje de Programación (que se encuadra en un
determinado paradigma) es la herramienta que permite
expresar la solución a un problema
Lenguajes y Paradigmas
PARADIGMA IMPERATIVO
 Describe cómo debe realizarse el cálculo, no el
porqué.
 Un cómputo consiste en una serie de
sentencias, ejecutadas según un control de
flujo explícito, que modifican el estado del
programa.
 Las variables son celdas de memoria que
contienen datos (o referencias), pueden ser
modificadas, y representan el estado del
programa.
 La sentencia principal es la asignación.
PARADIGMA IMPERATIVO
Programación estructurada

 Se busca que el programador elabore programas


sencillos y fáciles de entender.
 Para ello, la PE hace uso de tres estructuras básicas
de control:
 Estructura Secuencial
 Estructura Selectiva
 Estructura Repetitiva (ó Iterativa)
 Existe un teorema fundamental, el cual afirma que
cualquier programa, puede ser elaborado utilizando
únicamente las tres estructuras básicas (secuencia,
selección, iteración).
PARADIGMA DECLARATIVO

 Describe que se debe cálcular, sin explicitar el cómo.


 No existe un orden de evaluación prefijado.
 No existe sentencia de asignación.
 Ejemplo prolog, Maude, SQL
PARADIGMA ORIENTACIÓN A OBJETOS

 Ofrece mayor dominio sobre el programa liberándonos


aún más de su control.
 Hasta ahora, el control del programa era tarea del
programador, quien tenía que controlar y mantener en
su mente cada proceso que se realizaba y los efectos
colaterales que pudieran surgir entre distintos
procesos, lo que llamamos colisiones.
PARADIGMA ORIENTACIÓN A OBJETOS

 En POO, el programa se controla a sí mismo y la


mente del programador se libera enormemente
pudiendo realizar aplicaciones mucho más
complejas al exigir menor esfuerzo de atención, ya
que los objetos son entidades autónomas que se
controlan a sí mismos.
 Los objetos nos impiden mezclar sus datos con
otros métodos distintos a los suyos.
¿QUÉ NO ES LA POO?
No es un sistema de comunicación con los programas
basados en hardware, ventanas, iconos, etc.
 Puesto que, normalmente, los lenguajes de POO
suelen presentar estas características y
habitualmente estos entornos suelen desarrollarse
con estas técnicas, algunas personas tienden a
identificar la POO a entornos de este tipo.
¿QUÉ NO ES LA POO?
 No es un un lenguaje.
 De hecho las técnicas de POO
pueden utilizarse en cualquier
lenguaje conocido.
Paradigma
Orientado a
Objetos
Introducción
 Los problemas suelen tener varias soluciones posibles.
 En programación existen diversas metodologías que nos
ayudan a enfrentar un problema.
 Cada metodología tiene diversos lenguajes que las
soportan.
 Algunos lenguajes soportan varias metodologías.

Metodología Lenguaje
Estructurada Fortran, C, Pascal, Basic
Orientada a objetos (OOP) C++, Java, Smalltalk
Orientada a eventos VisualBasic
Programación Orientada a
Objetos
Definición:
La Programación Orientada a Objetos (OOP) es un
método de programación en el cual los programas se
organizan en colecciones cooperativas de objetos,
cada uno de los cuales representa una instancia de
alguna clase, y cuyas clases son, todas ellas,
miembros de una jerarquía de clases unidas mediante
relaciones de herencia.
Comentarios:
 Usamos objetos en lugar de algoritmos como bloque fundamental
 Cada objeto es una instancia de una clase
 Las clases están relacionadas entre sí por relaciones tan
complejas como la herencia
Ventajas de la POO

 Proximidad de los conceptos modelados respecto a


objetos del mundo real
 Facilita la reutilización de código
 Y por tanto el mantenimiento del mismo
 Se pueden usar conceptos comunes durante las fases de
análisis, diseño e implementación
 Disipa las barreras entre el qué y el cómo
Desventajas de la POO

 Mayor complejidad a la hora de entender el flujo de


datos
 Pérdida de linealidad
 Requiere de un lenguaje de modelización de problemas
más elaborado:
 Unified Modelling Language (UML)
 Representaciones gráficas más complicadas
Conceptos de la OOP
Conceptos básicos Tipos de relaciones
 Objeto  Asociación
 Clase  Herencia
 Agregación
Características de la OOP
 Abstracción:
 Instanciación
 Encapsulamiento:
 Modularidad: Representaciones gráficas
 Jerarquía  Diagramas estáticos (de
clases, de objetos...)
Otros conceptos OOP  Diagramas dinámicos (de
 Tipos interacción...)
 Persistencia
Objeto y Clase
Un objeto es algo de lo Una clase describe los
que hablamos y que objetos del mismo tipo
podemos manipular  Todos los objetos son
 Existen en el mundo real instancias de una clase
(o en nuestro  Describe las propiedades
entendimiento del y el comportamiento de
mismo) un tipo de objetos

Objeto:Clase Clase
Atributo1=valor Atributos
Atributo2=valor
... Operaciones
Conceptos OOP: Abstracción
 Nos permite trabajar con la complejidad del mundo real
 Resaltando los aspectos relevantes de los objetos de una clase
 Ocultando los detalles particulares de cada objeto
 Separaremos el comportamiento de la implementación
 Es más importante saber qué se hace en lugar de cómo se
hace:
Un sensor de temperatura
 Se define porque...
 mide la temperatura
 nos muestra su valor
 se puede calibrar...
 No sabemos... (no nos importa)
 cómo mide la temperatura
 de qué está hecho
 cómo se calibra
Conceptos OOP: Abstracción

 La abstracción no es única:

Un coche puede ser...


 Una cosa con ruedas, motor, volante y pedales
(conductor)
 Algo capaz de transportar personas (taxista)
 Una caja que se mueve (simulador de tráfico)
 Conjunto de piezas (fabricante)
Conceptos OOP: Encapsulamiento

 Ninguna parte de un sistema complejo debe depender de los detalles


internos de otra.
 Complementa a la abstracción
 Se consigue:
 Separando la interfaz de su implementación
 Ocultando la información interna de un objeto
 Escondiendo la estructura e implementación de los métodos (algoritmos).
 Exponiendo solo la forma de interactuar con el objeto
Conceptos OOP:
Encapsulamiento
Ejemplo: Un paralelogramo
Vemos que se puede...
 Construir con:
 4 puntos (y restricciones)
 1 punto y 2 vectores No vemos...
 1 punto, 1 vector, 1 ángulo  Como está representado
y 1 lado internamente
 Transformaciones:  4 puntos?
 Escalado  1 punto y 2 vectores?
 Rotación  ...
 Desplazamiento
 Como se modifica su escala
 Dibujar
 Guardando el factor?
 Escalando en el momento?
 Idem para rotación, traslación,
etc...
Conceptos OOP: Modularidad
 Consiste en separar el sistema en bloques poco
ligados entre sí: módulos.
 Organización del código

 Es una especie de encapsulamiento de más alto nivel.


 El C++ no lo impone aunque lo soporta (namespace)
 El Java es más formal (packages)

 Difícil pero muy importante en sistemas grandes.


 Suele aplicarse refinando el sistema en sucesivas iteraciones
 Cada módulo debe definir una interfaz clara
Conceptos POO: Jerarquía

 Es una clasificación u ordenamiento de las abstracciones


 Hay dos jerarquías fundamentales:
 Estructura de clases:
 Jerarquía “es un/a”
 Relaciones de herencia

 Estructura de objetos:
 Jerarquía “parte de”
 Relaciones de agregación
 Está implementada de manera genérica en la estructura de clases
Conceptos OOP: Jerarquía
Ejemplo: Figuras planas y diagramas

 Una figura plana es: Herencia simple


 Algo con una posición en el  Un cuadrado es una figura
plano
 Un círculo es una figura
 Escalable
 Rotable

Herencia múltiple
 Un gráfico es algo que se
puede dibujar en 2D es una figura
es un gráfico
 Un diagrama es un conjunto Agregación
de cuadrados y círculos
Conceptos OOP: Tipo

 Es el reforzamiento del concepto de clase


 Objetos de tipo diferente no pueden ser intercambiados
 El C++ y el Java son lenguajes fuertemente “tipeados”
 Ayuda a corregir errores en tiempo de compilación
 Mejor que en tiempo de ejecución
Conceptos OOP: Persistencia
 Propiedad de un objeto de trascender en el tiempo y
en el espacio a su creador (programa que lo generó)
 No se trata de almacenar sólo el estado de un objeto
sino toda la clase (incluido su comportamiento)
 No está directamente soportado por el C++
 Existen librerías y sistemas completos (OODBMS) que facilitan
la tarea
 Frameworks (entornos) como ROOT lo soportan parcialmente
(reflex)
 El concepto de serialización del Java está
directamente relacionado con la persistencia
Relaciones

 Están presentes en cualquier sistema


 Definen como se producen los intercambios de información y datos
 También ayudan a comprender las propiedades de unas clases a partir
de las propiedades de otras
 Existen 4 tipos de relaciones:
 Asociación
 Herencia
 Agregación
 Instanciación
Relación de Asociación
 Relación más general
 Denota una dependencia semántica
 Es bidireccional
 Primer paso para determinar una relación
más compleja
Ejemplo: Relación entre un producto y una venta. Cualquier venta
está asociada a un producto, pero no es, ni forma parte de, ni posee
ningún producto… al menos en una primera aproximación.

 Cardinalidad: multiplicidad a cada lado


 Uno a uno: Venta-Transacción
 Uno a muchos: Producto-Venta
 Muchos a muchos: Comprador-Vendedor
Relación de Herencia
 ¡Relación característica de la OOP!
 Puede expresar tanto especialización como generalización
 Evita definir repetidas veces
las características comunes a
varias clases
 Una de las clases comparte la estructura y/o el
comportamiento de otra(s) clase(s).
 También se denomina relación “es un/a” (is a)
Relación de Herencia
(vocabulario)
 Clase base o superclase: clase de la cual se
hereda
 Clase derivada o subclase: clase que hereda
 Herencia simple: Hereda de una sola clase
 Herencia múltiple: Hereda de varias clases
 Java solo la soporta parcialmente
 Presenta diversos problemas (¿qué hacer cuando se
hereda más de una vez de la misma clase?)
 Clase abstracta: La que no lleva, ni puede llevar,
ningún objeto asociado
 Polimorfismo: Posibilidad de usar indistintamente
todos los objetos de un clase y derivadas.
Relación de Herencia
(ejemplo)
Equilátero
Polimorfismo

Clase abstracta Triángulo Isósceles

Figura plana
Escaleno
Herencia simple

Rectángulo Cuadrado

Superclase Subclase
Relación de Agregación

 Una clase contiene a otra


clase
 Ésta “es parte de” aquélla.
 También se denomina
relación “es parte de” (has a)
 Una clase puede contener a otra:
 Por valor: Cuando los objetos de la clase contenida se crean y destruyen al
mismo tiempo que los de la clase continente
 Por referencia: Cuando no necesariamente ocurre lo anterior
Relación de Agregación

Un coche está hecho de


Volante
 Volante
 Palanca de cambio
 Motor
Marchas
 Ruedas
Coche
Motor

Ruedas
Relación de Instanciación

 En determinados casos una clase (p.ej. un vector) puede implementarse


independientemente del tipo (real, complejo, color...) de alguno de sus
atributos:
 Definimos una clase
parametrizada o template
(plantilla)
Tipo
 Para cada uno de los tipos
que necesitemos
definimos una nueva Vector
clase  Instanciación

VectorColores VectorEnteros
<Color> <int>
Representaciones gráficas
 Nos sirven para comunicarnos con otros usuarios o
desarrolladores.
 Documentan nuestro sistema
 Hay múltiples vistas y tipos de diagramas:
 Estáticos
 Diagramas de clases  Los de los ejemplos
 Diagramas de objetos
 ...
 Dinámicos:
 Diagramas de estado: Muestra el ciclo de vida de los objetos,
sistemas, etc...
 Diagramas secuenciales: Muestra como los objetos interaccionan
entre ellos
 ...

También podría gustarte

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy