The advice regarding small interfaces goes further than just a simple
"don't put many methods in an interface" - it includes (and is based on) a
different philosophy of using interfaces. The advice assumes that you
shouldn create an interfaces for the database backend in the first place -
instead, make it a concrete type, as there will likely be only one
implementation any way. This kind of interface most often comes from a
desire to mock out the database during testing - instead, use the real
implementation and make it possible to fake out *its* dependencies (e.g.
start up a database server for tests or use a driver with a memory-based
backend).

That doesn't mean you can't do what you are doing; IMO it's fine. Just,
that the advice about small interfaces is based on a different usage
pattern for them.

On Tue, Mar 13, 2018 at 7:06 AM, 'Reinhard Luediger' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Dear all,
>
> as far as I know it is recommended to keep actual interfaces as small as
> possible and to form bigger interfaces via interface composiston.
> Would be great if the community could advise me what the real benefits are.
>
> Lets say i want to create an interface for the database backend like the
> following example.
>
> //CleanupTimestamps is the interface which holds all methods related to 
> cleanupTimestamps
> type CleanupTimestamps interface {
>    SaveCleanupTimeStamp(taskName string, timestamp time.Time) (err error)
>    GetCleanupTimeStamp(taskName string) (timestamp *time.Time, err error)
> }
>
> //ClusterFlavors interface holds all methods related to clusterFlavor
> type ClusterFlavors interface {
>    CreateClusterFlavor(Name string, tx StoreTransaction) (Flavor 
> datatypes.ClusterFlavorPersisted, err error)
>    UpdateClusterFlavor(ID string, Name string, tx StoreTransaction) (err 
> error)
>    MarkClusterFlavorDeleted(ID string, tx StoreTransaction) (err error)
>    DeleteClusterFlavorPermanent(ID string, tx StoreTransaction) (err error)
>    ReadClusterFlavor(ID string) (Flavor datatypes.ClusterFlavorPersisted, err 
> error)
>    ListClusterFlavors(Includedeleted bool) (Flavors 
> []datatypes.ClusterFlavorPersisted, err error)
> }
>
> //Store is the interface to encapsulate the Storage  Backend
> type Store interface {
>    MustBegin() (tx StoreTransaction)
>
>    CleanupTimestamps
>    ClusterFlavors
> }
>
>
> Why should I create it in that fashion if I ever use the Store interface
> in my cod? Or what are the drawbacks if I put all methods needed directly
> into the Store interface?
>
> kind regards
>
> Reinhard
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to