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

No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

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

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?

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 鈥楾elevision鈥 no deber铆a tener un m茅todo llamado 鈥榯ransmitirEn(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鈥

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 (鈥榙ependencies鈥) 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:

鈥楬igh-level modules should not depend on low-level modules. Both should depend on abstractions.鈥
鈥楢bstractions should not depend upon details. Details should depend upon abstractions.鈥

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)

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.

MVP Model-View-Presenter

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