Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 17 additions & 19 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,69 +1,67 @@
# appenginedecorators
# appengine decorators
Useful decorators for App Engine

# Embrace the Interface
## Motivation
Concepts of decorators is highly based on Robert Pike's Statement "If Java and C++ are about types hierarchies and taxonomy Go is about composition"

# Introduction
Decorators:By Optimised use of abstraction,Design pattern and other software engineering principles we can design a genric functions, and work with
Go'sPhiosopy of composiblity,
Decorators:By Optimized use of abstraction,Design pattern and other software engineering principles we can design a generic functions, and work with
Go's Philosophy of composability,

In decorators we try to take small chunk of code and perform a particular operation and putting them back togather to work in tandem.By using this we
can singlify code for various comman functionalities to be applied on our business logic. They are simple orthogonal constructs in order to make
In decorators we try to take small chunk of code and perform a particular operation and putting them back together to work in tandem.By using this we
can singlify code for various common functionality to be applied on our business logic. They are simple orthogonal constructs in order to make
our entire logic simpler.



## Handler Interface

``` GO
// A Client sends an Http request and receivres any type which implements the interface or err in case of failure

//Handler interface sends an Http request and receives any type which implements the interface or err in case of failure
type Handler interface {
Do(r *http.Request, ps httprouter.Params, username string) (interface{}, *ServerError)
}
```
## Handler Function

``` GO
// Handler func is a function which implements Handler Interface.
//Handler func is a function which implements Handler Interface.
type HandlerFunc func(r *http.Request, ps httprouter.Params, username string) (interface{}, *ServerError)

func (f HandlerFunc) Do(r *http.Request, ps httprouter.Params, username string) (interface{}, *ServerError) {
return f(r, ps, username)
}
```
## Decorator Pattern

It is a design pattern that allows behavoiur to be added to an instacne of a type without afftecting the behavour of the instacnes of the
same type. A function takes a client and returns the client of same type with an enriched behavour,for example Authorixzation ,load balcning,
It is a design pattern that allows behavior to be added to an instance of a type without affecting the behavior of the instances of the
same type. A function takes a client and returns the client of same type with an enriched behavior,for example Authorization ,load balancing,
logging,pagination or search and much more.

``` GO
//This goes well with the single responsibility principle and the open close principle of software engineering
//(software entities should be open for extension and closed for modification)
type Decorator func(h Handler) Handler
//This goes well woth the single resposniblty principle and the open close principle of software engineering
//(software entitties should be open for extension and closed for modification)
```
## How to bind this orthogonal codes togather?
## How to bind this orthogonal codes together?

``` GO
// Decorate takes a client and one layer of behavior on the client with every loop, in this the client
// functionality typically our business logic remains unchanged ,this confirms with our open closes princilpe and separation of concern principle.
func Decorate(h Handler, ds ...Decorator) Handler {
decorated := h
for _, decorate := range ds {
decorated = decorate(decorated)
}
return decorated
}

// We can take a client and one layer of behavior on the client with every loop, in this the client
// functioanlity typically our business logic remains unchanged ,this confirms with our open closes princilpe and separation of concern principle.

```

## Onion Rings Analogy

Consier the client (Handler) as the core of a onion ring and the decorators as the layers of the onion rings which
Consider the client (Handler) as the core of a onion ring and the decorators as the layers of the onion rings which
adds on the core to enhance it without modifying it. (Open Closes Rule!)

![Onion Slice](https://github.com/s-garg/appenginedecorators/blob/master/githubimage.png)