https://kotlinlang.org logo
#android-architecture
Title
# android-architecture
i

ivano

01/07/2020, 1:02 PM
Copy code
class Car() :MovingObjects{
    val carParts = CarParts()
    val carFunctionalities =CarFunctionalities()
    
}

class CarParts():MovingObjects(){
        fun engine(): Engine
        fun wheel(): Wheel
        fun doors():Doors

    } 
}
class CarFunctionalities():MovingObjects{
    fun switchOn()
    fun maxVelocity(): Int
}
👍 1
a

Anastasia Finogenova

01/07/2020, 6:37 PM
So looking at this I have a question. Won't this approach lead to extensive object creation?
You are basically deepening nesting in object structure
d

Daniel

01/07/2020, 7:05 PM
Object allocation is usally not an issue (if there are not some very hard performance constrains). Making complex logic easier to understand by separating it to small chunks outweights the performance cost by far
i

ivano

01/07/2020, 8:05 PM
guys you speak about the first chapter of the head design book about ducks?
favorite composition over inheritance?
a

Anastasia Finogenova

01/07/2020, 8:06 PM
I speak about this code snippet which is basically single params vs nested object
i

ivano

01/07/2020, 8:19 PM
yeah I get, but I have not idea what I wrote, I am replying to the suggestion from Vlastimil, because I want to mantain classes with growing methods under the 300 lines of code
I don't know if is a good solution or not, I want my classes short and the dependencies decoupled
with SOLID
ah I got it!!!! is indeed Anastasia about nesting that Vlastimil was referring
Copy code
class APP(val part1,val part2){   part1 =Part1(subPart1,subPart2) }
a

Anastasia Finogenova

01/07/2020, 8:33 PM
I would say reasonable class size is 500-600 lines max imo and then you can split logic
But there is no law saying it should be _ max lines
A viewmodel or a use case will most likely be larger than Repository because of the containing logic
Some people chasing this small classes start creating Helper for everything to remove logic but then if you are reading this code you have 5 classes open and trying to tie this all together
So I feel it makes it worse for maintenance not better
i

ivano

01/07/2020, 8:43 PM
Good point, when we speak about Architecture is almost everything relative. Actually can happens that Repository can have a lot of RXjava operators and the viewModel are much more smaller having a LIveData wrap and calling the presenter layer (in clean architecture)
a

Anastasia Finogenova

01/07/2020, 8:44 PM
I personally have all operators in interactor 🤷
i

ivano

01/07/2020, 8:44 PM
then the_re is the testability,_ then the habits, then the code architectural conventions( can be easier implement features in smaller clases
a

Anastasia Finogenova

01/07/2020, 8:44 PM
It is a sort of MVVMI way
i

ivano

01/07/2020, 8:44 PM
eheh there is not good and bad, as soon as you do not build technical debt, and you can have good testing coverage, and be fast in creating new features
I encourage you Anastasia to write a blog about MVVMI
could be the new hot thing
a

Anastasia Finogenova

01/07/2020, 8:45 PM
It is easier to deal with smaller classes but realistically in a bigger project you just end up duplicating code if there is so many classes
Already did
i

ivano

01/07/2020, 8:45 PM
sounds pretty cool actually, even if is the small blanket metaphor
i

ivano

01/07/2020, 8:46 PM
if you put the operators(flatmap, and map mainly) from one side then you have to leave space from other classes
you really fast😂
😆 1
thank you I go to see it tomorrow, now is time to netflix in netherlands
a

Anastasia Finogenova

01/07/2020, 8:47 PM
Happy coding ...emm.. Netflix 😆
i

ivano

01/07/2020, 8:47 PM
println("thanks")
u

ursus

01/10/2020, 12:15 PM
My answer was in general, Repository, ViewModels, LiveData, Rx etc that is all fashion which will change, but the way which to scale systems which will never change, is to break them apart into subsystems of managable size, if system becomes too big
and if a given subsystem becomes too big, you break him up to subsubsystems etc
2 Views