Introducción a la programación orientada a objetos. Lenguajes orientados a objetos. Fundamentos de la programación orientada a objetos

¿Por qué se prefiere la programación orientada a objetos en la mayoría de los proyectos? La programación orientada a objetos ofrece una forma eficaz de abordar su complejidad. En lugar de ver un programa como una secuencia de instrucciones ejecutables, lo representa como un grupo de objetos con determinadas propiedades y realiza determinadas acciones sobre ellos. Esto da como resultado aplicaciones más limpias, más confiables y más fáciles de mantener.

Los principios básicos surgieron porque se descubrieron limitaciones en enfoques preexistentes. Entre ellos se encuentran el acceso ilimitado a datos y una gran cantidad de conexiones que imponen restricciones a la hora de realizar cambios. Su conocimiento y razones son importantes para comprender qué es la programación orientada a objetos y cuáles son sus beneficios.

Lenguajes procesales

C, Pascal, FORTRAN y lenguajes similares son procesales. Es decir, cada uno de sus operadores ordena a la computadora que haga algo: recibir datos, sumar números, dividir por seis, mostrar el resultado. Una solicitud en un lenguaje procesal es una lista de instrucciones. Si es pequeño, no se requiere ningún otro principio organizador (a menudo llamado paradigma). El programador crea una lista de instrucciones y la computadora las ejecuta.

División en funciones

A medida que las aplicaciones crecen, la lista se vuelve difícil de manejar. Pocas personas pueden comprender más de unos pocos cientos de instrucciones hasta que se agrupan. Por este motivo, la función se ha convertido en una forma de hacer que las aplicaciones sean más comprensibles para sus creadores. En algunos idiomas, el mismo concepto puede denominarse subrutina o procedimiento.

La aplicación está dividida en funciones, cada una de las cuales tiene un propósito y una interfaz claramente definidos.

La idea de dividir procedimientos se puede ampliar agrupándolos en un objeto más grande llamado módulo, pero el principio es similar: agrupar componentes que ejecutan listas de instrucciones.

La división en funciones y módulos es una de las piedras angulares de la programación estructurada, que fue el paradigma dominante durante varias décadas antes de la llegada de la programación orientada a objetos.

Problemas de programación estructurada

A medida que las aplicaciones crecieron, la programación estructurada comenzó a tener problemas. Los proyectos se estaban volviendo demasiado complejos. Los horarios cambiaron. Más programadores estuvieron involucrados. La complejidad creció. Los costos se dispararon, el cronograma avanzó y se produjo el colapso.

El análisis de las razones de estos fracasos mostró las deficiencias del paradigma procesal. No importa qué tan bien se implemente un enfoque de programación estructurada, las aplicaciones grandes se vuelven demasiado complejas.

¿Cuáles son las causas de estos problemas asociados con los lenguajes procedimentales? En primer lugar, las funciones tienen acceso ilimitado a datos globales. En segundo lugar, los procedimientos y valores no relacionados no modelan bien el mundo real.

Al considerar estas cuestiones en el contexto de un programa de inventario, uno de los elementos de datos globales más importantes es la población de unidades contables. A ellos pueden acceder diversas funciones para introducir un nuevo valor, visualizarlo, cambiarlo, etc.

Acceso ilimitado

En un programa escrito, por ejemplo, en C, hay dos tipos de datos. Los locales están ocultos dentro de la función y no son utilizados por otros procedimientos.

Cuando dos o más funciones necesitan acceder a los mismos datos, estos últimos deben ser globales. Ésta es, por ejemplo, la información sobre los elementos que se tienen en cuenta. Se puede acceder a los datos globales mediante cualquier procedimiento.

Un programa grande tiene muchas funciones y muchos elementos globales. El problema con el paradigma procesal es que conduce a aún más conexiones potenciales entre ellos.

Un número tan elevado de conexiones plantea varias dificultades. En primer lugar, dificulta la comprensión de la estructura del programa. En segundo lugar, dificulta la realización de cambios. Un cambio en un elemento de datos global puede requerir ajustes en todas las funciones que acceden a él.

