Swift by Sundell

Re note some refactoring techniques and concepts

Bad Smells in code:
Duplicate, long method, large class, long parameter list, divergent change (?), shotgun surgery
Feature envy, Data clumps, lazy class, middle man, message chains, ...
Techniques:
Composing methods,
Moving features between objects
Organizing data
Simplifying conditional expressions
Making method calls simpler
Dealing with generalization

Some interesting material from Sundell for some ideas, technique on what is bad code and how to refactor it.

Lightweight API design in Swift
https://www.swiftbysundell.com/articles/lightweight-api-design-in-swift/

    Often when we design how our various types and functions will interact with each other, we have to find some form of balance between power and ease of use. Make things too simple, and they might not be flexible enough to enable our features to continuously evolve — but on the other hand, too much complexity often leads to frustration, misunderstandings, and ultimately bugs.


Map, FlatMap and CompactMap => Like PHP or other callback like function for ie. convert, mapping or cast data.


Model controllers in Swift
This provide some good information to refactor current App crufts that was very bad implemented on User permissions, shared data, logic.

Massive View Controller :)
https://auth0.com/blog/compare-mvvm-and-viper-architectures/

https://github.com/auth0-blog/mvvm_viper
Oh, I'm not familiar with  using so many protocols.


Aha Dependency Inversion, it's too much!
Note: As you may have noticed, each layer in VIPER is implementing a protocol. This way, classes depend on abstractions instead of concretions, conforming to the Dependency Inversion principle.
https://code.tutsplus.com/tutorials/solid-part-4-the-dependency-inversion-principle--net-36872

Typealias for shortern method signatures
https://www.swiftbysundell.com/tips/using-typealiases-to-reduce-the-length-of-method-signatures/

Model Controller
https://www.swiftbysundell.com/articles/model-controllers-in-swift/

Observer
https://www.swiftbysundell.com/articles/observers-in-swift-part-1/

Use protocol

Protocol alternatives
https://www.swiftbysundell.com/articles/alternatives-to-protocols-in-swift/#single-requirements-using-closures

https://www.swiftbysundell.com/articles/alternatives-to-protocols-in-swift/#single-requirements-using-closures
Value and reference types
https://www.swiftbysundell.com/basics/value-and-reference-types/

https://www.swiftbysundell.com/articles/specializing-protocols-in-swift/

Enum -> Detail many use cases
https://www.swiftbysundell.com/basics/enums/


https://www.swiftbysundell.com/tips/organizing-code-using-extensions/
public extension
internal extension

https://www.swiftbysundell.com/tips/avoiding-massive-view-controllers/
Sundell suggest when you have 3 methods or properties that have the same prefix,  break them out into their own type.
https://www.swiftbysundell.com/tips/the-rule-of-threes/


https://www.swiftbysundell.com/articles/composing-types-in-swift/
class User {
    var name: String
    var age: Int
}

class Friend: User {
    var friendshipDate: Date
}

+ To use inheritance, we are forced to use classes - which are reference types. For models, that means that we can easily introduce shared mutable state by accident. If one part of our code base mutates a model, it will automatically be reflected everywhere, which can lead to bugs if such changes are not observed & handled correctly.
+ Since a Friend is also a User, a Friend can be passed to functions that take a User instance. This might seem harmless, but it increases the risk of our code being used in "the wrong way", for example if a Friend instance is passed to a function like saveDataForCurrentUser
...
Change to this:

struct User {
    var name: String
    var age: Int
}

struct Friend {
    let user: User
    var friendshipDate: Date
}

Some stuff about testing
https://www.swiftbysundell.com/articles/refactoring-swift-code-for-testability/

Yeah, It seem I have much work to do on structuring current code base
https://www.swiftbysundell.com/articles/structuring-swift-code/

https://www.swiftbysundell.com/articles/trimming-long-argument-lists-in-swift/

Not used, but may be cool stuff. M. Fowler have some post about Domain Specific Language (DSL).
https://www.swiftbysundell.com/articles/building-dsls-in-swift/

Avoid nested using inline function
https://www.swiftbysundell.com/tips/refactoring-swiftui-views-using-functions/

May be this one faster a bit
https://www.swiftbysundell.com/tips/computed-properties-vs-methods/

Reactive code
https://www.swiftbysundell.com/tips/using-property-observers/

https://www.swiftbysundell.com/tips/dependency-injection-using-functions/
Sometime I want to share data between class, I see there are Protocol, Notification (send/receive)...
May be try to use Closure.

https://www.swiftbysundell.com/tips/faster-and-more-stable-ui-tests/
It have some timeout related code. May be useful when optimize, debug app loading slow.

https://www.swiftbysundell.com/tips/converting-swift-errors-to-nserror/
This can be used for Error handling.

https://www.swiftbysundell.com/tips/defining-static-urls-using-string-literals/