Jump to content
Oberon82

One large unit vs multiple small units

Recommended Posts

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?

Share this post


Link to post

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.

Share this post


Link to post

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

  • Like 2

Share this post


Link to post

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.

  • Like 1

Share this post


Link to post
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 by Rollo62

Share this post


Link to post
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.

Share this post


Link to post
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.

 

 

 

Share this post


Link to post
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.

Share this post


Link to post

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

  • Like 1

Share this post


Link to post
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.

 

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×