Life After Business Objects - Confessions of an OOP Veteran • Vagif Abilov • GOTO 2020

[@jagansinghchoudhary]

Slide at 10:30 ??

[@Zhuinden]

8:20 "I don't think I need to explain that this is bad" -- and then this is what the entire LiveData/MutableLiveData thing in Android Jetpack is built upon (which is also the basis for StateFlow/MutableStateFlow in the KotlinX Coroutines library github.com/Kotlin/kotlinx.coroutines/blob/583ec6e862fb70c7fc0232af948a028bab3b20de/kotlinx-coroutines-core/common/src/flow/StateFlow.kt#L123 ), I'm somewhat disappointed it was handwaved away

[@Zhuinden]

To be honest, I'd also love to see how an immutable point "as mutable objects are a mistake" would scale in terms of memory use and GC performance problems in a graphics engine. I'm not sold that mutability is inherently bad (although it *should* be controlled).

[@lutandongqakaza6795]

@@Zhuinden I do not want to put words in the authors mouth but in general when you here people say that inheritence is bad they mean to say "Composition over Inheritance". And you may or may not know that functional styles of programming prefer composition because it opens a massive pandoras box of possibilities (and simplifications)

[@Zhuinden]

@@lutandongqakaza6795 I figured the real issue is that you can `if(is MutableBlah)` over it, and easily turn an "immutable" class into a "mutable" one, if the "mutable" one is not also wrapped by an immutable one, in which case you may as well ditch the inheritance and have two separate classes that still implement a common interface.