How to structure a struct with many member functions?

polaris · · 384 次点击

这是一个分享于的资源，其中的信息可能已经有所发展或是发生改变。

Given a struct with many member functions (let's say 30+), how would you structure the code to make it easy to read/understand/test/etc.? <hr/>**评论：** Femaref: <pre>logical units in different files. Are you sure that you need all those methods or maybe you can split up the struct into more meaningful types?</pre>spaztheannoyingkitty: <pre>This is a struct that is encapsulating the logic for querying our database. That struct is put into a map[string]DBStruct since we need to have multiple DB connections that's segregated by the string (sorry for being a bit elusive on the details of that string, but I can't give out a whole lot of info on that part of the design). Ultimately I need some way of querying the database in a bunch of different ways that is going to be constrained by that string. At the moment, we're thinking about just splitting the functions across multiple files to segregate different functional areas, but I'm hoping that there is a better solution.</pre>hell_0n_wheel: <pre>Are you mashing together your functions to manage DB connections and the functions that do DB queries? There's one place you need to separate concerns: your data model shouldn't care about how you get the data. i.e. whether you use a single connection or a pool, you should be able to use the same methods for querying.</pre>spaztheannoyingkitty: <pre>The functions in question are ultimately wrappers around the DB queries. We've written these functions such that they have a request/response interface (such as: func GetThing(ThingRequest) ThingResponse ) so at least that part of the interface is clean. The struct that these functions are on takes in a DB client (which is elasticsearch so there isn't a persistent conection) as a part of its construction. So where it creates the connection to elasticsearch is handled at the map layer. That map layer is another struct that is really just a glorified map[string]OurDBClient.</pre>dlsniper: <pre>No interface bigger than a few methods is clean. The best interfaces in Go have a single method (think of io.Writer or io.Reader). Please take the advice previously received and try to break your habit from previous languages and adopt a Go way to do it. You can pass the DB connection to the dependencies which need it and they can be decoupled from each-other so that you don't have a God-struct which holes so many methods. Split your struct to have a single responsibility for the functionality it takes care of, not n different ones.</pre>hell_0n_wheel: <pre><blockquote> No interface bigger than a few methods is clean. </blockquote> This isn't helpful advice. This is just blind application of dogma. How would you suggest putting an interface in front of a DB that facilitates dozens of different queries? "Selecting a record from the DB" is a single responsibility...</pre>dlsniper: <pre><blockquote> How would you suggest putting an interface in front of a DB that facilitates dozens of different queries? </blockquote> I could argue that if database/sql.*Db would need to be abstracted, which for some reason it seems to be the case, then one could create 3 interfaces with about 7-8 different methods between them? One would be open/close, one for queryctx, execctx and queryrowctx and one for the transaction part. But if I understand correctly, the author created this megastructre to hold a God-object for every DB interaction, such as SelectUse, UpdateCart, DeleteSomething. In that case, I would decouple the user from the cart from the something functionality. And finally, this could be also done as a collection of functions in different packages, because hopefully the functions are isolated and don't share state between each-other (other than the DB connection, ofc). More over, because the user needs an interface this leads me to the obvious conclusion that it's testing time and some mocking might become involved. And what would you prefer to mock? Something that has 2-3 functions or something that has 30+? If the response is the later one, please consider revisiting your response until you say the first one. Continuing with the assumption that testing is involved, it becomes apparent that rather than using the code in the application, the user chooses to trust the code in the mock. Instead of mocking the database (at most), a lot of pointless code will be created to hide code that's already there. <blockquote> This is just blind application of dogma. </blockquote> This all comes from years upon years of practice and seeing a lot of code bases and learning what works and what doesn't. It's nothing new nor Go specific. It also happily coincides with a lot of what Go gets good. </pre>hell_0n_wheel: <pre><blockquote> open/close, one for queryctx, execctx </blockquote> That's coupling the interface a bit too closely to the underlying library IMO. What good would this abstraction serve? <blockquote> different packages </blockquote> How would that work, when everything works on one database connection? That's what doesn't make sense. Why different packages? <blockquote> Something that has 2-3 functions or something that has 30+? </blockquote> Either way you slice it, everything still needs mocking and testing. So why different packages? <blockquote> This all comes from </blockquote> From what exactly? In all my experience, I've learned that there are times to follow dogma, and times where one must be practical... what are we gaining from your dogma here? I'm still not seeing it.</pre>dlsniper: <pre>There's no point in a discussion with you as regardless of what arguments I bring you are just stuck in the opposition.</pre>hell_0n_wheel: <pre>You started the discussion. I'm just asking for clarification.</pre>phxIsFarkinHot: <pre>I came from a c# background and made a few structs like this because I couldn't come up with a clean way to manage dependency injection and I was used to having classes with methods. My methodology has drastically changed once I got a good handle on closures and higher-order functions. Now when I need to manage a dependency, I create a func type for the end function I want to end up with, then create a function which takes the dependency as a parameter and returns an instance of the function type. This function instance will have access to the dependency via the closure, and the rest of the code where it's used is none the wiser. I can cook up a link on the playground, or send the link to a helpful article if that would be helpful.</pre>spaztheannoyingkitty: <pre>A playground example would be super useful. This sounds like it's a pure functional approach and I'm intrigued how you expand on this approach for many functions.</pre>tv64738: <pre>"How do I make a clean and neat big ball of mud?" You don't. <a href="https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1" rel="nofollow">https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1</a></pre>Sythe2o0: <pre>If necessary, then I'd make it a composition of multiple sub structs containing tightly coupled items.</pre>