I would recommend doing the simplest things to make it work, and resort to 
more complex stuffs when you actually have the need for them.

In the beginning, there were no *best practices* and people just took the 
easiest way to get their jobs done. Over the years, programming practices 
evolve. There are numerous *best practices* now and -to some people- those 
ideas become almost like religious doctrines. Those *best practices* mostly 
center on the concept of encapsulation. The idea is to allow rooms for 
future changes, so that -when the changes happen- there are minimal breaks 
to the existing code. However, this extra flexibility comes at the cost of 
extra work and complexity. If you have been exposed to the modern 
programming world in the last few decades, you should know what I am 
talking about. Depending on how fanatic you are on any of these *best 
practices* ideas, some of them may actually make life very difficult for 
you, but some people persist because they believe their initial investment 
will pay in the long run. However, based on my experience, people often end 
up creating these elaborate schemes for changes that never come. Some 
changes that did come are often unexpected and you still end up breaking 
many parts of the code any way. It often gets even worse as you now have to 
deal with the complex design that you created before. 

I am not saying that you should go primeval with your programming practice. 
You should strive to make your life easy and let the code evolves as the 
needs for it arise. 

On Tuesday, March 13, 2018 at 1:06:23 PM UTC+7, Reinhard Luediger 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.

Reply via email to