Por ejemplo, en un programa de contabilidad, alguien decide que el código del artículo que se está contabilizando no debe constar de 5 dígitos, sino de 12. Esto requerirá cambiar de corto a largo. Ahora las funciones relacionadas con el código deben cambiarse para que funcionen con el nuevo formato.

Cuando los elementos cambian en una aplicación grande, es difícil saber qué procedimientos tienen acceso a ellos. Pero incluso si esto se resuelve, cambiarlos puede provocar un funcionamiento incorrecto de otros datos globales. Todo está conectado con todo lo demás, por lo que un cambio en un lugar repercutirá en otro.

Simulación del mundo real

El segundo y más importante problema del paradigma procedimental es que su disposición de datos y funciones individuales no modela bien las cosas en el mundo real. Aquí se trata de objetos como personas y coches. No parecen datos ni funciones. Los objetos reales complejos tienen atributos y comportamiento.

Atributos

Ejemplos de atributos (a veces llamados características) para las personas son el color de ojos y el puesto de trabajo, y para los automóviles, la potencia y el número de puertas. Resulta que los atributos del mundo real son equivalentes a los datos de un programa. Tienen significados específicos, como azul (color de ojos) o cuatro (número de puertas).

Comportamiento

El comportamiento es lo que los objetos del mundo real producen en respuesta a algún tipo de influencia. Si le pides a tu jefe un aumento de sueldo, la respuesta será “sí” o “no”. Si pisas el freno, el coche se detendrá. Hablar y detenerse son ejemplos de comportamiento. Una conducta es como un procedimiento: está llamada a hacer algo y lo hace. Por tanto, los datos y funciones por sí solos no modelan eficazmente objetos del mundo real.

resolviendo el problema

Un objeto en programación orientada a objetos se representa como una colección de datos y funciones. Sólo los procedimientos, llamados funciones miembro en C++, le permiten recuperar sus valores. Los datos están ocultos y protegidos contra cambios. Los valores y funciones se resumen en un todo. Encapsulación y ocultación son los términos principales en la descripción de los lenguajes OO.

Si necesita cambiar datos, sabrá exactamente qué funciones interactúan con ellos. Ningún otro procedimiento puede acceder a ellos. Esto facilita la escritura, depuración y mantenimiento del programa.

Una aplicación normalmente consta de varios objetos que interactúan entre sí llamando a funciones miembro.

Hoy en día la programación más utilizada es C++ (plus-plus). Java carece de algunas características como punteros, plantillas y herencia múltiple, lo que lo hace menos potente y versátil que C++. C# aún no ha alcanzado la popularidad de C++.

Cabe señalar que las llamadas funciones miembro en C++ se denominan métodos en algunos otros lenguajes orientados a objetos, como Smalltalk. Los elementos de datos se denominan atributos. Llamar a un método en un objeto es enviarle un mensaje.

Analogía

Puedes imaginar objetos como departamentos de una empresa. En la mayoría de las organizaciones, los empleados no trabajan en RR.HH. un día, pagan la nómina al día siguiente y luego pasan una semana en el comercio minorista. Cada departamento tiene su propio personal con responsabilidades claramente asignadas. También hay datos propios: indicadores salariales, ventas, registros de empleados, etc. Las personas de los departamentos trabajan con su propia información. Por lo tanto, separar una empresa facilita el seguimiento de sus actividades y el mantenimiento de la integridad de los datos. El departamento de contabilidad es responsable de Si necesita saber el monto total de los salarios pagados en la sucursal sur en julio, no es necesario hurgar en los archivos. Basta con enviar una nota al responsable, esperar hasta que esta tenga acceso a los datos y envíe una respuesta con la información requerida. Esto garantiza el cumplimiento de la normativa y la ausencia de interferencias externas. De la misma manera, un objeto en POO proporciona organización a una aplicación.

Debe recordarse que la orientación a objetos no se refiere a los detalles de cómo funciona el programa. La mayoría de las declaraciones de C++ corresponden a operadores en lenguajes procedimentales como C. De hecho, las funciones miembro en C++ son muy similares a las funciones en C. Sólo un contexto más amplio determinará si una declaración es de procedimiento u orientada a objetos.

