官术网_书友最值得收藏!

A look at a non-modular example

Let's consider an extremely simple example and see how the (somehow) specialized modular approach differs from a non-modular one.

We start by writing a couple of functions in the traditional way, as following:

function doAddition(num1, num2){
  return num1 + num2;
}

function doSubtraction(num1, num2){
  var result = null;
  if(num1 > num2){
  result = num1 - num2;

  }else{
    result = num2 - num1; 
  }
  return result;
}

console.log(doAddition(3,2)); // displays 5

console.log(doSubtraction(3,2)); // displays 1

As you can see in the above code, we have two independent functions for doing simple additions and subtractions and there is no relation between the two, other than the fact that they both operate on the two passed-in numbers (numeric values).

If we had implemented these functions in an application and were to do the identical operations in a different application, we most likely would either rewrite the same functions in that application from scratch or we would copy/paste the code from this application into the other one.

What if we now decided to also do multiplication, division, and other related calculations in our application using the same approach?

Well, one way would be to just continue writing independent functions as above and add them to our application. This approach could work and would get the job done, but probably not in the best way, since as the code grows it will become more disorganized and chaotic.

By using this approach, not only would we be polluting the global namespace with a bunch of global functions that could possibly collide with other global functions of the same name. We would also end up with scattered pieces of code that had not been packaged together based on their functionality and specialization.

If all such functions do mathematical calculations of one kind or another and that is the commonality that they all have, how about if we create a package (module) that specializes in mathematical calculations?

This would allow us to have a specialized package that regardless of the application that it is hosted in, would always provide the same specialized functionality.

Let's even imagine a step further and assume that we created this package in a separate JavaScript file that can be added as an independent module to any application.

Even better, how about if this module only would get added (requested from the server, in the case of a client side web application) to the application at runtime, and only when needed?

This type of implementation would give us the ability to load chunks, pieces, or modules of the code when needed at runtime and then unload them when the application does not need them anymore. This would enable us to cut down on the footprint of our application on the client side while providing all the necessary functionality as needed and on demand.

Such an approach can also be very useful on mobile devices which have limited bandwidth and resources to be leveraged.

Rest assured that I do intend to explore all such possibilities with you in the later chapters of this book.

主站蜘蛛池模板: 河北区| 金平| 大英县| 洮南市| 云浮市| 台山市| 重庆市| 渭南市| 威远县| 明光市| 左权县| 瓮安县| 修武县| 同江市| 新源县| 德阳市| 襄城县| 湘潭市| 新昌县| 平顺县| 潮安县| 平乡县| 西林县| 中西区| 龙游县| 龙山县| 加查县| 唐山市| 洪泽县| 罗江县| 陆河县| 开远市| 建德市| 天长市| 偏关县| 北辰区| 宜川县| 陵川县| 清镇市| 灌阳县| 塔河县|