Arquitectura de Software

1

Arquitectura en Android

2

Patrón de diseño vs. Arquitectura de Diseño

3

¿Qué es la Arquitectura de Diseño?

4

SOLID: Single Responsability y Open/Closed Principles

5

SOLID: Liskov substitution, Interface segregation y Dependency Inversion principle

6

Evolución de la Arquitectura en Android

Arquitectura Model View Controller (MVC)

7

¿Qué es la aquitectura Model View Controller (MVC)?

8

MVC en un Proyecto Android: Analizando el código en capas

9

MVC en un Proyecto Android: Llevando el código a sus responsabilidades

Arquitectura Model View Presenter (MVP)

10

¿Qué es la aquitectura Model View Presenter (MVP)?

11

¿Qué es Clean Architecture?

12

Composición en Clases

13

Model View Presenter explicado

14

Capa Model

15

MVP en un Proyecto Android: Presenters y Views

16

MVP en un Proyecto Android: Model

17

Ubicando el código en MVP

Arquitectura Model View ViewModel (MVVM)

18

¿Qué es la arquitectura Model View ViewModel (MVVM)?

19

¿Cómo funciona MVVM Data Binding?

20

MVVM Data Binding estructurando nuestra aplicación y migrando a AndriodX

21

MVVM DataBinding creando un ViewModel

22

Patron Observer en MVVM

23

MVVM Data Binding: integrando ViewModel a View

24

MVVM Data Binding: RecyclerView Adapter

25

MVVM Data Binding: RecyclerView CardView

Android JetPack Arquitectura

26

¿Qué es Android JetPack Arquitectura?

27

¿Cómo funciona la arquitectura de componentes?

28

Arquitectura Componentes Lifecycle ViewModel

29

Arquitectura Componentes Lifecycle Observe

Fin del curso

30

Conclusiones

Curso de Arquitectura de Android

Curso de Arquitectura de Android

Anahí Salgado Díaz de la Vega

Anahí Salgado Díaz de la Vega

SOLID: Liskov substitution, Interface segregation y Dependency Inversion principle

5/30
Recursos
Transcripción

Vamos a seguir revisando los siguientes elementos de SOLID Principles

  • L Liskov Substitution: Deberíamos poder usar una clase hija para sustituir a una clase padre sin obtener errores.
  • I Interface segregation: Si una interfaz crece demasiado pierde su objetivo y viola el primer principio.
  • D Dependency Inversion: Depende de una abstracción, no de algo concreto.

Aportes 13

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

  • Liskov Substitution: Por ejemplo, cuando creamos una array, en Java sería List<Integer> nums = new ArrayList<>();. ArrayList implementa List (una interfaz o padre), por lo tanto al llamar los metodos de list estaremos llamando a los metodos implementados en ArrayList.

  • Interface segregation: Por ejemplo, una interfaz ‘Television’ no debería tener un método llamado ‘transmitirEn(Laptop)’.

  • Dependency Inversion: Por ejemplo, en vez enviar por parámetro un objeto específico (ej: new Corporacion(Ingeniero ing) ), debemos enviar un objeto más abstracto para que nuestra funcionalidad no este conectada a un tipo específico ya que esto puede causar problemas a la hora de arreglar bugs o añadir más features.

FATAL explicado la Interface Segregation… Mejor decir que si tienes una clase abstracta Ave y quieres añadir e instanciar una clase pingüíno, otra golondrina y otra gallina… En la clase abstracta Ave no deberían estar métodos como volar() o nadar() puesto que hay aves que no lo hacen… Por tanto, tendríamos una clase Ave y, por ejemplo, 3 clases abstractas más, con sus métodos específicos AveVoladora, AveNadadora, AveTerrestre. Y entonces extender o implementar Ave con cada una de las que se necesiten… Porque como nos toque implementar un método volar() a una gallina o nadar() a una golondrina…

Liskov substitution: Es cuando tienes una clase padre y una hijo, pero puedes instanciar la clase hijo, pero con tipo de la clase padre, no entiendo la utilidad de ello, espero en la practica entenderlo.

SOLID
Single Responsbility -> Una clase una responsabilidad.
Open/Closed Principle -> Organizar el código modularmente(Uso de interfaces).
Liskov substitution ->Definir una clase hija en una clase padre sin errores.
Interface segregation -> No añadir métodos ajenos a la función principal de la interfaz.
Dependency Inversion -> Depender de abstracciones, entra el uso de inyección de dependencias(Lo que explica Anahi)

Dependency inversion es distinto a Dependency Injection (lo que Anahi esta explicando es Dependency Injection no esta explicando Dependency inversion)

Injection vs Inversion
Dependency Injection is an Inversion of Control technique for supplying objects (‘dependencies’) to a class by way of the Dependency Injection Design Pattern. Typically passing dependencies via one of the following:

A constructor
A public property or field
A public setter
The Dependency Inversion Principle (DIP) is a software design guideline which boils down to two recommendations about de-coupling a class from its concrete dependencies:

‘High-level modules should not depend on low-level modules. Both should depend on abstractions.’
‘Abstractions should not depend upon details. Details should depend upon abstractions.’

me gusta mucho como explicas aqui dejo un contenido excelente que vi para Laravel (yo soy usuario) https://www.laraveltip.com/guia-definitiva-de-principios-solid-explicados-con-laravel/

S → Single Responsability → Una clase debe tener solo una responsabilidad.

  • Evita la cascada en el código.

O → Open/Closed Principle → Busca organizar el código modularmente.

  • Busca tener composición en la clase, esto quiere decir que la clase esta compuesta por elementos que se encuentran en otras clases, esto va a hacer el código más sencillo de entender.
  • Se recomienda más utilizar la composición que la herencia.
  • Se busca que la clase sea lo más abstracto posible.

L → Liskov substitution → Se debe poder sustituir una clase hija por una clase padre sin tener errores.

I → Interface segregation → Si una interfaz comienza a crecer demasiado se rompe el primer principio de SOLID.

  • Busca que se dividan las funcionalidades que no pertenecen propiamente a la función de la clase o del método.

D → Dependency inversión → Depende de una abstracción, no de algo concreto.

  • Se recomienda utilizar interfaces para poder dar comportamientos a diferentes clases.
  • Se recomienda pasar parámetros abstractos.

Básicamente, lo mas importante y útil son las interfaces.

es super interesante, me gusto mucho a la verdad que si es nuevo todoesto para mi ya que aprendi a codificar casi por instinto jajaja pero no hay cosa mas bonita que aprender como es y hacer las cosas a como son… te dan una mejor calidad como desarrollador y calidad en tus trabajos.

Aqui les dejo el link del curso de POO
https://platzi.com/clases/oop/

Los principios SOLID no son reglas son como guias para hacer buen codigo es dificil implementarlo correctamente

interesante, en especial la interface segregation nos hace replantear nustra interfaz para que sea mas util

MVP Model-View-Presenter