```class Car() :MovingObjects{ val carParts = ...

# android-architecture

[ivano]

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
}

[Anastasia Finogenova]

So looking at this I have a question. Won't this approach lead to extensive object creation?

[Anastasia Finogenova]

You are basically deepening nesting in object structure

[Daniel]

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

[ivano]

guys you speak about the first chapter of the head design book about ducks?

[ivano]

favorite composition over inheritance?

[Anastasia Finogenova]

I speak about this code snippet which is basically single params vs nested object

[ivano]

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

[ivano]

I don't know if is a good solution or not, I want my classes short and the dependencies decoupled

[ivano]

with SOLID

[ivano]

ah I got it!!!! is indeed Anastasia about nesting that Vlastimil was referring

[ivano]

class APP(val part1,val part2){   part1 =Part1(subPart1,subPart2) }

[Anastasia Finogenova]

I would say reasonable class size is 500-600 lines max imo and then you can split logic

[Anastasia Finogenova]

But there is no law saying it should be _ max lines

[Anastasia Finogenova]

A viewmodel or a use case will most likely be larger than Repository because of the containing logic

[Anastasia Finogenova]

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

[Anastasia Finogenova]

So I feel it makes it worse for maintenance not better

[ivano]

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)

[Anastasia Finogenova]

I personally have all operators in interactor 🤷

[ivano]

then the_re is the testability,_ then the habits, then the code architectural conventions( can be easier implement features in smaller clases

[Anastasia Finogenova]

It is a sort of MVVMI way

[ivano]

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

[ivano]

I encourage you Anastasia to write a blog about MVVMI

[ivano]

could be the new hot thing

[Anastasia Finogenova]

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

[Anastasia Finogenova]

Already did

[ivano]

sounds pretty cool actually, even if is the small blanket metaphor

[Anastasia Finogenova]

https://proandroiddev.com/our-way-to-mvvmi-and-mistakes-we-made-when-implementing-mvvm-5f5448b5ad50

[ivano]

if you put the operators(flatmap, and map mainly) from one side then you have to leave space from other classes

[ivano]

you really fast😂

[ivano]

thank you I go to see it tomorrow, now is time to netflix in netherlands

[Anastasia Finogenova]

Happy coding ...emm.. Netflix 😆

[ivano]

println("thanks")

[ursus]

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

[ursus]

and if a given subsystem becomes too big, you break him up to subsubsystems etc