Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to parse the library design from Moco

2025-04-02 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

How to design from Moco parsing library, I believe many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Moco includes two aspects in library design, how to set up the server and how to make the server run.

Let's start with the simple question of how to get the server running. The simplest option is to let the user start the server himself and then shut down the server at the end of the test. As a result, each test would look something like this:

Public void shouldWork () {... Setup server... Try {server.start ();... Your test here.} finally {server.stop ();}}

As a framework, the interface left to the customer must be simple, encapsulating the implementation details within the framework. If every test is written in this way, users will soon scold their mother. The current practice of Moco is to use the running method to encapsulate the details of Server start and stop.

Running (server, new Runnable () {@ Override public void run () throws Exception {assertThat (helper.get (root ()), is ("foo"));})

I know you don't like anonymous inner classes, and neither do I, but this is the limitation of Java. When Java 8 arrives, I'm sure everything will change.

Set up the server, that is, what kind of request, what kind of response. Moco has a key starting point, and that is DSL, you know, I just finished translating "domain-specific languages" some time ago. Therefore, the readability of API has become a very important thing.

It's simple to say, but you should know that there are many conditions for matching requests, and they can be combined arbitrarily. If these conditions are independent of each other ("or"), I can use variable parameters to solve them, but sometimes these conditions are related ("and"), what should I do? Thanks to the idea of functional programming, I came up with the way to combine functions.

I know that Java does not have first-class citizen functions, but there are first-class citizen objects in Java, and we can use objects to simulate functions. In fact, this is also a way for many object-oriented programming languages to solve function combinations, and such objects are called function objects, also known as functor.

Encapsulate the required conditions into function objects, and then combine them with a few simple operators. Two operators, and and or, are currently available in Moco for combination.

Server.request (and (by (uri ("/ foo")), by (method ("put") .response ("bar"); server.request (or (by ("foo"), by (uri ("/ foo") .response ("bar")

With the popularization of object-oriented thinking, the writing of function combination will become more and more common, and it will become a must in the toolbox of the program staff.

DSL is an important consideration, so instead of a direct new object, it is encapsulated with functions (such as uri, method). You might say, then I can design the class name to be readable for readability, but what's wrong with new an object? It's on new. On the one hand, new is to create an object, which is an implementation detail, which is not at the same level as what we are trying to express. On the other hand, you will find that multiple new will make this sentence seem incoherent. This sentence? Yes, our way of writing is like declaring something in one sentence, and we expect to have a certain degree of consistency in what we say, and this is DSL.

Once designed as DSL, the document for a single function loses its meaning and, more importantly, a document for usage. So, in Moco, I wrote the document, but not JavaDoc.

In Moco, there may be the same thing in the request and response, such as file, while the parameter types of request and response are different. If file can return different types, it is *. Unfortunately, in Java, we cannot overload according to the return type. One solution is to design a function for request and response, such as requestFile and responseFile, but obviously this will spread the same logic between the two class implementations, and this requires sharing not only file, but also other things.

In computer problems, adding a middle layer is always an important solution. This is also the purpose of by. In this way, these shared things can be made into a Resource, which can be adapted into a Matcher as long as there is a by for the request.

In Moco design, there is also a very important point in framework design: type. Java is a statically typed programming language. By making good use of types, errors can be reported at compile time without leaving them at run time. Fail fast is a very important programming practice.

Moco currently supports some Content Type detection. If you put this Content Type in Resource, you will find that not all Resource needs this, such as method. Of course, we can support Content Type in the Resource interface and throw exceptions where they are not needed.

In Moco, my approach is to introduce a ContentResource, support Content Type, it inherits from Resource, so dependent, requires Content Type's interface (such as content), directly supports ContentResource, while other parts continue to support Resource, so that if accidentally used incorrectly, the compilation will report an error.

Another point is about the Publish interface. In the implementation of Moco, there is a Setting and a BaseSetting. If you look at the implementation, you will create a BaseSetting when you set Request, but the interface returned is Setting. One reason for this is that because Setting appears on interfaces that users can use, while BaseSetting is reserved for internal implementation, it provides methods for internal implementation that users should not use, so a separation is made between the two, which ensures that users do not misoperate. Also dealing with HttpServer and ActualHttpServer.

Make a summary, simplify the user interface, design DSL, make good use of types, and distinguish Publish interfaces.

After reading the above, have you mastered how to parse the library design from Moco? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report