What exactly are you trying to accomplish? If you are trying to implement a
design pattern, then something akin to your example will work, but its not
clear what about this problem requires not one, but two levels of
indirection (IUserService and IUserDAO).

In my experience, I've found that these patterns are more of a way to
circumvent the inflexibility of certain type systems to allow testing and
configuration, and that these incantations are required at the outset
because changing from something simple later can be challenging. With Go,
its much easier to start out with the simplest implementation possible and
slowly evolve your implementation to add the required functionality when it
is needed.

That said, without knowing more about your problem, I suggest starting out
with an object that wraps your datastore. Using this object heavily
throughout your codebase will tell you if you have the right interface.
When you need to inject a different implementation for testing or some
other requirement, replace that type with an interface and carry on.
On Sunday, September 16, 2012 1:07:38 PM UTC-7, (unknown) wrote:

Well this is for a known problem domain, it's not really a discovery phase.

Since Go was design for large scale programs, I was hoping there would be
some large scale design pattern samples...
On Saturday, September 15, 2012 7:28:25 PM UTC-4, Kevin Gillette wrote:

The suggested approach is to not worry about patterns, and just write the
code. If you get familiar with Go, many problems easily solve themselves in
your mind just based on the conventions and idioms surrounding the
language. Until that time, it's a fast enough language to write code in,
that if your initial approach doesn't work, you'll probably have a good
idea of how to rewrite it.

The most important thing is: don't over-engineer your approaches: don't
be concerned with interfaces, abstractions, interactions, etc, at all,
until you know enough about the problem to be _sure_ they're a good idea.
Just start out with the dumbest/simplest approach you can think of -- it's
better to have an inadequate, overly simple implementation, than an
inflexible, heavy, overkill solution.
On Saturday, September 15, 2012 5:16:30 PM UTC-6, (unknown) wrote:

I'm not sure if this is a typical design pattern when using Go, but if
so, is there an example of something like:

public interface IUserService
User getUser(int id);

public class UserService : IUserService
private IUserDAO _userDao;

public User getUser(int id) {
return _userDao.get(id);

Where the _userDao is also using an Ioc container.

Is this the suggested pattern for or are things different with Go?

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 7 | next ›
Discussion Overview
groupgolang-nuts @
postedSep 15, '12 at 11:16p
activeSep 17, '12 at 12:16a



site design / logo © 2021 Grokbase