Swift What is the model file use for and how does it work? -


i saw developer using user.swift or post.swift. use , why seems every developer had it.

some code find online https://github.com/dasoga/chat-firebase/blob/master/chatrealtime/model/user.swift

import uikit  class user: nsobject { var id: string? var name: string? var email: string? var profileimageurl: string? } 

the idea of model class encapsulate data used app in own class, offering cleaner separation of model controller , view. see model-view-controller in apple's cocoa core competencies. or see model object.

but setting aside these broader design principles, let's consider user class: class encapsulates series of properties, namely identifier, name, email address, , image url. so, why use user type, rather individual properties and/or standard collections?

let's consider alternatives, illustrative of why model object user can powerful:

  • consider app maintained list of users. array of user objects far more convenient than, say, separate arrays of identifiers, names, emails, etc. example, if wanted sort list of users name? if had of these properties in different arrays, keeping track of them complicated.

  • so, let's recognized keeping these various properties powerful, decided use simple dictionary accomplish this. array of users represented array of dictionaries. solves previous problem.

    but introduces other problems. example, it's incumbent upon you, programmer, use right keys dictionary, , compiler can't offer clues expects keys dictionary should be, less rules govern type of data associated keys.

    worse, might have business rules associated user object, namely id , name might required, email address , image url optional. furthermore, might want apply business rules email address , url make sure they're valid. or might it's valid change user's name or email address, not change id. sort of logic can encapsulated within user object, if you're using simple dictionary, it's hard capture business rules effectively.

    for example, might suggest refactoring user class capture of these business rules:

    class user {     let id: string         // note use of `let`, not `var`, meaning can't change     var name: string       // note no `?`, meaning required     var email: string?     // note use of `?`, meant _is_ optional     var imageurl: nsurl?   // note use of `nsurl`, more captures/validates url string      init(id: string, name: string, email: string?, imageurl: nsurl?) {         self.id = id         self.name = name         self.email = email         self.imageurl = imageurl     } } 

    this nice simple user type that, limited code, enforces sorts of business logic (e.g. id required , immutable, name required mutable, email , imageurl optional , mutable). clearly, go further class definition, encapsulating sorts of other business requirements.

    but beauty of when use user class in code, these rules enforced @ compile time, eliminating sorts of programming problems before occur. properties strongly-typed , mutability , optionality of various properties nicely encapsulated in simple type.

bottom line, designed model types, it's easier write code safely uses , interacts these model classes.


Comments

Popular posts from this blog

jOOQ update returning clause with Oracle -

java - Warning equals/hashCode on @Data annotation lombok with inheritance -

java - BasicPathUsageException: Cannot join to attribute of basic type -