Objeto en programación orientada a objetos: definición

Al considerar un problema de programación en un lenguaje orientado a objetos, en lugar de hacer preguntas sobre cómo dividirlo en funciones separadas, surge el problema de dividirlo en objetos. El pensamiento OOP facilita mucho el desarrollo de aplicaciones. Esto ocurre como resultado de la similitud entre el software y los objetos reales.

¿Qué cosas se convierten en objetos en programación orientada a objetos? A continuación se muestran categorías típicas.

Un objeto físico en programación orientada a objetos es:

  • transporte en modelos de flujo;
  • elementos eléctricos en programas de diseño de circuitos;
  • países en el modelo económico;
  • aeronaves en el sistema de control de tráfico aéreo.

Elementos del entorno informático del usuario:

  • menú;
  • ventanas;
  • gráficos (línea, rectángulo, círculo);
  • teclado, mouse, impresora, unidades de disco.
  • trabajadores;
  • estudiantes;
  • clientela;
  • vendedores.
  • libro de contabilidad;
  • asunto personal;
  • diccionario;
  • tabla de latitudes y longitudes de zonas pobladas.

La conexión entre los objetos del mundo real y la programación orientada a objetos fue el resultado de la combinación de funciones y datos: revolucionaron la programación. No existe una correspondencia tan estrecha en los lenguajes procesales.

Clase

Los objetos en programación orientada a objetos son miembros de clases. ¿Qué significa? Los lenguajes de programación tienen tipos de datos integrados. El tipo int, es decir, un número entero, está predefinido en C++. Puedes declarar tantas variables int como quieras.

Un conjunto de objetos de la misma clase se define de manera similar. Define las funciones y datos incluidos en sus objetos sin crearlos, al igual que int no crea variables.

Una clase en programación orientada a objetos es una descripción de varios objetos similares. Prince, Sting y Madonna son cantantes. No existe nadie con este nombre, pero las personas pueden llamarse así si tienen las características adecuadas. Un objeto POO es una instancia de una clase.

Herencia

En la vida, las clases se dividen en subclases. Por ejemplo, los animales se dividen en anfibios, mamíferos, aves, insectos, etc.

El principio de este tipo de división es que cada subclase tiene características comunes con la clase de la que desciende. Todos los coches tienen ruedas y motor. Estas son las características que definen a los vehículos. Además de las características generales, cada subclase tiene sus propias características. Los autobuses tienen muchos asientos y los camiones tienen espacio para transportar cargas pesadas.

Del mismo modo, una clase base puede convertirse en padre de varias subclases derivadas, que pueden definirse para compartir sus características y agregar las suyas propias. La herencia es como una función que simplifica un programa procesal. Si varios fragmentos de código hacen casi lo mismo, puede extraer los elementos comunes y colocarlos en un solo procedimiento. Tres partes de la aplicación pueden llamar a una función para realizar acciones comunes, pero también pueden realizar sus propias operaciones. De manera similar, una clase base contiene datos comunes a un grupo de clases derivadas. Al igual que las funciones, la herencia acorta un programa orientado a objetos y deja claras las relaciones entre sus elementos.

Reutilizar

Una vez que se ha creado y depurado una clase, se puede compartir con otros programadores para reutilizarla en sus propias aplicaciones. Es como una biblioteca de funciones que se pueden incluir en diferentes aplicaciones.

En POO, la herencia es una extensión de la idea de reutilización. A partir de una clase existente, sin cambiarla, se puede crear una nueva con la adición de otras funciones. La facilidad de reutilizar el software existente es una ventaja importante de la programación orientada a objetos. Se cree que esto proporcionará mayores rendimientos de la inversión inicial.

Crear nuevos tipos de datos

Los objetos son útiles para crear nuevos tipos de datos. Supongamos que un programa utiliza valores bidimensionales (por ejemplo, coordenadas o latitud y longitud) y desea expresar operaciones con ellos mediante operaciones aritméticas:

posición1 = posición + origen,

