PROGRAMACIÓN ESTRUCTURADA VS POO

Programación Estructurada Vs. Programación Orientada a Objetos

A lo largo de la historia se han ido desarrollando distintos lenguajes de programación basados en distintos paradigmas o formas de estructurar y pensar el desarrollo de software.

A principios de la década de 1980 comenzó a surgir el llamado paradigma de “Orientación a Objetos”, que proponía una forma novedosa de comprender y modelar el mundo que nos rodea. Su uso se popularizó a principios de la década de los años 1990 y hoy, luego de varias décadas, este paradigma es sin duda uno de los principales y más importantes en la escena del desarrollo de software.

Hay paradigmas para todos los gustos:

l Estructurados (C, Pascal, Basic, etc.)

l Funcionales (CAML)

l Declarativos (Prolog)

l Orientados a Objetos (C#, VB.NET, Smalltalk, Java)

l Orientados a Aspectos

l Híbridos (Lisp, Visual Basic)

l Incomprensibles….

Donde cada enfoque tiene sus ventajas y desventajas y cada uno es el más apropiado para ciertas cosas. Los más conocidos son los Estructurados, los Híbridos y los Orientados a Objetos.

La programación orientada a objetos o POO es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento.

A diferencia del paradigma estructurado, que propone modelar a la realidad como una serie de procedimientos secuenciales, la orientación a objetos propone representar todo lo que conocemos en términos de entidades (objetos) que interactúan y se relacionan entre sí. Estas entidades pueden representar absolutamente cualquier cosa, desde algo físico y tangible como una persona, una factura o un auto, hasta cosas intangibles como la imaginación, un proceso químico o un algoritmo matemático.

La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan.

En la programación estructurada sólo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

La mayoría de los programadores que tienen conocimientos de paradigmas estructurados tienden a encarar la orientación a objetos como un agregado más a aquellos, o sólo como una forma ligeramente distinta de hacer lo mismo. La realidad nos dicta que para ser buenos programadores orientados a objetos deberemos entender y modelar la realidad de una manera distinta.

En la actualidad, el paradigma de orientación a objetos es sin lugar a dudas el más utilizado por las empresas de todo el mundo a la hora de encarar desarrollos de aplicaciones de software, ya que permite representar de manera relativamente simple modelos y realidades muy complejas y esto hace que el software sea más fácil de programar, comprender y mantener.

public static void main(String[] args){
  String sentence = "NVL-h_ey_hey-_";
  String[] list = {"NVL", "_", "-"};
  for (int i=0; i < list.length; i++){
    sentence = sentence.replace(list[i], "");
  }
  System.out.print(sentence);
}

heyhey

No, eso no es así.

El error proviene de la consulta parametizada, no de un método/función/constructor que reciba parámetros, el mensaje de error en esa situación sería muy distinto, además, ese tipo de error no dejaría compilar el código, es decir, sería un error de compilador y la sintaxis quedaría resaltada en la IDE, por ende, se podría localizar el conflicto en seguida.

Este es un error en tiempo de ejecución, lanzado por el método com1.ExecuteNonQuery() o com2.ExecuteNonQuery() (o tal vez ambos), y el tipo de excepción que tiene es esta:
➢ OleDbException con mensaje de error:

En resumen, el error está en la consulta, ya sea query1 o query2 o ambas, en la forma de construirla o en la forma de añadir los parámetros, pero no manejo SQL así que no puedo aportar más.

En la query1 estás preguntando por 2 parámetros, y estás asignando a ambos el valor, en la query2 estás preguntando por 1 parámetro, y también lo estás asignando, es decir, todo parece correcto, pero como ya digo no manejo SQL y obviamente existe algún conflicto si no te funciona.

Saludos!

No overload for method 'MethodName' takes X arguments;

Namespace.ClassName does not contain a constructor that takes X arguments

query2 = "SELECT Id_Nota, Nota, [Fecha Trimestre], Tipo, Etapa, Dni, Nombre, Apellido, id_alumMatCurso From Notas N Where N.id_alumMatCurso = @idCurMater";

SELECT id_cursoMateria From CursosMaterias cm Where cm.id_Curso = @idCurso AND cm.id_Materia = @idMateria

SELECT Id_Nota, Nota, [Fecha Trimestre], Tipo, Etapa, Dni, Nombre, Apellido, id_alumMatCurso From Notas N Where N.id_alumMatCurso = @idCurMater

SELECT id_cursoMateria From CursosMaterias AS cm Where cm.id_Curso = @idCurso AND cm.id_Materia = @idMateria

SELECT Id_Nota, Nota, [Fecha Trimestre], Tipo, Etapa, Dni, Nombre, Apellido, id_alumMatCurso From Notas AS N Where N.id_alumMatCurso = @idCurMater

¿En qué línea te da la excepción?

No se han especificado valores para algunos de los parámetros requeridos

Hola, muchas gracias por tu respuesta, lo aprecio mucho, lo mas probable es que lo haga así como tu dices, Gracias

Saludos.

Ok, no lo había leído. En ese caso mi sugerencia es cambiar la regla de las chinchetas.