this post was submitted on 10 Oct 2024
48 points (85.3% liked)

Programming

17416 readers
37 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 32 points 1 month ago (3 children)

OOP is great, and can be much simpler than what you've seen.

It's Java culture that's terrible. The word "Factory" is a code smell all on its own.

Just like any tool, don't overuse it. Don't force extra layers of abstraction.

[–] [email protected] 2 points 1 month ago (1 children)

Why is the word factory a code smell?

[–] [email protected] -3 points 1 month ago* (last edited 1 month ago) (2 children)

It means you’re compensating for the lack of optional/named parameters in your language.

[–] [email protected] 3 points 1 month ago

Sounds like you’re thinking more about the builder pattern.

[–] [email protected] 2 points 1 month ago

Eh? How's that work. I'm not going to sit here and say there isn't too many factories in Java but as a concept it's extremely useful. You hand off a "factory" to something which actually creates the object. This is really useful in for example serialization. How so? You could register factories (mapped to some sort of ID) which get passed the serialized data and return some sort of created object. Now the core serialization code doesn't know nor care how exactly any particular type gets serialized. Pretty nifty huh?

Some languages have better ways to encapsulate this functionality but that's what the factory concept is

[–] [email protected] 8 points 1 month ago (3 children)

I've realized that Factories are actually kind of fine, in particular when contexualized as being the equivalent of partials from the world of functionals.

[–] [email protected] 5 points 1 month ago* (last edited 1 month ago)

IMO factory functions are totally fine -- I hesitate to even give them a special name b/c functions that can return an object are not special.

However I think good use cases for Factory classes (and long-lived stateful instances of) are scarce, often being better served using other constructs.

[–] [email protected] 1 points 1 month ago* (last edited 1 month ago)

I always call my little helper higher order functions (intended to be partially applied) factories :)

[–] [email protected] 8 points 1 month ago (1 children)

I have never seen them used well. I expect there IS some use case out there where it makes sense but I haven't seen it yet. So many times I've seen factories that can only return one type. So why did you use a factory? And a factory that returns more than one type is 50/50 to be scary.

Yeah, I went through the whole shape examples thing in school. The OOP I was taught in school was bullshit.

Make it simpler. Organizing things into classes is absolutely fine. Seven layers of abstraction is typically not fine.

[–] [email protected] 9 points 1 month ago (1 children)

Consider the following: You have a class A that has a few dependencies it needs. The dependencies B and C never change, but D will generally be different for each time the class needs to be used. You also happen to be using dependency injection in this case. You could either:

  • Inject the dependencies B and C for any call site where you need an instance of A and have a given D, or
  • Create an AFactory, which depends on B and C, having a method create with a parameter D returning A, and then inject that for all call sites where you have a given D.

This is a stripped example, but one I personally have both seen and productively used frequently at work.

In this case the AFactory could practically be renamed PartialA and be functionally the same thing.

You could also imagine a factory that returns different implementations of a given interface based on either static (B and C in the previous example) or dynamic dependencies (D in the previous example).

[–] [email protected] 1 points 1 month ago* (last edited 1 month ago) (1 children)

Sounds easy to simplify:

Use one of: constructor A(d), function a(d), or method d.a() to construct A's.

B and C never change, so I invoke YAGNI and hardcode them in this one and only place, abstracting them away entirely.

No factories, no dependency injection frameworks.

[–] [email protected] 2 points 1 month ago (1 children)

Now B and C cannot be replaced for the purposes of testing the component in isolation, though. The hardcoded dependency just increased the testing complexity by a factor of B * C.

[–] [email protected] -1 points 1 month ago* (last edited 1 month ago)

That's changing the goal posts to "not static"

[–] [email protected] 27 points 1 month ago

It's enterprise design that sucks, often it's written in Java - Hello World