Timeline for Is it good or bad practice to provide separate classes for an object: one to build it, and one to use it?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 21, 2014 at 20:01 | comment | added | jme | Fair enough! When my research slows down and I have more time, I am going to read some of the references on design patterns you mentioned in your answer. I'm always wondering if the code I've written is the "correct" way to go about something, perhaps at the detriment of productivity. | |
| Jan 21, 2014 at 19:56 | vote | accept | jme | ||
| Jan 21, 2014 at 17:50 | comment | added | DXM | @jme: there's only so much protection and bullet proofing you can offer without making things more complicated then they need to be. In situations like this, I like to ask, "if I give the user a shotgun, what prevents him from blowing off his own foot." :) If someone really wants to go crazy and initialize their own FooData, maybe they know what they are doing and they need "an alternate builder" for their specific situation or maybe they are going to blow off a finger. Either way, you gave them and documented a simple, safe way to use your library. Everything else is up to them. | |
| Jan 21, 2014 at 17:29 | comment | added | jme |
So I'd have three classes: Foo, FooData, and FooBuilder. Foo has a FooData* in its implementation. FooBuilder makes a FooData and passes a pointer to the constructor of Foo. My question: FooData's constructor needs to be public so that FooBuilder can initialize it. So what prevents the users of my library from initializing their own FooData object and constructing a possibly invalid Foo, besides me not telling them that FooData exists in the documentation?
|
|
| Jan 21, 2014 at 16:04 | comment | added | DXM | @jme: ... or as I suggested, if Data is a separate class, FooBuilder could just pass it into Foo's constructor. Then you could do the whole thing without having to make them friends, right? | |
| Jan 21, 2014 at 15:07 | comment | added | jme |
Interesting, thanks. I think the builder pattern is what I'm after. I'm particularly interested in the case where Foo contains a large amount of data. Say a Foo has a private data member of type Data* which, points to a really big object. So I'll make FooBuilder, also with a private Data*. When I call FooBuilder::build(), it will make a new Foo object and swap its Data* with the Data* it contains (where are Data* are really smart pointers...). So I need a friend relationship, right, unless I want to expose the implementation detail that Foo has a Data* in a constructor.
|
|
| Jan 21, 2014 at 3:40 | history | edited | DXM | CC BY-SA 3.0 |
added 117 characters in body
|
| Jan 21, 2014 at 3:27 | history | answered | DXM | CC BY-SA 3.0 |