One large unit vs multiple small units

[Oberon82 1]

Which is better, small units or one large unit? I mean put all in one large unit or split into multiple units. How does it impacts on code completion?

[Stano 143]

I strictly follow business logic. So that I don't have a problem learning about them and finding something later. I don't have big units. So up to 3,000 lines.

I don't know the answer to the question.

[FPiette 383]

Small units if better than one large. It helps separate things and it helps to program in a more object oriented way.

[Lars Fosdal 1792]

It depends. 
If classes naturally belong together, and are not suitable for general usage - i.e. they are specialized for a purpose - I don't see a problem with "lumping them together".

If they are merely building blocks, and will be reused in a multitude of other classes, it is better to try to keep them small and simple. 

 

The most challenging task is to avoid circular references and polluting "clean classes" with methods that use types from other classes. 

When you need such bridges - you need to take extra care in how you design them.

Use dependency injection, use adapter/proxy classes, divide and conquer.

[Rollo62 536]

1 hour ago, Lars Fosdal said:

It depends.

All above said is right.

I also want to mention that it may depend from Platform as well.

While large units under Windws never made a big issue to me, it turned out that under mobile they may show various strange exceptions and crashes, under iOS or Android.

I assume that the reason for this is because linker issues, since a simple re-order units might help in many cases.

 

That is the main reason I try to highly decouple my units nowadays, even if the classes might be related.

This is not only a better, modular design IMHO, easier to maintain and test, but also helps to prevent mysterious exception under Mobile

 

Edited September 29, 2022 by Rollo62

[Attila Kovacs 629]

The size does not matter. (tm)

 

(dependencies do)

[FPiette 383]

3 hours ago, Rollo62 said:

While large units under Windows never made a big issue to me, it turned out that under mobile they may show various strange exceptions and crashes, under iOS or Android.

That is not a question of unit size nor number. Something else is wrong in your iOS or Android application.

[Rollo62 536]

2 hours ago, FPiette said:

That is not a question of unit size nor number. Something else is wrong in your iOS or Android application.

Like said, same app, since I heavily modularized I have not seen such issues any more.

I don't recall, but in the past iOS or Android had some kind of 64K limit for relative jumps, I think.

It was always my explanation that too large binary blocks might fail, while the linker could handle many smaller chunks as needed

( probably that view is too naive with modern linkers, but anyway this helped a lot).

 

These were cases from the early beginning of FMX mobile, so maybe all that has changed a lot, over the last years anyway.

Nevertheless, my principle to try to use only small units had a lot of other advantages too and I'm quite happy with it.

 

 

 

[FPiette 383]

17 hours ago, Rollo62 said:

19 hours ago, FPiette said:

That is not a question of unit size nor number. Something else is wrong in your iOS or Android application.

Like said, same app, since I heavily modularized I have not seen such issues any more. 

One frequent bug which becomes visible when changing OS is using a freed pointer or freed object or initialized local variable : the address point to somewhere not hurting in one OS but point to something useful in the other OS.

 

17 hours ago, Rollo62 said:

in the past iOS or Android had some kind of 64K limit for relative jumps, I think.

I don't think the existed. But rearranging the code by moving some part of one unit in a new unit will cause the code to be linked in different places and the effect of the bug I mention above may be gone. Only the effect will magically disappear but not the bug, it will reappear later when code is again changed and the dangling pointer point again to something significant.

 

17 hours ago, Rollo62 said:

my principle to try to use only small units had a lot of other advantages too and I'm quite happy with it.

As said in my first answer to the OP, that is how it should be done. But do not fall into the opposite trap and make lots of tiny units.

[Lars Fosdal 1792]

17 hours ago, Rollo62 said:

I don't recall, but in the past iOS or Android had some kind of 64K limit for relative jumps, I think.

https://stackoverflow.com/questions/29737035/can-someone-explain-the-branch-opcode-in-arm indicates a +/- 32MB relative jump range?

[Fr0sT.Brutal 900]

Small units are good for modularization but they complicate code navigation and understanding and enlarge "uses" section. As anywhere - it's important to keep the balance

[Rollo62 536]

4 hours ago, Fr0sT.Brutal said:

Small units are good for modularization but they complicate code navigation and understanding and enlarge "uses" section. As anywhere - it's important to keep the balance

Right, I also try to do keep the balance right.

Usually I see modular units that define one functionality as "implementation details" of an interface, which may or maybe not  involve one or more Units to do its implementation.

When accessing this "functionality" through the interface, yes there may be a few units involved behind the scene,

but not from the caller perspective ( he only needs one clean, simplified interface unit ).

 

Higher complexity may arise from the implementation side, but thats worth it in my opinion, to keep such details separate whereever it make sense.

For me it is most important to have a clean consumer side, which can be used many times in many places, while the implementation side is defined and tested only once mostly.

You may call it imbalance, but I think the consumer side has higher weight than producer side.