StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
20394211
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
10
CommunityOwnedDate
CreationDate
2013-12-05T07:44:06.563
FavoriteCount
0
LastActivityDate
2017-02-27T07:22:04.397
LastEditDate
2017-02-27T07:22:04.397
LastEditorUserId
2714852
OwnerUserId
2714852
ParentId
20380333
PostTypeId
2
Score
50
ViewCount
0
LastEditorDisplayName
text
Body
There're two high-level pieces to this: figuring out which code goes in which package, and tweaking your APIs to reduce the need for packages to take on as many dependencies. On designing APIs that avoid the need for some imports: <ul> <li>Write config functions for hooking packages up to each other at run time rather than compile time. Instead of <code>routes</code> importing all the packages that define routes, it can export <code>routes.Register</code>, which <code>main</code> (or code in each app) can call. In general, configuration info probably flows from <code>main</code> or a dedicated package; you don't want it scattered throughout your app.</li> <li>Pass around basic types and <code>interface</code> values. If you're depending on a package for just a type name, maybe you can avoid that. Maybe some code handling a <code>[]Page</code> can get instead use a <code>[]string</code> of filenames or a <code>[]int</code> of IDs or some more general interface (<code>sql.Rows</code>) instead. </li> <li>Consider having 'schema' packages with just pure data types and interfaces, so <code>User</code> is separate from code that might load users from the database. It doesn't have to depend on much (maybe on anything), so you can include it from anywhere. <a href="https://go-talks.appspot.com/github.com/benbjohnson/structuring-applications-for-growth/main.slide#1" rel="noreferrer">Ben Johnson gave a lightning talk at GopherCon 2016</a> suggesting that and organizing packages by dependencies.</li> </ul> On organizing code into packages: <ul> <li>As a rule, split a package up when each piece could be useful on its own. If two pieces of functionality are really intimately related, you don't have to split them into packages at all; you can organize with multiple files or types instead. Big packages can be OK; Go's <code>net/http</code> is one, for instance.</li> <li>Break up grab-bag packages (<code>utils</code>, <code>tools</code>) by topic or dependency. Otherwise you can end up importing a huge <code>utils</code> package (and taking on all its dependencies) for one or two pieces of functionality (that wouldn't have so many dependencies if separated out).</li> <li>Consider pushing reusable code 'down' into lower-level packages untangled from your particular use case. If you have a <code>package page</code> containing both logic for your content management system and all-purpose HTML-manipulation code, consider moving the HTML stuff "down" to a <code>package html</code> so you can use it without importing unrelated content management stuff. </li> </ul> <hr> Here, I'd rearrange things so the router doesn't need to include the routes: instead, each app package calls a <code>router.Register()</code> method. This is what <a href="http://www.gorillatoolkit.org/pkg/mux" rel="noreferrer">the Gorilla web toolkit's <code>mux</code> package</a> does. Your <code>routes</code>, <code>database</code>, and <code>constants</code> packages sound like low-level pieces that should be imported by your app code and not import it. Generally, try to build your app in layers. Your higher-layer, use-case-specific app code should import lower-layer, more fundamental tools, and never the other way around. Here are some more thoughts: <ul> <li>Packages are for separating independently usable bits of functionality; you don't need to split one off whenever a source file gets large. Unlike in, say, Python or Java, in Go one can split and combine and rearrange files completely independent of the package structure, so you can break up huge files without breaking up packages. The standard library's <code>net/http</code> is about 7k lines (counting comments/blanks but not tests). Internally, it's split into many smaller files and types. But it's one package, I think 'cause there was no reason users would want, say, just cookie handling on its own. On the other hand, <code>net</code> and <code>net/url</code> are separate because they have uses outside HTTP. It's great if you can push "down" utilities into libraries that are independent and feel like their own polished products, or cleanly layer your application itself (e.g., UI sits atop an API sits atop some core libraries and data models). Likewise "horizontal" separation may help you hold the app in your head (e.g., the UI layer breaks up into user account management, the application core, and administrative tools, or something finer-grained than that). But, the core point is, you're free to split or not as works for you.</li> <li>Set up APIs to configure behavior at run-time so you don't have to import it at compile time. So, for example, your URL router can expose a <code>Register</code> method instead of importing <code>appA</code>, <code>appB</code>, etc. and reading a <code>var Routes</code> from each. You could make a <code>myapp/routes</code> package that imports <code>router</code> and all your views and calls <code>router.Register</code>. The fundamental idea is that the router is all-purpose code that needn't import your application's views. Some ways to put together config APIs: <ul> <li>Pass app behavior via <code>interface</code>s or <code>func</code>s: <code>http</code> can be passed custom implementations of <code>Handler</code> (of course) but also <code>CookieJar</code> or <code>File</code>. <code>text/template</code> and <code>html/template</code> can accept functions to be accessible from templates (in a <code>FuncMap</code>).</li> <li>Export shortcut functions from your package if appropriate: In <code>http</code>, callers can either make and separately configure some <code>http.Server</code> objects, or call <code>http.ListenAndServe(...)</code> that uses a global <code>Server</code>. That gives you a nice design--everything's in an object and callers can create multiple <code>Server</code>s in a process and such--but it also offers a lazy way to configure in the simple single-server case. </li> <li>If you have to, just duct-tape it: You don't have to limit yourself to super-elegant config systems if you can't fit one to your app: maybe for some stuff a <code>package "myapp/conf"</code> with a global <code>var Conf map[string]interface{}</code> is useful. But be aware of downsides to global conf. If you want to write reusable libraries, they can't import <code>myapp/conf</code>; they need to accept all the info they need in constructors, etc. Globals also risk hard-wiring in an assumption something will always have a single value app-wide when it eventually won't; maybe today you have a single database config or HTTP server config or such, but someday you don't.</li> </ul></li> </ul> Some more specific ways to move code or change definitions to reduce dependency issues: <ul> <li>Separate fundamental tasks from app-dependent ones. One app I work on in another language has a "utils" module mixing general tasks (e.g., formatting datetimes or working with HTML) with app-specific stuff (that depends on the user schema, etc.). But the users package imports the utils, creating a cycle. If I were porting to Go, I'd move the user-dependent utils "up" out of the utils module, maybe to live with the user code or even above it.</li> <li>Consider breaking up grab-bag packages. Slightly enlarging on the last point: if two pieces of functionality are independent (that is, things still work if you move some code to another package) and unrelated from the user's perspective, they're candidates to be separated into two packages. Sometimes the bundling is harmless, but other times it leads to extra dependencies, or a less generic package name would just make clearer code. So my <code>utils</code> above might be broken up by topic or dependency (e.g., <code>strutil</code>, <code>dbutil</code>, etc.). If you wind up with lots of packages this way, we've got <a href="https://github.com/bradfitz/goimports" rel="noreferrer"><code>goimports</code></a> to help manage them.</li> <li>Replace import-requiring object types in APIs with basic types and <code>interface</code>s. Say two entities in your app have a many-to-many relationship like <code>User</code>s and <code>Group</code>s. If they live in different packages (a big 'if'), you can't have both <code>u.Groups()</code> returning a <code>[]group.Group</code> and <code>g.Users()</code> returning <code>[]user.User</code> because that requires the packages to import each other. However, you could change one or both of those return, say, a <code>[]uint</code> of IDs or a <code>sql.Rows</code> or some other <code>interface</code> you can get to without <code>import</code>ing a specific object type. Depending on your use case, types like <code>User</code> and <code>Group</code> might be so intimately related that it's better just to put them in one package, but if you decide they should be distinct, this is a way. </li> </ul> Thanks for the detailed question and followup.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POCyclic dependencies and interfaces in Golang
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. UStwotwotwo
UserOwnerUserId
1. UStwotwotwo
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POCyclic dependencies and interfaces in Golang
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.