Click here to Skip to main content
15,887,746 members
Please Sign up or sign in to vote.
1.00/5 (3 votes)
See more:
I'm an Informatics Engineer undergraduate and an enthusiast junior Java Developer.
I'm currently building a demo project to keep practicing after finishing
my first java class at my local university.
It's a Windows Desktop Application (and maybe platform independed in the future)
serving as clientele manager for a mechanic's store.
It will be able to locally (no DB implementation)
store clients, which will have their vehicles,
add vehicle services (date/info of actual service) etc.
It is currently under developement and running as intended.
So far i have completed the data classes and i'm half way to the gui classes.

I wanted to ask if there is any point shrinking the data and\or gui classes to 1
and\or even make the whole program a unified class?
Would the performance change (considering the classes instances being called),
or any advantage at all trying something like that
or even considered as a good practice?
I could use some inner classes approach,
but does it really matter for a small application
which will have, at it's best let's say,
a couple thousand (if lucky) clients.

Thank you for your time

Best regards,

What I have tried:

I've tried
I've tried
I've tried
I've tried
I've tried
I've tried
Posted
Updated 3-Aug-22 13:16pm

Quote:
I wanted to ask if there is any point shrinking the data and\or gui classes to 1
and\or even make the whole program a unified class?
That's what everyone wants to do when they are just getting started. Here is the answer they all (including a 2-year future you) learn: just don't. Writing the entire script in a single file is not maintainable, not scalable, and in Java, that's a pain (because of how the classes in Java can be defined). Just create components and focus on each one of them separately.

Remember, that SOLID principles were defined for a reason: SOLID - Wikipedia[^].
SOLID: The First 5 Principles of Object Oriented Design | DigitalOcean[^]

Quote:
Would the performance change (considering the classes instances being called),
or any advantage at all trying something like that
or even considered good practice?
Yes, but not as much as you would expect. If your application starts in 5 seconds, it might be trimmed down to 3 seconds or 4 seconds. But the development will change from 3 hours (per feature patch or update) to 5 or even 8 hours (depending on the features, etc.). What's worse if, with a single file, you will end up implementing some of the anti-patterns in your code, which will make the development painful.

Quote:
I could use some inner classes approach,
but does it really matter for a small application
which will have, at it's best let's say,
a couple thousand (if lucky) clients.
An application written that "poorly" or "naively" would be lucky to get a couple of hundred clients, a thousand is like a dream, and then if people "do" love the concept, it will not scale.

Do the development the way the framework suggests and recommends.

Oh, but if you do end up writing it in a single file and it scales, please write an article on CodeProject, I would love to read it. :-)
 
Share this answer
 
Quote:
I wanted to ask if there is any point shrinking the data and\or gui classes to 1
and\or even make the whole program a unified class?

There is no point to doing that at all. Classes should be responsible for one thing and one thing only. "Unifying" breaks that rule.

Quote:
Would the performance change (considering the classes instances being called),

Most likely not.

Quote:
any advantage at all trying something like that

Only if you're into making your code as unsupportable and unmanageable as possible.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900