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.
