トランスクリプトSpanish

Los 6 patrones de diseño más utilizados

8m 59s1,521 単語245 segmentsSpanish

全トランスクリプト

0:00

En ingeniería de software, los patrones

0:01

de diseño son una solución general y

0:04

reutilizable para problemas comunes que

0:06

ocurren en un determinado contexto

0:08

cuando nos encontramos diseñando

0:10

aplicaciones. Estas no son una solución

0:12

final que luego se transforma en código

0:14

fuente, sino que son una descripción o

0:16

plantilla que puedes utilizar tú en

0:18

determinado momento.

0:21

[Música]

0:24

Hola mundo y bienvenidos a este video.

0:26

Los patrones de diseño son la

0:27

formalización de buenas prácticas que un

0:29

ingeniero de software puede utilizar

0:31

para resolver problemas comunes. En

0:33

programación orientada a objetos, los

0:35

patrones de diseño, por lo general

0:37

muestran relaciones e interacciones

0:39

sobre los distintos objetos y clases,

0:41

aunque patrones que impliquen

0:43

mutabilidad no son útiles cuando se está

0:45

utilizando un paradigma funcional

0:47

estricto. Algunos patrones podrían ser

0:48

hasta catalogados de innecesarios o

0:50

inútiles dependiendo del paradigma,

0:53

lenguaje o librerías que estemos

0:54

utilizando, ya que estos ya podrían

0:56

tener soluciones específicas para poder

0:58

resolver esos problemas. En este video

1:01

nosotros veremos seis patrones de

1:02

diseño, pero no debes pensar de que

1:04

estos son balas de plata, ya que

1:06

utilizar alguno de estos patrones podría

1:08

ser una pésima idea dependiendo de tu

1:10

contexto. Pero antes de mencionarte los

1:12

seis patrones de diseño y qué problemas

1:14

estos resuelven, tengo que decirte que

1:16

el botón de me gusta acaba de escribir

1:18

código espaghetti. Y esta es una pésima

1:20

práctica en el desarrollo de software,

1:22

por lo que para que ese maldito aprenda

1:23

que no debe seguir escribiendo código

1:25

espaghetti, debes golpearlo un número

1:27

par de veces hasta que quede en azul.

1:29

Cuando el botón de me gusta quede en

1:31

azul, él habrá aprendido que ya no debe

1:33

seguir escribiendo código espaguagetti.

1:34

Y si golpeas el botón de me gusta, harás

1:36

que nuestra comunidad de desarrollo sea

1:38

muchísimo mejor, ya que el botón de me

1:40

gusta se habrá encaminado en escribir

1:41

código de mejor calidad. Y ya que ese

1:43

maldito está en azul, continuamos con

1:45

nuestro video. En ingeniería de

1:46

software, el patrón Singleton restringe

1:49

la instanciación de una clase a solo una

1:51

única instancia. Esto es útil cuando

1:54

necesitas solo una instancia de una

1:55

clase para poder coordinar acciones

1:58

entre distintos sistemas. Si tu sistema

2:00

solo tiene una base de datos, singleton.

2:02

Si tienes solo una API, singleton. Si

2:04

tienes que conectarte con un servicio

2:06

como AWS y solo con una instancia de

2:09

este, Singleton. Dependiendo del

2:11

lenguaje podría ser que no necesites

2:13

implementar una clase de singleton. En

2:15

Node JS puedes implementar un objeto

2:17

literal y exportarlo. Esto se comportará

2:19

igual que un singleton, ya que el motor

2:21

de Node tiene implementado un caché con

2:23

las variables exportadas, por lo que

2:25

siempre será la misma. Pero en caso de

2:27

Java, que tiene una implementación más

2:29

estricta, debe implementarse de la

2:31

siguiente manera. Primero se crea la

2:33

clase. Luego defines una propiedad

2:35

llamada Singleton, la cual tendrá la

2:38

instancia que creamos. Luego definimos

2:40

un constructor llamado Singleton. Ese

2:43

constructor se encargará de construir el

2:45

objeto que vamos a necesitar en un

2:47

futuro. Luego creamos un método llamado

2:49

get instance, que se encargará de

2:51

devolver la instancia de nuestro

2:52

singleton. En programación orientada a

2:54

objetos, el patrón decorador es un

2:56

patrón que permite agregar

2:58

funcionalidades a un objeto sin alterar

3:00

el comportamiento de otras instancias de

3:02

objetos de la misma clase. Soluciona el

3:04

problema de agregar o quitar

3:06

responsabilidades a un objeto en el

3:08

rantime y es una alternativa flexible a

3:11

las subclases. Y una implementación en

3:13

Java se vería algo más o menos así. Si

3:16

vamos a vender café, vamos a necesitar

3:18

saber el precio de este y también vamos

3:21

a necesitar saber sus ingredientes, que

3:23

claro, el café tiene café, pero

3:26

podríamos querer vender también café con

3:28

leche. Y en lugar de crear una nueva

3:30

clase y reimplementar los métodos, lo

3:33

mejor sería tomar la tasa que ya existe

3:36

y pasarla por el constructor a una clase

3:38

con leche. Esta clase crea métodos con

3:41

los mismos nombres, pero llama primero a

3:44

los métodos del objeto café. Y cuando

3:46

alguien solicite el precio, agregamos el

