ios iphone swift design-patterns solid-principles

Desarrollando una aplicación Swift para iOS “The Right Way”



iphone design-patterns (2)

Dado que la primera línea de la pregunta dice que desea "desarrollar una aplicación real por su cuenta", por lo tanto, solo quiero apuntarle en la dirección correcta.

El hecho es que no hay una "mejor" manera de estructurar su código. Hay muchas formas en las que puede escribir código que realice la misma tarea. Y a menos que esté trabajando en un equipo y construyendo una aplicación muy complicada, realmente no importa qué enfoque siga.

Como dijo que aprendió rápido, sugeriría que ahora se centre en el aprendizaje de funciones avanzadas de cierres y protocolos rápidos. Una vez que esté familiarizado con estos, deberá familiarizarse con el SDK de iOS, que tiene muchos marcos integrados que debería usar en su aplicación.

Por último, simplemente comienza con tu aplicación lo antes posible. Es posible que no pueda escribir código limpio y bien estructurado en su primera aplicación, pero es algo que aprenderá con el tiempo al cometer errores y corregirlos más tarde. Solo para animarte, me gustaría decirte que hacer una aplicación simple no es muy difícil, aprendí el objetivo c e hice mi primer juego en 20 días y tú también puedes hacerlo. Si necesita tutoriales / recursos, solo deje un comentario, actualizaré la respuesta.

Centrarse en la construcción de la aplicación. Mejóralo más tarde cuando lo hayas construido.

Recientemente, aprendí Swift y lo básico para desarrollar una aplicación iOS. Ahora, quiero desarrollar una aplicación real por mi cuenta, pero me preocupa mucho escribir un buen código, así que busqué "mejores prácticas", "patrones de diseño" y "la forma correcta" de lograrlo.

En mi búsqueda, he encontrado este gran tutorial sobre todos los patrones de diseño que se utilizan normalmente en una aplicación Swift para iOS y ejemplos de dónde se usan.

Sin embargo, considero que este tutorial es excelente y me ayudó mucho, tengo la sensación de que es solo un comienzo, porque veo muchas violaciones de los principios de SOLID. Por ejemplo:

Ver el Patrón de Fachada implementado en LibraryAPI:

class LibraryAPI: NSObject { private let persistencyManager: PersistencyManager private let httpClient: HTTPClient private let isOnline: Bool class var sharedInstance: LibraryAPI { struct Singleton { static let instance = LibraryAPI() } return Singleton.instance } override init() { persistencyManager = PersistencyManager() httpClient = HTTPClient() isOnline = false super.init() NSNotificationCenter.defaultCenter().addObserver(self, selector:"downloadImage:", name: "BLDownloadImageNotification", object: nil) } deinit { NSNotificationCenter.defaultCenter().removeObserver(self) } func getAlbums() -> [Album] { // ... Not relevant } func addAlbum(album: Album, index: Int) { // ... Not relevant } func deleteAlbum(index: Int) { // ... Not relevant } func downloadImage(notification: NSNotification) { // ... Not relevant } }

Lo primero que me viene a la mente al ver esto es: ¿esto no viola el principio de inversión de dependencia? ¿No deberían httpClient y persistencyManager como protocolos y luego las clases HttpClient y PersistencyManager implementan ese protocolo?

Si ese es el caso, en algún momento tendré que definir qué clases, qué implementa esos protocolos, voy a usar. ¿Dónde debo decirle a la aplicación?

Otra pregunta que tengo es: este ejemplo solo implementa un Modelo ( Album ), pero ¿qué pasaría si implementara muchos otros? ( Album , Author , Genre ...). ¿No sería LibraryAPI tan grande que violara el principio de responsabilidad única?

Y por último, pero no menos importante ... El mismo problema con el DIP existe en PersistencyManager . ¿No debería implementar el patrón DAO, por lo que `PersistencyManager no depende de las otras clases?

Gracias de antemano, y espero que me explique lo suficientemente bien!


Algunas sugerencias

  1. Los patrones de diseño son una guía para ayudarlo a evitar esfuerzos para resolver problemas ya resueltos, no son reglas estrictas
  2. Si bien el sitio al que se vincula (raywenderlich.com) es un buen comienzo para los tutoriales, para una visión más detallada de los patrones de diseño en swift, sugiero los patrones de diseño en Swift
  3. Si HttpClient y PersistencyManager son clases base que proporcionan la interfaz, un protocolo no es estrictamente esencial. Estoy de acuerdo en que los protocolos son una forma más general de ir aquí.
  4. Si utiliza protocolos, especificaría el administrador de persistencia y del cliente en el inicializador, ya que son esenciales.
  5. Los modelos persistentes son un rol suficientemente específico como para ser manejado por una sola clase, vea realm.io para un ejemplo de db