donde y origen son pares de valores numéricos independientes. Crear una clase que incluya estos dos valores y declarar sus variables como objetos crea un nuevo tipo de datos.

Polimorfismo, sobrecarga

Los operadores = (igual) y + (más) utilizados en la aritmética posicional anterior no funcionan de la misma manera que con los tipos integrados como int. Los objetos de posición, etc. no están predefinidos, sino que se definen mediante programación. ¿Cómo saben estos operadores cómo manejarlos? La respuesta es que se les pueden asignar nuevos patrones de comportamiento. Estas operaciones serán funciones miembro de la clase Posición.

El uso de operadores o procedimientos dependiendo de sobre qué operan se llama polimorfismo. Cuando a un operador existente como + o = se le da la capacidad de trabajar con un nuevo tipo de datos, se dice que está sobrecargado. La sobrecarga en programación orientada a objetos es un tipo de polimorfismo. Es su característica importante.

El libro sobre programación orientada a objetos para principiantes permitirá a todos familiarizarse con este tema con más detalle.

Básicamente utilizó un paradigma de programación prescriptivo: el objetivo era crear código que actuara apropiadamente sobre los datos. Este enfoque es bueno para resolver problemas pequeños, pero crea muchos problemas difíciles de resolver cuando se intenta crear grandes sistemas de software.

Una de las alternativas programación directiva es programación orientada a objetos, cual en realidad ayuda a hacer frente a la creciente complejidad no lineal de los programas a medida que aumenta su volumen. Sin embargo, no se debe concluir que el uso del paradigma de programación orientada a objetos garantiza una solución exitosa a todos los problemas.

Para convertirse en un profesional de la programación se necesita talento, creatividad, inteligencia, conocimiento, lógica, capacidad para construir y utilizar abstracciones y, lo más importante, experiencia.

En esta sección, continuaremos nuestra introducción a los conceptos básicos de la programación orientada a objetos, que comenzamos en el primer capítulo del libro. Primero, se discutirán los conceptos de programación orientada a objetos comunes a varios lenguajes de programación y luego su implementación en el lenguaje Java.

Debe tener en cuenta que el curso sobre programación orientada a objetos se imparte a estudiantes universitarios durante un semestre completo y, por lo tanto, el material que se presenta a continuación representa sólo una introducción muy básica al mundo de la programación orientada a objetos. El libro contiene una cobertura mucho más completa de muchos de los temas relacionados con el diseño, la ingeniería y la programación orientados a objetos, y en el tercer capítulo del libro puede encontrar una descripción muy clara de todos los aspectos orientados a objetos de Java. idioma.

Conceptos básicos de programación orientada a objetos

Programación orientada a objetos o POO (programación orientada a objetos) - metodología de programación basado en la representación de un programa como una colección de objetos, cada uno de los cuales es una implementación de un cierto tipo, utilizando un mecanismo reenviar mensajes y clases organizadas en jerarquía de herencia.

El elemento central de la programación orientada a objetos es la abstracción. Los datos se convierten en objetos mediante abstracción y la secuencia de procesamiento de estos datos se convierte en un conjunto de mensajes que se pasan entre estos objetos. Cada uno de los objetos tiene su propio comportamiento único. Los objetos pueden tratarse como entidades concretas que responden a mensajes que les ordenan realizar alguna acción.

La programación orientada a objetos se caracteriza por los siguientes principios (según Alan Kay):

  • todo es un objeto;
  • los cálculos se llevan a cabo mediante la interacción (intercambio de datos) entre objetos, en la que un objeto requiere que otro objeto realice alguna acción; los objetos interactúan enviando y recibiendo mensajes; un mensaje es una solicitud para realizar una acción, complementada con un conjunto de argumentos que pueden ser necesarios al realizar la acción;
  • cada objeto tiene un independiente memoria, que consta de otros objetos;
  • cada objeto es un representante de una clase que expresa las propiedades generales de los objetos de un tipo determinado;
  • ambientado en clase funcionalidad(comportamiento del objeto); así, todos los objetos que son instancias de la misma clase pueden realizar las mismas acciones;
  • Las clases se organizan en una única estructura de árbol con una raíz común, llamada jerarquía de herencia; la memoria y el comportamiento asociados con instancias de una clase particular están automáticamente disponibles para cualquier clase inferior en el árbol jerárquico.

Definición 10.1. Abstracción- un método para resolver un problema en el que objetos de diversos tipos se unen por un concepto común (concepto), y luego las entidades agrupadas se consideran elementos de una sola categoría.

Abstracción le permite separar el significado lógico de un fragmento de programa del problema de su implementación, dividiendo descripción externa(interfaz) de un objeto y su organización interna(implementación).

Definición 10.2. Encapsulación- una técnica en la que se oculta en su interior información insignificante desde el punto de vista de la interfaz del objeto.

Definición 10.3. Herencia- una propiedad de los objetos a través de la cual las instancias de una clase obtienen acceso a los datos y métodos de las clases antecesoras sin redefinirlos.

La herencia permite que diferentes tipos de datos compartan el mismo código, lo que da como resultado un código más pequeño y una mayor funcionalidad.

Definición 10.4.

Hola a todos.

Una semana de artículos sobre Habré dedicados a la programación orientada a objetos. El último artículo me provocó muchas emociones y, lamentablemente, muy malas emociones. Realmente no me gustó el artículo. ¿Por qué? Porque transmite algunas emociones negativas sobre el uso de programación orientada a objetos. Las emociones son causadas únicamente por el hecho de que una persona no comprende completamente todo el poder de la POO y quiere convencer a todos de que la POO es mala. Lo más triste es que la gente empieza a escuchar y a lanzar argumentos terribles que nada tienen que ver con la realidad. Creo que este tipo de artículos están más contraindicados para los estudiantes que GoF, que recomendaría lo antes posible. :)

Empecemos.

¿Qué es la programación orientada a objetos? OOP es tanto programación como diseño OO. Uno sin el otro carece casi por completo de sentido. Creé POO para diseñar/programar productos de software. No para modelado de procesos. No para diseñar protocolos, sino específicamente para productos de software, para su implementación. Simplificar un sistema que implementará un protocolo o proceso comercial o algo más.

Cuando empiezas a utilizar la programación orientada a objetos, lo primero que debes hacer es empezar a utilizar el pensamiento de objetos. Ya dije una vez que este es el mayor problema de la programación orientada a objetos; aprender a pensar objetivamente es muy difícil. Y es muy importante aprender a hacer esto lo antes posible (GoF con analogías como puente, constructor, fachada ayudará mucho con esto). Usando el pensamiento de objetos, puedes diseñar fácilmente sistemas complejos. Usando el pensamiento de objetos, puedes resolver fácilmente cualquier problema (es muy importante que cualquier problema de diseño/programación, si en principio se puede resolver absolutamente cualquiera) operando con objetos y la interacción entre a ellos. Aquellos. La programación orientada a objetos sin pensamiento de objetos no le permitirá comenzar a utilizar todo el poder y la fuerza de la programación orientada a objetos.

Sigamos adelante. Por eso, es importante que pensemos objetivamente para encontrar las abstracciones de objetos que necesitamos para resolver nuestros problemas. Si se eligen bien las analogías y abstracciones, entonces vemos una imagen muy clara que nos permite comprender rápidamente lo que está sucediendo en el sistema. Y aquí empezamos a recordar sobre la herencia y el polimorfismo. Estas dos herramientas son necesarias para escalar fácilmente el sistema sin duplicar código. Pero la fuerza de estos mecanismos depende del éxito de las abstracciones y analogías que elijas. Si su pensamiento de objetos no le permite formar una descomposición conveniente de los objetos, entonces la herencia y el polimorfismo no le ayudarán. Aquellos. la herencia y el polimorfismo no son más que herramientas que permiten resolver el problema del escalado del sistema.

¿Cómo funcionan estas herramientas? Sí, es más sencillo que los nabos al vapor, porque todo se basa en cosas que nos resultan familiares. Me encantan los ejemplos sencillos de la vida:

