FAQ
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

  • Kevin Gillette at Sep 15, 2012 at 11:28 pm
    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?
    --
  • Sahmed1020 at Sep 16, 2012 at 8:07 pm
    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?
    --
  • Stephen Day at Sep 16, 2012 at 9:13 pm
    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?
    --
  • S Ahmed at Sep 16, 2012 at 9:42 pm
    I see what you guys are seeing.

    But to me java and Go are just languages, is there something with Go that I
    can take lighter approach and with Java I couldn't? i.e. simple now, and
    have the ability to change mid-way...

    How can I unit test a particular service if the db layer is tightly coupled?
    On Sun, Sep 16, 2012 at 5:13 PM, Stephen Day wrote:

    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?
    --
  • Tomwilde at Sep 17, 2012 at 12:16 am

    How can I unit test a particular service if the db layer is tightly
    coupled?
    If I got your question right, then the solution is simple:

    type DbAdapter interface {
    // ...
    }

    Different implementations of DbAdapter can be written.
    Your service's depend on DbAdapter's behaviour, not its implementation.
    You can then unit-test your services by providing them with a
    mocked DbAdapter.

    In general, when writing Go, do it concretely and straightforwardly. Only
    abstract when you have a need for generality.
    Changing Go code from using a concrete type to an interface is fairly
    simple and easy. Most of the time it requires no refraction.

    Cheers!

    --
  • Jesse McNelis at Sep 16, 2012 at 11:20 pm

    On Sun, Sep 16, 2012 at 9:16 AM, 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);
    }
    }
    type UserService struct {userDao UserDao}
    type User struct{//probably some fields in here}
    type UserDao interface{//probably some methods in here}

    func(u *UserService)getUser(id int) User{
    return u.userDao.get(id)
    }
    Where the _userDao is also using an Ioc container.
    func NewUserService(u *UserDao)*UserService{
    return &UserService{userDao: UserDao}
    }
    Is this the suggested pattern for or are things different with Go?
    --
    =====================
    http://jessta.id.au

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 15, '12 at 11:16p
activeSep 17, '12 at 12:16a
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase