 Welcome everyone. Hope you are enjoying the DrupalCon Asia. Thank you for coming this evening. This is a design patents in PHP. Myself Mohit Aghera and he is in Drupal. Basically I am working with Drupal since Drupal 6, basically like Drupal 5 and currently I am working as a Drupal developer at Excellent since last couple of years. Here is my Drupal Internet ID. I am Ankit Agrawal. I am working in Drupal since 4 years and have worked on projects like migration of sites from Drupal 5 to Drupal 7, Drupal 6 to Drupal 7 so I am working in Excellent since 1.5 years. You can reach me open my Drupal Internet ID. Thank you. Now let's see what is design patents. So any of you are aware or no grief about design patents. So now let's see what is design patent. Basically, famous architect Christopher Alexander has explained this nicely. He says that each patent particularly represents a problem that occurs over and over. Now identify the poor solution of the problem. Now this solution is something that can be utilized millions of times without doing the same thing. So we told in architecture language but same holds true for object oriented programming as well. Basically by just knowing the object oriented basics doesn't make anyone a good object oriented designer. For this you need to think about various approaches to solve the problem like identify the problem in its context, the solution and the elements of the solution that will make up the design, the relationship between the classes and objects for that particular solution. The consequences that will arise like when you apply that particular solution. So all these things together makes the design patent. So as we know that design patents aren't invented basically. They are discovered basically based on the years of experience of object oriented programming. And as we know that patent usually doesn't give you a code. It usually gives you a kind of generate solutions to particular design problems and we have to apply that to our problems. So this is how basically a patent works. Generally all the patents deals with the kind of the way they implement use cases for future maintainability. Now let's see why to use the design patents. Because yes, design patent provides kind of easy to use and recognize various object oriented programming solutions. So that's a kind of advantage and apart from that it provides much more flexible system because our code is well organized and particular as per the kind of well categorized basically. And apart from that it allows to say more with less. When you are communicating with your fellow developer in terms of design patent, you are not just communicating better names basically. You are communicating kind of various set of characteristics constraints that the better be present. So this way basically it helps to achieve much more fine grant communication among developers. Now let's see like where the design patent resides in object oriented layers. So as we know that there are object oriented basics like inspection, inheritance, polymorphism at all. Above that there are various object oriented principles like encapsulated varies, programmed interface and all. So encapsulated varies means if you take the portion of a program that gets sent frequently and encapsulated. So it won't affect your rest of code and system will be much more flexible. And apart from that yeah, it will have much more unintended consequences from code change. So that's what about encapsulated code varies. Above that there are design patents particularly observable at all the design patents. Now let's see how can we categorize patent. Basically there are various ways to categorize patents. So first one is for purpose. So purpose literally reflects like what patent does. So patent can have either creational, structural and behavioral purpose. So creational patent basically deal with object creation. So kind of abstract factories in certain are the creational patents. Whereas structural patent deals with the relationship between classes and objects. And the behavioral patent that like maintains the relationship between classes and objects such that they interact with each other and they share the responsibility with each other. So this is a kind of way to categorize patent based on purpose. Now another one is called scope. Scope means I mean literally patent is applied to classes or objects. So when the patent is applied primarily to classes. At the time the relationship among the classes are established using the inheritance. So this is somewhat fixed that compiles them because the relationship is maintained in code. And when the scope is object at that time the relationship will be maintained actually and it's much more flexible than the class scope. Now let's see a few patent one by one. Now let's see an observer pattern. Let's take one example from publishing industry. As you know that the newspaper publishes publishes newspaper. Now we as a subscriber subscribes particular newspaper. So every time newspaper gets published each copy will be delivered to us. Now let's say we don't want that particular newspaper. So we'll just unsubscribe it. Subscribe another one. And the same thing happens. So as per this example kind of publisher and subscriber together makes an observer pattern. So as per this example publisher will be the subject and the observer will be the subscriber. So observer pattern literally means whenever any state change in subject happens all the observers will be notified. So as we know that it's a kind of behavior pattern because it works based on objects because any state change in subject happens, subject object happens all the observers object will be notified. And as we can see from here that it provides one to many relationships. Because here we can see that there is only one subject and all the observers will be notified. So by this way it provides one to many relationships. Now let's see class diagram for observer pattern. So we have a basically subject interface and the observer interface. So subject interface defines various methods for kind of register observer, remove notify observer and all. And we have a concrete subject class that implements particular interface and it will implement that relevant methods. Apart from that we have observer interface and the concrete observer class that implements particular interface. Now whenever any state change happens in subject it will notify concrete observer objects. So upon notification concrete observer may vary the particular subject that will get the updated value that will be notified based on updated value. They will reconcile their state based on the updated information of concrete subject. So this is how particularly the communication flow happens. As we can see that it provides loose coupling. Let's see here because here if we see concrete subject it only knows about observer that they implement certain interface. So they don't have any knowledge about concrete observer class. So by this way it provides loose coupling. Now we have a SPL subject and SPL observer class in PHP. So that allows to implement observer pattern. And it is in Rupal. Rupal is also actually built on a twin pattern of observer and visitor. So in Rupal we have a root node load and root is a log in. So both are observers on node and user respectively. Now let's see where it's used in Rupalite. As we know that Rupalite is using lots of components from symphony. So particularly even this particular component of symphony is using observer pattern. In Rupal we have an event subscriber interface. So basically what it does is just particular events and like which function to call. So in Rupal we have one more kind of path subscriber interface. So what it will do like by implementing various method that converts path areas. So in the get subscribed event function of a path subscriber class, we can register various event like one kernel terminated. We can register like which function to call. Or one kernel controller. We can register which function to call. So this is how it is implemented in Rupalite. Apart from that we have various other classes like root preloader and many more. So it's basically used in Rupalite. And as we can see that it has lots of advantages. One more advantage is that it supports broadcasting. Because unlike any regular communication center doesn't need to specify the receiver. It's just a broadcast updated message and all the observers will get notified based on the information. So this way it supports broadcast. And it also provides news coupling. Now let's see visitor pattern. So it is also kind of a behavior pattern and it primarily applies to object. As we see in observer pattern that whenever any state change happens all observer get notified. But in that case when you want to extend the functionality of subject at that time you don't want to modify the class of the subject. At that time you can use a visitor pattern. So simply for the use case you want to add extra functionality. But you don't want to modify that class. At that case you can use a visitor pattern. Let's see one example When you go to the supermarket when we buy all the products just go to checkout. At that time the cashier will act as a visitor. It will take each product from a cart and it will prepare the product. So in that case a cart will be the kind of set of elements. A product will be the elements and cashier will act as a visitor. Let's see one more example for a compiler that we present program as aspects in next week. So for this case compiler needs to perform various like validation for semantic analysis and type checking and work. So now let's say one class that defines operation for type checking there is one more class that defines operation for let's say data validation flow analysis and work. Apart from that we can use that abstract syntax view for pretty printing code restructuring and all. So the problem with this design is that when we have all the functionalities are in separate classes or separate nodes. So that will result the system that's hard to maintain and understand. Apart from that this kind of code will be mixed. You can't imagine that pretty printing code is mixed with program restructuring and like validation code is mixed with type checking and all. So it is somewhat less flexible. So let's say how we can use visitor better over here. So here we have visitor class. So that defines particularly visit methods for each concrete element classes. So here we can see concrete element classes. Now we have a concrete visitor one and visitor two. So that can be a number of concrete visitor classes. They particularly implement all the methods defined by the visitor interface. We have an element class that defines except method which will have a visitor object, concrete visitor object as argument. And we have concrete element classes that implement except operation and they'll implement few more operations like this for the requirement. So now let's see where it's used in Rupal 8. So it will be much more better. We have in Rupal we have a metadata interface. So basically it provides kind of validation constraints. It provides some sort of validation criteria. So we have one more kind of validation visitor interface. So that performs a various validation. So by implementing validation visit interface, validation visitor class will use a visitor better. So when you want to initially it will call the validation method. So based on that it will identify which metadata interface to call. So based on the particular identification it will call the relevant metadata interface. So in that case if it has identified for type data it will call the particular except method for that metadata interface. So this is how communication happens in Rupal 8. Let's see it has lots of advantages like it allows to add new functionality dynamically. We don't have to change the code for particular class. Apart from that as you can see that it gathers related operations and separate unrelated ones. I guess we see in our compiler example. So here we can gather related operations like kind of printing and all in separate. And we can separate other unrelated operations. Now as we see in Rupal, in Rupal we have in the formata in node view. So basically they are the visitors on a form in node respectively. So let's say when you are trying to implement a formata okay. And they can hook formata with all the modules which has implemented hook formata. So that is how it helps to implement a kind of visitor better in using formata and node view. Apart from that it has kind of few disadvantages as well. Let's see class data. See here like if you want to add a new concrete element class for this you will have to implement a relevant function in concrete visitor classes and you have to define it in a visitor class. So in this case I mean it becomes somewhat more complex when you want to add a new concrete element. Apart from that when you are trying to add a new functionality to the object at runtime you have to expose that object so at that time there might be some issues with the integrity of object because you have to expose that object to excellent sources of other objects. So that's the kind of disadvantage for visitor better. Hope you guys are following me. Now let's see decorative better. So it's a kind of structural better because like it maintains a relationship between classes and it's a glass to objects. Let's see like the decorator is known as a wrapper as well. I mean literally means we are going to decorate one object with another object. So it kind of provides a flexible alternative to subclassing as well. Let's see one example. We have a concrete component and another one is concrete decorator. So basically let's see when you have like a concrete component. So dark roast will be the concrete component and mocha will be the decorator. So while calculating the cost external object will initially pull the method A. Let's say method A returns cost. So it will pull the method A so first time the method A of mocha object will be pulled which will internally pull the method A of concrete component that's dark roast. So method A of dark roast will return its cost to concrete decorator. Now concrete decorator will end its own cost and ultimately it returns final cost. So similarly you can add any number of supplements to particular dark roast. So let's say you can add any decorator to concrete component. So basically how it helps because let's say when you implement using the subclassing at the time you will have to like implement the subclasses for each thing. Let's say dark roast mocha, like one more class for dark roast with coffee and it will have lots of classes for kind of for each combination. So this one is the much more flexible solution. Now let's see like class diagram. Here we have a concrete component so concrete component is the object that is going to be decorated and now we have a decorator that will decorate particular concrete component. Apart from that decorator has a reference to a component so it means it will have reference to particular component. Apart from that we can also see one more thing like decorator and concrete component implements the same interface. And we have other decorators that implements decorator and various operations. Now let's see where it's used in the Drupal 8. Basically the query extender of Drupal are the nice example for decorator pattern. Now let's see like when you write the dgclect or query. Let's say that you will write a query object. Now we have a select interface that defines various methods for like kind of getting the field and execution and all. And we have a select class that implements, so select class that implements all the methods defined by the interface. Now let's say you want to add extra functionality like kind of for table sorting and weather select and all. So at that time we have one more class or interface that's select extender. So select extender will have a query of object and select. So it means you can assume that select object is decorated with select extender. So it will be inside select extender. And based on that we can implement table sort extender and weather select extender function. So as we see that there are various advantages and it provides a flexible alternative to the class. But from there there are few disadvantages as well. When you implement the decorator pattern system will have lots of small small objects. So at some time it becomes hard to understand and debunk the system. But with a proper understanding of the core, I mean we can quickly do it. But that's a kind of an easy advantageous scenario like when we implement decorator pattern. So starting with the strategy pattern. The strategy patterns are just keeping the implementation of each of the algorithms in a separate class. Each such algorithm encapsulated in a separate class is referred to as a strategy. And the object that uses a strategy object is referred to as an index object. The strategy object must be designed to offer the same interface. So this can be achieved by implementing a common interface or by using the subclass of a common set class. Let's see a simple example for this strategy pattern. So for reaching an airport there exist several options like reaching it via city bus, personal car or taxi. So that this mode of profiles can be used interchangeably and can be decided on the basis of cost, convenience and time. Beaver of a class should not be inherited. Instead they should be encapsulated using interface. So let's take an example of car class. In car we are having two common feature behaviors that are accelerate and brake. Since accelerate and brake can be implemented in different models, so a common method of implementing is like implementing it in the subclass. But the disadvantage of that is while implementing it in the subclass if we implemented it across multiple models then we have to duplicate the code and make a lot of changes in the code. This one is the UML diagram and here we are using the sort method for that using the comparator interface. So what comparator interface is doing is it is using the id comparator or the date comparator on the basis of the elements. Like if the element is of an integer it can use the id comparator for sorting the elements or if the elements are a date then it can make a use of date comparator. In Drupal 8 translation interface is using the strategy pattern. So the translation manager and the cross translation both are implementing a translation interface and the translation interface returns the translated string using the translation markup and that way it is using a strategy pattern. Coming to a facade pattern it is a structure pattern because it deals with how code should be structured and it can be made tangible so that it can be maintained in long term. A facade pattern shields the user from the complex detail source system and provides a simplified view which is easy to use. Object that provides a simplified interface to a larger quantity of code we can take here as an example of a library. So in case of a library we are having a set of different components and the facade can provide a convenient method for accessing the common components that way a library can be made easily and understand. It defines a unified high level interface to a subsystem but lets the subclasses decide when to instantiate it. Now consumer calls a customer representative and the customer gets access of facade like by fulfilling the order through order fulfillment department, billing department and the shipping department. So it is working as a facade as it is doing a multiple procedures facade has no new end constructor with the type entered parameters in case if we need a new instance we can use the factory as an object now here we are in the facade we are having the turn on and turn off as a method and that is been implemented using the bios interface and the OS interface. So if we see in the bios interface we are having the execute, wait for, pre-paste, launch and the power down methods so like it is containing the multiple methods so in that case the facade pattern is used basically when we need to perform multiple operations through a single interface. Factory method pattern is a creation pattern. It defines a runtime interface for creating an object but lets the subclasses decide which class to instantiate it is known as virtual transcript because it defines the interface for creating an object but lets the subclass decide the type of it. So a simple example of this would be the hotel. So when staying in a hotel like first we visit the friend desk and the person sitting at the friend desk will give us a key to our room so that way he can act as a room factory now while staying in the hotel we need to make a call and we call the friend desk person and he connects us to a person where we need to make a call so that way he can be looked as a phone call factory as well a simplified way of creating a factory method pattern is creating an abstract class or an interface that declares the factory method and different subclasses can implement the factory method in its entirety another common approach of it is create a concrete class with default implementation for factory method in it so that way different subclasses can overwrite the factory method with different strategy implementation so factory method pattern has benefit and drawback both the benefit of using it it implements the separation between the application and the family of classes so that way it is easier to extend the family of classes without making major changes in the code. The drawback of this pattern since it can be implemented only for the family of objects and it intends a private constructor so we cannot use it if the best class needs to be extended and this is a simple diagram the factory method pattern. Let's take the unil diagram of this one. So here we are taking the example of a desktop application and in the desktop application we have operations such as like creating, opening and saving a document and let's say for drawing document we need to have a two factory method class and there can be drawing document class and the drawing application class it will be a task of drawing application class to manage the operations such as creating a document or opening a documents and drawing document class would do what would do is it will create an instance whenever the library instantiates. Here the problem is if we do not implement the factory method pattern here then for every application we need to make a different instances and in the user registration block is using the factory method pattern. It is implementing a container phase for returning an instance of a user registration block and that way it is returning the plugin for that. Coming to a abstract factory pattern it is again a creational pattern. It determines the actual type of concrete object in KAC but it returns an abstract counter to the created object. Let's take a simple example. If we need to provide a data access to or to different data sources, for example SQL database and XML file, we would have a data access class containing the method that would be common for both of those. So that can be done by implementing an interface that would be a common method for loading or like the later operation. Other way, data access class would be making a call for the data sources which shouldn't affect the way from which data sources, means we do not need to duplicate the code. If we do not duplicate the code for both of the data sources, abstract factory pattern declares only an interface of creating the product but it is the task of concrete class to actually create the product for it. Here we are taking an example of the GUI framework so here we can have a different look and feel themes like here we have used the windows theme and the motif theme. So that can have a different behavior or the different look and feel for the controls like the button in the edit box. In order to write the hard coding for each of the look and feel what we can do is create a common factory class that will implement the common methods. So let's say for windows theme we can create a windows look and feel abstract class and for the motif theme we can use the motif look and feel. It is implementing a common interface for containing the methods that are implemented by both of them. So it reduces the duplication of the code. Sometimes there are situations when the single instance of an object is sufficient in the application there comes the situation where we can use the singleton pattern. The singleton pattern ensures that only one instance of an object exists during the lifetime of an application and it provides a global point of access to an object so that the object is able to access the global point without any disturbance. So in this event we are considering a static member private constructor and a public static method get instance. So the get instance method ensures that it returns the instance if the instance is not already created and if it is already present then returns the same instance. So it ensures that we do not create more than one instance of a class. In Rupert we have example of safe markup class that is implementing a kind of singleton pattern but it is not acting as pure singleton pattern. What safe markup class is doing is it is writing the sanitization of a screen by using the escape and the get all methods but it can be looked as a singleton pattern but it is not purely a singleton pattern. There comes certain advantages as well because singleton pattern it provides the controlled access to a certain instance. So we have a strict control over how and when client accesses the object. Reduce name space when using the global variable it ensures that it do not pollutes the name space when it selects the global variable name. Some common example of singleton pattern are logger classes and the configuration classes. Logger classes are the one which are defined in the application for any logging access point. So it ensures that whenever the logging of object is done it returns the same instance without creating any new instance for the same. Similarly with the configuration classes it returns the configuration parameter for an application without generating the new again. That's all about the patterns and equations. So any questions? What's your favorite design pattern? My favorite is decorator. Because I use it a lot. decorator is my favorite because every time I use a database statement I see it in action. What was your first design pattern? What was that? The factor method pattern defines the runtime interface for creating an object. It is used quickly. Do you think that knowing the design patterns is essential to be able to manipulate? We are using all of them at certain places. In the project most of the design patterns are already used. What is the real-time example of the singleton pattern? Our database connection is not in the Drupal scenario. Why Drupal we are not using the singleton pattern? Because it is considered as an anti-pattern. Sorry? Singleton pattern is considered as an anti-pattern. Singleton patterns allow us to create only one object. No one will want kind of implementation where you can create only one object. It is desirable to use it. You mean form using form API? Yes. Basically, the API is various form altars and all the books use a visitor pattern. In traditional Drupal, it is a function oriented. I am not sure if defining form uses any pattern. I am not sure. When you write any form,