1. Herencia. Hay un panadero. Hay un horno eléctrico y de gas. Tu tarea es simular el proceso de cocción de un panadero en cada uno de los hornos. Resolviendo el problema de frente, tendremos mucha duplicación de código debido a que el proceso de transferencia de alimentos al horno y el trabajo con los hornos son idénticos para ambos hornos. Pero si activamos el pensamiento de objetos y recordamos la herramienta de herencia, obtenemos algo como lo siguiente (demasiado vago para dibujar un diagrama, lo siento):
Hay una estufa (estufa abstracta). Tiene un comportamiento: encender, apagar, aumentar o disminuir la temperatura, poner algo, sacar algo y un estado: la temperatura en el horno, encendida o apagada. Este es un excelente ejemplo de un objeto abstracto que sigue los principios de encapsulación (definitivamente los seguiré al implementarlos). Y hay un panadero, un panadero concreto, Iván. Sabe trabajar con un horno abstracto. Aquellos. vigilar la temperatura, encenderlo y apagarlo, etc. tú entiendes. El poder de la herencia es que no tenemos que reescribir nuestro Iván para cada una de las estufas, ya sea eléctrica o de gas. Creo que está claro para todos por qué. Resulta que la herramienta se aplicó correctamente.
2. Polimorfismo. Los hornos funcionan de manera diferente. Una estufa de gas consume gas, una estufa eléctrica consume electricidad. Usando polimorfismo podemos cambiar fácilmente el comportamiento en los sucesores del horno abstracto.
3. Encapsulación. Lo principal de la encapsulación es que no tengo que saber qué sucede dentro de mi horno. Digamos que no llamo al método para encender el horno, sino que cambio su propiedad enable a verdadera. ¿Qué pasará en este momento? Si no se respeta el principio de encapsulación, me veré obligado a decirle a la estufa que empiece a consumir combustible, porque... Te excité. Aquellos. el panadero sabe que el horno consume combustible y sabe cómo funciona. O, por ejemplo, no podemos poner la temperatura del horno por debajo o por encima de un determinado nivel. Si no cumplimos con el principio de encapsulación, entonces tendremos que decirle al horno que compruebe la temperatura actual, ¿funcionará? Aquellos. El panadero vuelve a saber demasiado sobre el horno. Los captadores y definidores son herramientas de lenguaje que nos ayudan a implementar fácilmente el seguimiento de cambios de estado. Todo. Si los captadores y definidores están vacíos, entonces así es como debería ser en mi nivel de abstracción. Los captadores y definidores no pueden interferir con la implementación de la encapsulación; un diseñador/programador puede implementar la encapsulación de manera torcida.

En este ejemplo, el nivel de abstracción está bien elegido. Cada uno se ocupa de sus propios asuntos, los tres pilares de la OLP están trabajando para la gloria. Pero en cuanto elijo malas abstracciones, comienza una auténtica pesadilla. E incluso existen estándares de listas de verificación que te ayudarán a comprender si has elegido bien las abstracciones y si tu descomposición es correcta en la dirección en la que vas (SÓLIDO).

También comenzaron a agregar la abstracción como otro pilar de la programación orientada a objetos. Creo que esto probablemente sea cierto, pero realmente huele a CEP.

También me llamaron la atención las afirmaciones sobre la tipificación. El caso es que no hay problemas con con cuál de los herederos estás trabajando actualmente. Si en el nivel actual de abstracción para usted es importante utilizar el horno, entonces no le importa qué sea. ¿Tienes una estufa? ¿Estás resolviendo tus problemas? Esto y aquello... No me queda claro por qué crees que se trata de escritura dinámica. ¿Querías hornear? Tómalo. ¿Necesitas eléctrico? Bueno, lo siento, la gasolina ya no te conviene.

Los ejemplos restantes que se dieron en el artículo que me llamó la atención son solo ejemplos de abstracción y analogía repugnantemente elegidas en el marco de la tarea en cuestión. Punto.

