Scala akka cultivation 6 (Analysis of scala functional ke Lihua style application scenarios)

The victory and defeat of the military are not in the future, and the shame of the bag is the male-douniu fighting, fighting, fighting...

It has been some time since I learned and used scala. At first, I learned scala mainly to learn the spark ecosystem. But after learning some scala features, I was deeply impressed by scala functional and object-oriented styles and had to praise the designers who designed the language. When using MATLAB for data analysis and automated design, Xiao Xiang enjoys compiling analysis code using MATLAB command lines and matrix-oriented operations; I like to write hierarchical and clear module interfaces in java, and these Scala languages are well designed. I have to say that scala's functional and object-oriented style can happen at any time. If you are a painter, the code written using scala is more like a poetic landscape. If you are a writer, you will write a thrilling and fluctuating article. Scala gives different types of programmers different experiences and feelings. The scala function-based coli style allows you to write more abstract, functional, and efficient functional code.

This is often the case when the main function is defined. The longer the code in the function body is written, the longer the function can be split. Because the logic cannot be stopped during code writing, don't want to interrupt in the middle to define those tedious auxiliary functions, often a function goes all the way to the header, and finally makes the main function code segment very long, inconvenient to understand, the function is complex, you need to slowly split the function later. After learning to use the scala functional ke Lihua style, Xiao Xiang needs the sharding function when his thoughts cannot be stopped, the Declaration of the auxiliary function to be split is defined in the function declaration according to the Ke Lihua style. After the main function is completed, these auxiliary functions are gradually implemented in order. You can create a primary function overload to reduce or hide unnecessary auxiliary method parameter input in the convenience interface of the auxiliary function. Using the scala Keri style can simplify the complexity of the main function, improve the self-closing of the main function, and improve the extensibility of the function (facts have proved that the streamlined production method is the most efficient and secure, the same is true for code writing. Maintaining a function to complete processing (logical processing, related exception handling, etc.) is also the pursuit of simple design and excellent code health check ).

For example, a function is designed to obtain data from all rows of a local text file. The main function is to create a file stream to read all rows of the file. During the reading process, many auxiliary operations are required, such as checking whether a local file exists and reading and closing the file stream. Using scala's function-based Keri code looks very elegant

def getLines(filename:String):List[String]={    getLines(filename)(isReadable)(closeStream)}def getLines(filename: String)(isFileReadable: (File) => Boolean)(closableStream: (Closeable) => Unit):List[String] = {    val file = new File(filename)    if (isFileReadable(file)) {      val readerStream = new FileReader(file)      val buffer = new BufferedReader(readerStream)      try {        var list: List[String] = List()        var str = ""        var isReadOver = false        while (!isReadOver) {          str = buffer.readLine()          if (str == null) isReadOver = true          else list = str :: list        }        list.reverse      } finally {        closableStream(buffer)        closableStream(readerStream)      }    } else {      List()    }  }  def isReadable(file: File) = {    if (null != file && file.exists() && file.canRead()) true    else false  }  def closeStream(stream: Closeable) {    if (null != stream) {      try {        stream.close      } catch {        case ex => Log.error(“[”+this.getClass.getName+”.closeStream]”,ex.getMessage)      }    }  }

Xiao Xiang believes that using the Keri feature can simplify complex logic, and expose the processing that is often missed out of the business logic of the main function to the definition stage of the function, improving the robustness of the Code, makes function functions more refined and streamlined.

For example, the frontend request server segment processing process for WEB development based on a three-tier MVC model using restful HTTP resource requests mainly includes: Step 1: the server side accepts user resource requests, step 2: the front-end scheduler proxy accepts user resource requests. Step 3 checks the validity of the current request. Step 4 creates the corresponding request for filtering and processing links. Step 5 creates a rendering view, step 6: respond to user requests.

It will be very simple and easy to understand to write process control functions using scala

/*** User resource request => scheduler proxy user resource request => check the validity of the request => Create a resource application responsibility chain and return Model data and view URI => Create View => response to user requests */def serviceUserRequest [IN, m, V, OUT] (requstInputData: IN) (dipatcherDelegeteOp: IN => M) (checkRequestValid: M => Boolean) (filterChains: M => M) (createResponseRestURLView: M => V) (createResponseStream: V => OUT): OUT = {val request = dipatcherDelegeteOp (requstInputData) if (checkRequestValid (request) {val model = filterChains (request) val view = createResponseRestURLView (model) createResponseStream (view)} else {/error business handler "return error view URI Stream "}}