3:49

valor de la leche. Y cuando alguien

3:51

solicite los ingredientes, agregamos

3:53

también como ingrediente la leche.

3:58

En ingeniería de software, el patrón

4:00

mediador define un objeto, el cual

4:02

encapsula cómo otros objetos van a

4:05

interactuar. Este patrón se considera un

4:08

patrón de comportamiento, ya que puede

4:10

alterar cómo se ejecuta la aplicación.

4:12

Un patrón mediador en JavaScript definir

4:15

de la siguiente manera. Primero,

4:17

definimos un ifi, que significa

4:19

inmediate invoked expression. A esta le

4:22

agregamos una variable, la que contendrá

4:24

los eventos que pueden despacharse o

4:26

escucharse. Seguido, creamos una función

4:29

llamada subscribe. Esta se encargará de

4:31

recibir el evento y también la función

4:34

que se ejecutará. Esta debe quedar

4:36

registrada en nuestra variable de

4:37

eventos. Después creamos una función

4:39

llamada dispatch. Esta recibirá el

4:42

evento que se está despachando y también

4:44

la data que se le pasará como argumento

4:46

a la función que suscribiremos. Esta

4:48

función recorrerá todos los eventos que

4:50

se encuentran registrados y de encontrar

4:53

uno o más de uno, ejecutará las

4:55

funciones y pasará los datos a cada una

4:57

de estas. Luego retornamos estas

4:59

funciones y con eso ya construimos

5:02

nuestro mediador. La diferencia entre un

5:04

mediador y un observador es que el

5:06

mediador necesita un objeto aparte

5:08

encargado de manejar las comunicaciones

5:11

entre todos los objetos, mientras que el

5:13

observador modifica el objeto que tiene

5:16

que escuchar. El patrón observador no

5:18

tiene este intermediario. Redux

5:21

implementa el patrón mediador. En

5:23

ingeniería de software, el patrón

5:25

adaptador permite que un objeto que no

5:27

está diseñado para funcionar con una

5:28

interfaz sea modificado para que este sí

5:31

pueda funcionar con esta. En Python

5:34

podemos definir un patrón adaptador

5:36

creando dos clases. Primero, creamos una

5:39

clase Android y una clase iPhone.

5:41

Android se recarga con USB y iPhone se

5:44

recarga con Lightning. Puedo crear una

5:46

clase cargador que reciba el teléfono

5:48

que tiene que cargar, pero este solo

5:50

funcionaría con USB. Por lo que para que

5:52

el iPhone se pueda cargar, puedo crear

5:54

una clase iPhone adapter que reciba el

5:57

iPhone y que cuando se llame a su método

5:59

para cargar el teléfono con USB, que

6:01

este lo cargue con Lightning. De esta

6:04

manera, este iPhone adaptado podría

6:06

utilizarse con el cargador de Android.

6:08

El patrón MBC o también conocido como

6:11

Model View Controller se utiliza

6:13

comúnmente para desarrollar interfaces

6:15

de usuario dividiendo la lógica en tres

6:18

elementos interconectados. El modelo, el

6:21

cual contiene la lógica de tu

6:22

aplicación, se encargará de llamar a los

6:24

distintos datos y contiene las reglas de

6:27

negocio. La vista es la representación

6:29

visual de los datos que se recolectan.

6:31

Esto es lo que verá el usuario y el

6:33

controlador. Se encarga de recibir los

6:36

datos, transformarlos en algo útil para

6:38

el modelo, recibe los datos del modelo y

6:41

luego construye la respuesta para el

6:43

usuario. Un ejemplo de MBC se puede ver

6:46

fácilmente en Node js con Express, donde

6:48

creamos un endpo encargado de recibir

6:51

las peticiones de nuestro usuario. Con

6:53

esa petición vamos a buscar los datos

6:55

que este necesita. Luego los devolvemos

6:57

al usuario estos datos y por supuesto

6:59

manejamos las excepciones en el caso que

7:02

estas existan. Si existe un HTML lo

7:04

renderizamos con los datos que

7:06

recolectamos, pero en este caso

7:08

devolvemos los datos como si fuese una

7:10

API Rest, por lo que nuestra vista entre

7:12

comillas en este caso es un Jason. El

7:14

patrón Flux fue desarrollado por

さらにアンロック

無料でサインアップしてプレミアム機能にアクセス

インタラクティブビューア

字幕を同期させ、オーバーレイを調整し、完全な再生コントロールでビデオを視聴できます。

無料でサインアップしてアンロック

AI要約

動画コンテンツ、キーポイント、および重要なポイントのAI生成された要約を即座に取得します。

無料でサインアップしてアンロック

翻訳

ワンクリックでトランスクリプトを100以上の言語に翻訳します。任意の形式でダウンロードできます。

無料でサインアップしてアンロック

マインドマップ

トランスクリプトをインタラクティブなマインドマップとして視覚化します。構造を一目で理解できます。

無料でサインアップしてアンロック

トランスクリプトとチャット

動画コンテンツについて質問します。AIを利用してトランスクリプトから直接回答を得られます。

無料でサインアップしてアンロック

トランスクリプトをもっと活用する

無料でサインアップして、インタラクティブビューア、AI要約、翻訳、マインドマップなどをアンロックしてください。クレジットカードは不要です。