Por separado sobre DTO. DTO es un patrón. Le permite crear un objeto que transferirá información a otra capa, a otro sistema, en resumen, transferirá algo a alguna parte. Por qué no puedo considerarlo como un objeto es generalmente un misterio para mí. ¿Dónde está la contradicción? ¿Es sólo contenedor? ¿¿Así que lo que?? Este es un objeto dentro del marco del modelo de objetos que consideré en un nivel dado de abstracción, donde DTO es un objeto y parte de la descomposición.

Tampoco está claro qué decir sobre los idiomas. Puedo diseñar software utilizando el enfoque basado en objetos, independientemente del idioma. Pero si el lenguaje no implementa las herramientas básicas para trabajar con objetos, entonces me resultará muy difícil o imposible implementar el sistema que diseñé.

También dicen que algunas cosas no se pueden representar en forma de objetos y sus interacciones. Estoy seguro de que ese no es el caso. Sólo necesitas elegir el nivel correcto de abstracción. Ya sea la implementación de un protocolo, una capa de acceso a la base de datos, complementos de conexión, un administrador de tareas, un proceso de negocio, un sistema de diseño de procesos de negocio, etc. cualquier cosa puede representarse como objetos y sus interacciones. Todo se puede implementar como objetos e interacciones entre ellos. Si esto es bueno o malo depende en la mayoría de los casos sólo de su capacidad de pensar objetivamente.

Para resumir. Si no comprende el poder de la programación orientada a objetos, lo más probable es que necesite desarrollar el pensamiento de objetos.

PD En los comentarios al último artículo, claramente fui demasiado lejos al dirigirme a algunas personas. Mis disculpas.

Evento en programación orientada a objetos. - Este es un mensaje que aparece en varios puntos del código ejecutable cuando se cumplen ciertas condiciones. Los eventos están diseñados para poder predecir cómo reaccionará el software. Para resolver este problema, se crean controladores de eventos: tan pronto como el programa ingresa a un estado determinado, ocurre un evento, se envía un mensaje y el controlador intercepta este mensaje. En el caso general, no se pasa nada al controlador o se pasa una referencia al objeto que inició (generó) el evento que se está procesando. En casos especiales, los valores de algunas variables o referencias a otros objetos se pasan al controlador para que el procesamiento de este evento pueda tener en cuenta el contexto del evento. El evento más simple es un evento que señala el inicio o la finalización de algún procedimiento. Básicamente, un evento informa un cambio en el estado de algún objeto. Los eventos se presentan más claramente en la interfaz de usuario, cuando cada acción del usuario genera una cadena de eventos, que luego se procesan en la aplicación. En el análisis orientado a objetos, es común utilizar un modelo de estado para describir el comportamiento dinámico de los objetos. Un evento es la transición de un objeto de un estado a otro. La interacción de objetos también se lleva a cabo mediante eventos: un cambio en el estado de un objeto conduce a un cambio en el estado de otro objeto, y el evento resulta ser un medio de comunicación entre objetos. El evento es este. A continuación, se destacan cuatro aspectos del evento:

La primera fila de eventos de ejemplo proporciona el ciclo de vida real del objeto:

  • creación de objetos;
  • destrucción de un objeto.

Ejemplos más complejos de eventos surgen cuando un objeto tiene estados internos que se describen mediante un diagrama de transición correspondiente (de un estado a otro).

Los lenguajes de programación modernos orientados a objetos son C++ Y Java. Desde mediados de la década de 1990, muchos lenguajes orientados a objetos se han implementado como sistemas de programación visual, en el que la parte de la interfaz de un producto de software se crea de forma interactiva, prácticamente sin escribir declaraciones del programa. Los sistemas de diseño visual orientados a objetos incluyen Visual Básico , Delfos , Constructor C++,Visual C++. El lenguaje VBA (Visual Basic para Aplicaciones) es el lenguaje de las aplicaciones de Microsoft Office ( Sobresalir , Palabra , Acceso , PowerPoint etc.). Vba respeta la sintaxis básica del lenguaje y las reglas de programación Idiomas básicos– dialectos, permite crear macros para automatizar la ejecución de determinadas operaciones y una interfaz gráfica de usuario, integración entre varios productos de software.

