[go-nuts] Re: Why should i use interface composistion
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.
[go-nuts] Re: Why should i use interface composistion
Interfaces are not for grouping variable behavior, interfaces are for
allowing generic code to apply to varying data structures.
Consider a struct of function fields for grouping variable behavior without
a backing data structure.
If your interface type is not an input in the same package then you didn’t
need an interface.
I’m not convinced these three types should be interfaces.
Matt
On Tuesday, March 13, 2018 at 1:06:23 AM UTC-5, 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.
[go-nuts] Re: Why should i use interface composistion
The answer is it depends on the context. There is no way to answer that
question without looking at the full codebase and what method will call a
type implementing the Store interface. In general, you should only put the
methods in an interface the consumer of a value will use.
given a function Print
func Print(s Shape){
s.Draw();
}
if Shape is an interface, there is no need to have a method "Rotate" in
that interface. Shape should only be
type Shape interface{
Draw()
}
and defined in the same package as Print. An interface should be defined
based on what the consumer of that inerface need, nothing else.
In your snippet, if the consumer of Store never calls
DeleteClusterFlavorPermanent then it should not be in Store interface.
--
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.
[go-nuts] Re: Why should i use interface composistion
A good guideline for newcomers is to avoid creating any interfaces at all. Start with writing structs + methods first. Interfaces impose requirements on client code. Keeping them small means clients have fewer requirements. Let the need for an interface arise naturally during evolution of your code, when you have two things that need to act the same. Take the minimal intersection of that need. That becomes a method on a new interface. Also, try not to return interfaces from functions or methods. Rather consume them as input arguments and return pointers to concrete structs when needed. This also makes it easier for clients to use your code. Quoting https://rakyll.org/typesystem/ > You can always embed interfaces later but you cannot decompose large ones. > Language ecosystems with classical inheritance is often suffering from excessive level of indirection and premature abstractions based on inheritance which later makes the code complicated and unmaintainable. -- 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.
