Skip to main content
33 events
when toggle format what by license comment
Apr 26, 2023 at 10:56 comment added joker @BenCottrell, thank you for clearing this up. However, same concern applies. You want to successfully create the object regardless whether the dependencies are ready at instantiation time. Again, this is because you want to pass down the object to lower layers to use, if any. So the constraints are (fast startup, shared object among multiple classes, dependencies might not be ready on application startup). This leaves us with the idea of separation between object construction and initialization, doesn't it?
Apr 25, 2023 at 22:27 comment added Ben Cottrell @joker I think there's been some confusion - that's not what I'm suggesting; the suggestion is a method (Not a constructor) which gathers together whatever that object's dependencies are (For example, the database connection, or reading configuration from a file), then creating the object as a final step - and returning that object with everything which it needs to be in a valid state - i.e. performing the initialisation of its dependencies and data, ensuring that is successful before creating the object instead of starting with an un-initialised object then initialising it afterward.
Apr 25, 2023 at 12:45 comment added joker Clear enough, @BenCottrell?
Apr 25, 2023 at 12:44 comment added joker The downside of having a constructor that does both: object construction and initialization: 1. slower startup, and most importantly, 2. risk of missing the database connection if not ready on the application startup (which might be a not rare case considering it's a secondary database). If the connection, on startup, fails for whatever reason, all subsequent requests to the object will fail throughout the lifetime of the application, until it gets restarted.
Apr 25, 2023 at 12:42 comment added joker @BenCottrell, Because of layering. Classes are in layers. Let's say that we have 3 layers of classes (layer#1 -- high level, .., layer#3, -- low level). The object in question gets instantiated on the high level end of classes. The high level classes are loaded into memory on application startup. Not all low level classes are loaded into memory. The high level class passes the object down to the suite low level class when needed. With that, you can now see why we cannot afford having a constructor that does both object construction and initialization.
Apr 21, 2023 at 22:21 review Close votes
Apr 26, 2023 at 3:03
Apr 21, 2023 at 21:24 comment added Ben Cottrell @joker why on earth does it matter? What problem are you trying to avoid by not having a method which both creates and initialises an object? i.e. why wouldn't it work or what problem would it cause?
Apr 21, 2023 at 21:10 vote accept joker
Apr 21, 2023 at 19:25 answer added Greg Burghardt timeline score: 2
Apr 21, 2023 at 18:51 answer added incongruentDoughnut timeline score: 1
Apr 21, 2023 at 16:48 comment added radarbob ... documenting the decoupling of init and the rest of the methods -> documentation does not fix poor design
Apr 21, 2023 at 16:35 comment added joker I hope I made it clearer to understand the problem.
Apr 21, 2023 at 16:35 comment added joker In my case, the object, in terms of construction is perfectly fine without initialization. This is strictly in terms of construction/instantiation and not initialization. Maybe think of a Thread. You can instantiate one, but it's almost not usable until you call start.
Apr 21, 2023 at 16:34 comment added joker @BenCottrell, I'd say that's Factory pattern abuse. Factory, as you said is for objects construction. Object construction is one thing and its initialization is another thing. Example use of factory pattern is when you have multiple SMS service providers and you want to separate the user for the specifics of which provider and how each one of them gets constructed.
Apr 21, 2023 at 15:31 comment added Ben Cottrell @joker Where does "Neither factories nor builders run logic like database connection instantiation or checks over database connection" come from? Such use cases are a common reason for using some kind of factory pattern. (Indeed likely among the main reasons for using a factory because they generally solve the problem described here of being able to perform separate object initialisation and construction in a single method call).
Apr 21, 2023 at 15:25 answer added Laiv timeline score: 4
Apr 21, 2023 at 14:56 answer added JonasH timeline score: 2
Apr 21, 2023 at 14:39 comment added joker Let us continue this discussion in chat.
Apr 21, 2023 at 14:35 comment added Stack Exchange Broke The Law @joker class LazyThing {Thing t; void doStuff() {if(t==null) t=new Thing(); t.doStuff();}}. In a dynamic language you could even do it without listing all the methods. (I think that's also possible in Java using Proxy)
Apr 21, 2023 at 14:33 comment added joker @user253751, would you please give me an example. I'm not really following. Thank you!
Apr 21, 2023 at 14:27 comment added Stack Exchange Broke The Law @joker a decorator decorates something. A lazy construction decorator wouldn't construct the something until you called it
Apr 21, 2023 at 14:23 comment added joker @user253751, there's no inner object to initialize. It's performing some checks against a database that's required before any further processing can be handled.
Apr 21, 2023 at 13:43 comment added joker @Laiv, yeah I gave it all the context, and to my surprise, the answer (in fact, it was more of a conversation or a discussion if I may) was pretty consistent.
Apr 21, 2023 at 13:42 comment added joker @Laiv, I'm availing init as public, but documenting the decoupling of init and the rest of the methods. If the user wants eager initialization, they can call init independently, otherwise, it's gonne be called internally if not initialized. So, the object user isn't forced or anything.
Apr 21, 2023 at 13:41 comment added joker @BenCottrell, check my comment above.
Apr 21, 2023 at 13:40 comment added joker @ErikEidt, builder are mostly associated with POJOs creation. Neither factories nor builders run logic like database connection instantiation or checks over database connection. Plus the fact that will result in making only eager initialization and taking away lazy initialization.
Apr 21, 2023 at 13:11 comment added Stack Exchange Broke The Law maybe init in the constructor, but make some kind of lazy class decorator that doesn't construct the inner object until the first method is called, if that's what you need
Apr 21, 2023 at 7:24 comment added Laiv I asked a ChatGPT I hope you have explained to it every single aspect of the context this code runs in. Otherwise, this is pure "oh AI of the lake, tell your wisdom"
Apr 21, 2023 at 7:05 comment added Laiv by making init public you are forcing everyone to call init before any other methods in order to prevent possible no initialized exceptions. That's temporal coupling and is considered a code smell. So, why don't you call it from each other method? Why consumers must know about this temporal coupling? Does init needs to be triggered periodically (to perform checks)?
Apr 20, 2023 at 17:49 comment added Ben Cottrell This sounds like it lends itself more to a factory rather than asking users of the class to create the object themselves.
Apr 20, 2023 at 17:48 comment added Erik Eidt If you provide the init capability as part of a builder or factory method, then you'll get the benefit of the type system preventing use of the methods in the uninitialized state. The idea is to use two different types, one that carries the concept of uninitialized, and one that carries the concept of ready to use.
S Apr 20, 2023 at 16:51 review First questions
Apr 21, 2023 at 2:22
S Apr 20, 2023 at 16:51 history asked joker CC BY-SA 4.0