Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ViewModelType protocol and associatedtype limitations #38

Open
IvanKalaica opened this issue Jan 11, 2018 · 4 comments
Open

ViewModelType protocol and associatedtype limitations #38

IvanKalaica opened this issue Jan 11, 2018 · 4 comments

Comments

@IvanKalaica
Copy link

Should't PostsViewModel be an protocol and not class? I think keeping protocol oriented view models is better than enforcing generic structure with associatedtype. Input/output transform can always be enforced per viewModel protocol. Thoughts?

@sergdort
Copy link
Owner

sergdort commented Feb 4, 2018

Hi, @IvanKalaica, thanks for the question :)

What benefits do you think we would get from using protocol? The only thing that comes to mind is snapshot and UITests.

Input/output transform can always be enforced per viewModel protocol.

Curious to see an example :)

@IvanKalaica
Copy link
Author

I think interface based programming is always a good habit. :)

struct ExampleViewModelInput {
    
}

struct ExampleViewModelOutput {
    let speedInKmh: Observable<Int>
}

protocol ExampleViewModel {
    func transform(input: ExampleViewModelInput) -> ExampleViewModelOutput
}

final class DefaultExampleViewModel: ExampleViewModel {
    private let exampleService: ExampleService
    
    init(exampleService: VehicleService) {
        self.exampleService = exampleService
    }
}

extension DefaultExampleViewModel {
    func transform(input: ExampleViewModelInput) -> ExampleViewModelOutput {    
        return ExampleViewModelOutput(
            speedInKmh: self.exampleService.map { $0.speedInKmh }.distinctUntilChanged()
        )
    }
}

@ttkien
Copy link

ttkien commented Feb 25, 2018

@IvanKalaica Could you explain more why the below code is good habit?

@hr147
Copy link

hr147 commented Jan 22, 2019

@sergdort as per Dependency Inversion Principle (DIP) when 2 classes or modules are communicating with each other than both should link to abstraction rather than knowing about concrete module/class, which makes the system loosely coupled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants