Why having only one instance of a class (not about Singleton)

[cold quarry]

I've seen some libraries, like Gson from Google. You can create objects like any other class, but I don't see any point or reason to do this with some libraries... With GSON, it's like:

Gson gson = new Gson()

Why not making a class with static fields? So, instead of

gson.someMethod()

They did like this?

Gson.someMethod()

I'm not talking specifically about Gson, it could be any example as you think, I've seen a lot of classes that only have one single instance... I saw this quote in a github repo and it was kinda fun:

Classes
You can make classes, but you can only ever make one instance of them. This shouldn't affect how most object-oriented programmers work.
(https://github.com/TodePond/DreamBerd)

[celest glade]

<@&987246841693360200> please have a look, thanks.

[celest glade]

While you are waiting for getting help, here are some tips to improve your experience:

Code is much easier to read if posted with syntax highlighting and proper formatting.

If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.

Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.

[cold quarry]

Why having only one instance of a class (not Singleton)

I think I know some answers I'll receive, like:

You can pass objects as parameters

But that's all?

(That's all answers I could think rn)

[prisma knot]

Flexibility probably

Or thread safety

It's similar to ObjectMapper in Jackson, you would usually only have 1 instance but the reason it's not is because of configurability

[cold quarry]

So do you think it's always better to write code like this? Even knowing that it might have only one instance?

Why having only one instance of a class (not about Singleton)

[meager thicket]

its better to design libraries like that

you can always make a singleton later

you can't un-make something a singleton

[supple barn]

so true

I generally reserve singletons for global configurations, resource pooling, and caching / db related operations. The downside to singletons are they just don't scale or test well, they also cause tight coupling and make it harder to follow more advance design patterns generally speaking.

[meager thicket]

the singleton you learn in school is almost never the one to use

the getInstance version

its fine for some things to be "effectively singletons" though

you don't actually want a singleton db

you just want one instance being passed around

[supple barn]

I always made my own singletons in this language

[supple barn]

why would you not want a singleton db?

[meager thicket]

you want to start and stop it and you want it pluggable for tests

so if your code just reads a singleton Db.INSTANCE you can't do that

you do generally want a single instance, but its best to pass it by argument

[supple barn]

you call it through the repo design pattern. you could still do the things you are describing with a singleton

[meager thicket]

you can start a test database with a singleton

how

singleton means something very specific - a class you only are allowed to have one instance of existing in the JVM at a time

i would believe a non-singleton in a static global field

[supple barn]

Do you run tests on applications while they are in production? I've never heard of that

[meager thicket]

(i wouldn't like it, but i could imagine the code)

[supple barn]

cause the use case you are describing implies running two instances and that would only occur if you are trying to satisfy both a test and prod use case in prod

and that's just bad

[meager thicket]

nah - just if you want to start a db before a test, tear it down after, and have a fresh db for the next test

or run tests in parallel

[supple barn]

you would use something like moq

[meager thicket]

moq?

[supple barn]

I think its called that in c#, id have to look up the java equivalent

[meager thicket]

oh mocking

we can disagree about how much mocking a codebase should have

[supple barn]

oh yeah, javas version is mockito

[meager thicket]

but you gotta test interaction with the actual db being used

[supple barn]

no way

no testing on prod

[meager thicket]

no man

i mean like actually use a postgres instance during your tests

not the prod instance

https://github.com/testcontainers/testcontainers-java

spin up a test postgres, run a test, spin up a new test postgres

[supple barn]

that depends on framework, moq (which is c#) tests on the actual db schema and everything.

[meager thicket]

or spin up one, but use template dbs (still results in new Dataseources)

that sounds insane

[supple barn]

spring boots integrations with db are pretty poor

[meager thicket]

moq can actually read the database's schema and provide mocking of stuff like sql constraints?

[supple barn]

Depends on a lot of factors. Code first in c# is huge, you can actually spin up a whole DB without ever opening whatever DB platform you are using and customize it pretty thoroughly

[meager thicket]

wait you are talking about an orm

[supple barn]

for that use case yes

[meager thicket]

so if your code manages the schema then yeah okay wtvr

if you rely only on the ORM's interface it could be like rails where testing on sqlite is enough

[supple barn]

I never had to learn ruby

thank god

[meager thicket]

but if you have logic (like we do at work) that uses postgres features like triggers, then you need to make a real postgres to test stuff

its not hard to do, but making the db a singleton isn't really a winning strategy here. Managed global object sure - rails does that even, but not a singleton.

[supple barn]

that would make sense, there are a few use cases where SQL just does it better unfortunately.

[meager thicket]

"thank god im uninformed"

[supple barn]

yes actually

same with non GC languages

[meager thicket]

learn rust

[supple barn]

THANK GOD i never had to bash my head against a wall for those

[supple barn]

I might one of these days. Microsoft picked up rust pretty heavily lately

[opal robin]

you can have different configurations for example

like should you pretty print or not, should you ignore nulls or not and so on

and nothing stops you from providing a default config if the user doesn't need anything fancy
Foo.DEFAULT.doThing();

[proven berry]

Singletons are used when there will only ever be one use for an class. Utility classes for example, other design techniques may use static methods/classes etc

Autowired annotation in springboot will utilise this feature for you. It will search for the instance and provide it to your class. You don't want to use singletons in ever changing objects such as models or something

You could have a service that interacts with your db as a singleton for example. It only serves that purpose and doesn't require several instances to complete this task

Also static fields are horrendous to unit test. Avoid avoid avoid

[cold quarry]

Got it