In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-03-31 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >
Share
Shulou(Shulou.com)06/01 Report--
In this article, the editor introduces in detail the "core case analysis of laravel", with detailed content, clear steps and proper handling of details. I hope this "core case analysis of laravel" article can help you solve your doubts.
The core of laravel is the service container, that is, the IOC container. The container provides a series of services needed in the whole framework, including dependency injection and control inversion, which is a design principle in object-oriented programming and can be used to reduce the coupling between computer code.
This article operating environment: Windows10 system, Laravel6 version, Dell G3 computer.
The core of laravel
The service container, also known as the IOC container, actually contains two parts: dependency injection (DI) and inversion of control (IOC), which is the real core of laravel. Other functional modules such as Route (routing), Eloquent ORM (database ORM component), Request and Response (request and response), and so on, are actually provided by core-independent class modules, which are actually responsible for the service container of laravel from registration to instantiation and eventually being used by you. The concept of service container is difficult to explain, and it can only be explained step by step from the history of service container.
The container provides a range of services needed throughout the framework.
The Story of the birth of IoC Container-- Stone Age (primitive pattern)
We take a "Superman" as a class.
Class Superman {}
We can imagine that a superman must have at least one superpower when he was born, and this superpower can also be abstracted as an object, and define a class for that object to describe it. A superpower must have multiple attributes and (operation) methods, and this is a hearty imagination, but at present, we roughly define a "superpower" with only attributes, and as for what we can do, we will enrich it later:
Class Power {/ * capability value * / protected $ability; / * capability range or distance * / protected $range; public function _ _ construct ($ability, $range) {$this- > ability = $ability; $this- > range = $range;}}
At this point, let's go back and modify the previous "Superman" class so that a Superman is given a superpower when it is created:
Class Superman {protected $power; public function _ _ construct () {$this- > power = new Power (999,100);}}
In this way, when we create an instance of "Superman", we also create an instance of "superpower", but we see that there is an inevitable dependency between "Superman" and "superpower".
The so-called "dependence" is "if I rely on you, there will be no me without you".
Such dependencies can be seen everywhere in a project that implements object-oriented programming. A small amount of dependency will not have a very intuitive impact, and we will gradually spread out this example to make people realize what a nightmare experience it is when dependence reaches an order of magnitude. Of course, I will naturally talk about how to solve the problem.
In the previous example, the superpower class is instantiated into a specific superpower, but we know that superhuman superpowers are diversified, and the methods and attributes of each superpower are quite different, which can not be described completely by one category. Let's modify it now, and we assume that Superman can have the following kinds of superpowers:
Flight, attributes are: flight speed, continuous flight time
Brute force, attributes are: strength value
Energy bomb, attributes are: damage value, firing distance, number of simultaneous shots
We created the following classes:
Class Flight {protected $speed; protected $holdtime; public function _ _ construct ($speed, $holdtime) {} class Force {protected $force; public function _ construct ($force) {} class Shot {protected $atk; protected $range; protected $limit; public function _ construct ($atk, $range, $limit) {}}
Well, now our Superman is a little busy. When Superman initializes, will we instantiate his superpowers as needed, roughly as follows:
Class Superman {protected $power; public function _ construct () {$this- > power = new Fight (9100); / / $this- > power = new Force (45); / / $this- > power = new Shot (99,50,2); / * $this- > power = array (new Force (45), new Shot (99,50,2)); * /}}
We need to manually instantiate a series of required classes within the constructor (or other methods), which is not good. As you can imagine, if the requirements change (different monsters roam the planet), we need more targeted new superpowers, or if we need to change superpower methods, we have to reinvent Superman. In other words, while changing my powers, I have to create a new Superman. It's too inefficient! The world has long been destroyed before the new Superman has been created.
At this time, the man with an idea thought: why can't this be done? Superman's abilities can be replaced at any time by adding or updating a chip or other device (not thinking about Iron Man). In that case, don't start all over again.
The Story of the birth of IoC Container-- the Bronze Age (Factory Mode)
We should not manually solidify his "superpower" initialization behavior in the "Superman" class, but transfer to the external responsibility to create superpower modules, devices, chips, etc. (we later call them "modules"). Implanted into a certain interface in Superman, this interface is a given, as long as the "module" meets this interface, the device can be used by Superman. It can enhance and increase a certain ability of Superman. This kind of behavior in which the outside is responsible for its dependence on requirements, we can call it "IoC".
The factory pattern, as the name implies, is an instance of the external things on which a class depends, a development pattern that can be created by one or more "factories", namely the "factory pattern".
In order to create superpower modules for Superman, we have created a factory that can make a variety of modules in only one way:
Class SuperModuleFactory {public function makeModule ($moduleName, $options) {switch ($moduleName) {case 'Fight': return new Fight ($options [0], $options [1]); case' Force': return new Force ($options [0]); case 'Shot': return new Shot ($options [0], $options [1], $options [2]);}
At this time, Superman can use this factory at the beginning of his creation!
Class Superman {protected $power; public function _ _ construct () {/ / initialization plant $factory = new SuperModuleFactory; / / the required modules are manufactured by factory-supplied methods $this- > power = $factory- > makeModule ('Fight', [9100]); / / $this- > power = $factory- > makeModule (' Force', [45]) / / $this- > power = $factory- > makeModule ('Shot', [99,50,2]); / * $this- > power = array ($factory- > makeModule (' Force', [45]), $factory- > makeModule ('Shot', [99,50,2]); * /}}
We can see that we no longer need to initialize many third-party classes at the beginning of Superman initialization, we only need to initialize a factory class to meet the demand. But this doesn't seem to be much different from what it used to be, except that there aren't so many new keywords. In fact, if we modify this class a little bit, you will understand the true meaning and value of the factory class.
Class Superman {protected $power; public function _ construct (array $modules) {/ / initialization plant $factory = new SuperModuleFactory; / / manufacture the required module foreach ($modules as $moduleName = > $moduleOptions) {$this- > power [] = $factory- > makeModule ($moduleName, $moduleOptions) } / / create Superman $superman = new Superman (['Fight' = > [9100],' Shot' = > [99,50,2]])
Now the result of the revision is satisfactory. Now, the creation of "Superman" no longer depends on any "superpower" class, if we modify or add a new superpower, we only need to modify the SuperModuleFactory.
After reading this, the article "Core case Analysis of laravel" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself to understand it. If you want to know more about related articles, welcome to follow the industry information channel.
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.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.