{"id":229808,"date":"2022-11-20T17:56:00","date_gmt":"2022-11-20T14:56:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=229808"},"modified":"2022-11-20T17:56:39","modified_gmt":"2022-11-20T14:56:39","slug":"los-dos-primeros-pilares-de-la-programacion-orientada-a-objetos","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/es\/los-dos-primeros-pilares-de-la-programacion-orientada-a-objetos\/","title":{"rendered":"Los dos primeros pilares de la programaci\u00f3n orientada a objetos"},"content":{"rendered":"\n

Cuando se trata de hablar de programaci\u00f3n orientada a objetos (o POO), es probable que escuche hablar de Los tres pilares de la programaci\u00f3n orientada a objetos o Los cuatro pilares de la programaci\u00f3n orientada a objetos.<\/p>\n

Dependiendo de sus antecedentes, es posible que ya haya o\u00eddo hablar de ellos, sepa lo que son y realmente no necesita sumergirse demasiado en ellos. Pero si no lo ha hecho, creo que comprenderlos es fundamental para la programaci\u00f3n orientada a objetos.<\/p>\n

Hemos cubierto toda la fase de An\u00e1lisis<\/a><\/strong> de la Programaci\u00f3n Orientada a Objetos:<\/p>\n

    \n
  1. An\u00e1lisis, Parte 1<\/a><\/li>\n
  2. An\u00e1lisis, Parte 2<\/a><\/li>\n
  3. Comprender las expectativas del cliente<\/a><\/li>\n
  4. Declaraci\u00f3n de trabajo<\/a><\/li>\n
  5. T\u00e9rminos y condiciones<\/a><\/li>\n<\/ol>\n

    Dicho esto, entremos en las discusiones de dise\u00f1o e implementaci\u00f3n. Despu\u00e9s de todo, esto es a lo que muchas personas quieren saltar de todos modos, \u00bfno es as\u00ed?<\/p>\n

    \"Los<\/a><\/p>\n

    Antes de escribir cualquier c\u00f3digo, me gustar\u00eda hacer dos posts sobre los cuatro puntos de la programaci\u00f3n orientada a objetos (porque soy de los que suscribe la idea de que son cuatro).<\/p>\n

    Dos pilares de la programaci\u00f3n orientada a objetos<\/h2>\n

    Nuevamente, comprender esto es clave para comprender la base de la programaci\u00f3n orientada a objetos. Sin ellos, ser\u00e1 dif\u00edcil navegar por el resto de lo que se discutir\u00e1 en publicaciones futuras.<\/p>\n

    Con eso, hablemos de cada uno de ellos. Cubriremos los dos primeros en esta publicaci\u00f3n y los dos \u00faltimos en la pr\u00f3xima publicaci\u00f3n.<\/p>\n

    1 Abstracci\u00f3n<\/h3>\n

    En t\u00e9rminos generales, esta es la clave para escribir c\u00f3digo orientado a objetos. Por eso, me refiero a todo lo que est\u00e1 contenido dentro de una clase. Abstraemos la idea de algo en una clase. En muchos libros, veremos cosas como Animales<\/strong> o Autos<\/strong> representados como clases.<\/p>\n

    Esto funciona, en teor\u00eda, pero en la pr\u00e1ctica, no estamos programando animales ni estamos programando autos (aunque supongo que en este punto de la historia, podr\u00edas argumentar que lo estamos, pero estoy divagando porque sabes a lo que me refiero).<\/p>\n

    En cambio, vamos a abstraer ideas en sus clases. Y hay una idea clave aqu\u00ed:<\/p>\n

    \n

    Una clase debe representar un sustantivo.<\/p>\n<\/blockquote>\n

    Es decir, no deber\u00eda tener una clase que represente algo como "Correr". En su lugar, puede tener algo que se ejecuta y, por lo tanto,\u00a0 las ejecuciones<\/strong> ser\u00edan un m\u00e9todo. Y ese es el desglose general de c\u00f3mo funciona la abstracci\u00f3n:<\/p>\n

      \n
    1. Lo que se va a representar es la clase,<\/li>\n
    2. Lo que hace la cosa son sus m\u00e9todos,<\/li>\n
    3. Y la forma en que describe la cosa generalmente se puede hacer a trav\u00e9s de sus atributos o propiedades.<\/li>\n<\/ol>\n

      Esto no quiere decir que no tengamos funciones o m\u00e9todos que modifiquen sus propiedades, pero los tres puntos anteriores son buenas reglas generales. Entonces, cuando est\u00e1s dise\u00f1ando una clase, puedes preguntar cosas como:<\/p>\n