El propósito del curso es proporcionar a los estudiantes una comprensión de los principios básicos de la programación orientada a objetos en varios lenguajes. El objetivo principal del curso es formar especialistas que dominen los métodos y medios modernos para desarrollar algoritmos y programas, y que conozcan los conocimientos modernos. tecnología de programación y aquellos que saben aplicarlo a la hora de resolver problemas aplicados complejos. El curso de conferencias está diseñado para estudiantes con formación en Ciencias de la Computación Y programación en lenguaje c.

Trabajo de laboratorio

  1. Programación orientada a objetos para principiantes
  2. Adobe Flash Lab 1: dibujo y sombreado
  3. Adobe Flash Lab 2: símbolos y sus transformaciones
  4. Adobe Flash Lab 7: animación enmarcada
  5. Adobe Flash Lab 9: Insertar un objeto Flash en un archivo HTML
  6. Programación orientada a objetos en JavaScript. laboratorio 1
    Conceptos básicos y definiciones: objeto, método, propiedades, eventos.
  7. Programación orientada a objetos en JavaScript. Laboratorio 3. Formulario, botón, campo de texto
  8. Programación orientada a objetos en JavaScript. Laboratorio 4. Tipos de datos. Variables. Operaciones aritméticas. Operación condicional
  9. Introducción a la interfaz, objetos y nuevas características de MS Access 2007.
  10. Laboratorio.2. Modificación de base de datos. Usando tablas vinculadas. Crear formularios e informes

Literatura

  1. Bruno Bebé. Simple y claro sobre Borland C++: Versiones 4.0 y 4.5/Trans. del ingles -M.: BINOM, 1994. - 400 p.
  2. Buch G. “Análisis y diseño orientado a objetos con ejemplos de aplicaciones en C++” Trans. del ingles - M.: Binomio; San Petersburgo: dialecto Nevsky, 1999.
  3. . - M, 2000
  4. Gaisaryan S.S. “Diseño orientado a objetos” (http://www.mista.ru/oop_book/index.htm)
  5. Zhukov A. "Estudiar C" - San Petersburgo: Peter, 2003.
  6. - Sistemas Adobe, 2010.
  7. Ishkova E. “El comienzo de la programación en C++” - M.: Binom, 2001.
  8. Klochkov D.P., Pavlov D.A. Introducción a la programación orientada a objetos. / Manual educativo y metodológico. - Ed. Nizhegorsk Universidad, 1995. - 70 p.
  9. Legalov A. “Resultados de la expansión del paradigma orientado a objetos” (http://www.softcraft.ru/paradigm/process/pr01.shtml
  10. Mukhortov V.V., Rylov V.Yu. (manual metodológico) - IMSO RAS, Novosibirsk, 2002
  11. Nemnyugin S., Perkolab L. “Aprendiendo TurboPascal
  12. Pliskin M. “Evolución de los lenguajes de programación” (://2..cctpu../edu///lang/_09.)
  13. . - MEPI, 2003
  14. Metodología de programación orientada a objetos (http://www.math.rsu.ru/smalltalk/sml-a.ru.html)
  15. Sistemas orientados a objetos: estado y perspectivas. Revisión analítica basada en materiales de OVUM. Revisión preparada por A.G. Ivánov. (http://www.math.rsu.ru/smalltalk/obzornew.ru.html)
  16. Lenguajes de programación orientados a objetos. Comparación con lenguas tradicionales (://.suvvbcourse/1.)
  17. Patrikeev Yu.N. “Diseño orientado a objetos” (http://www.object.newmail.ru/oop1.html)
  18. Patrikeev Yu.N. “Programación orientada a objetos en Borland C++” (http://www.object.newmail.ru/obj0.html)
  19. Principios de la programación orientada a objetos - Conferencias sobre el sistema de diseño visual orientado a objetos Delphi - Conferencias (http://blackman.wp-club.net/lection/visualprg.php)
  20. Estilos de programación (http://media.karelia.ru/~ftt/IVK/new2/Inflect/T_1_16.htm)
  21. Stroustrup B. lenguaje de programación c++(2ª ed.)./Trad. De inglés-M.: Radio y Comunicaciones, 1995. - 352 p.




Arriba