 Sometimes we tend to put everything in one controller and then we discover that something is not working. So we try to understand what is this, how to use it. Especially it is important when you are migrating from Rupal 7 to Rupal 8 because in Rupal 7 controller there is not always a distinct entity, but in Rupal 8 it is there by default, but is that one we think we can name it controller or not? And yeah, if you can go to 2016, there is a presentation in Montreal regarding the object-oriented style used in Rupal 8 this presentation is a logical continuation. Controllers, as I told, is the same name but meaning different things in different environments. We know Gangl4 but 23 patterns, design patterns we are trying to use but then we know what exist such things like grasps, grasps and solids. What are these? Why those two and where controllers belong to every one of them or is just something in Gangl4 least or what is this? So the main difference is that Gangl4 are patterns that we can use for recurring problems. So you see a pattern here, right? The same butterfly starts here and ends here and actually this part is one pattern but you can call this part also a pattern this one also because only colors are different. Grasps and solids are principles so they are a little bit higher level than design patterns so those are true in general, let's say. You have to remember when you have troubles understanding how to do things to understand better we have the main project oriented principles those are hierarchy, obstruction, modularity and encapsulation. So encapsulation when you try to hide your logic inside a class modularity then there are principles of high cohesion and loosely coupling inheritance and aggregation a part of hierarchy and usually we are talking encapsulation and modularity when we are doing some classes and what is not exactly right because this is a real top level in object oriented programming and it was first done in 1991 and after that a lot of different principles and laws and design patterns appeared according to this. On the second level there are principles and here we have solid grasp and law of diameter principles maybe you know solid and grasp but law of diameter is telling that plus has to know what he is doing, his dependencies but plus should not know anything else about the system so it's kind of single entity and only after that already gang of 424 principles that we already start using practically in our work but regarding this 23 we have another 72 heuristic principles and heuristic method for way to do a class so when you are working practically doing some functionality inside the class you have to use gang of 4 and heuristics these principles but remember that you have to respect these two inside levels but a higher level and those are actually a must just to remember you what is grasp principle so is a general responsibility principle grasp solid you see the first capital letters explain what it is single responsibility open for extension closed for modification when we are talking about plus or method one interface shall be enough for a client that is substitution principle interface aggregation dependency inversion those are principle like we are learning them sometimes in the university and they have a couple of cases when during our presentation I remember we learned something in the university but now I see that we can use it in practical words and if you are really a person of 47 years old like in the previous slide maybe you are using those principles but name those principles differently so you know this one don't repeat yourself kiss principle right keep things simple stupid that's good favorite composition of inheritance is a couple of two these Hollywood principles is very easy to remember don't call us we will call you so your class should wait somebody will need this class she should not be active initiating something because usually initiating and events are part of front end you are back end so you have to sit and wait then somebody will call you and you will start reacting Hollywood principle is quite good principle to follow and this is a little bit verbose slide but this is the first time when in grasp general disability assignment software patents finally we see controller here so is a principle controller is a principle but we see controller also is in gang of four there are no controller that is named in heuristic 72 but in gang of four we have them but this is the main part that will explain you what is a controller I will talk more about controller and responsibility because if you look on the description of this grasp principle you see that every where there is this word responsibility right who is responsible for creation who will fulfill or collect the information who will assign responsibility for handling a system event who assigns responsibility but coupling remains low everywhere is this word responsibility so let's talk about it what is the responsibility is what an object or class is doing or knowing means you create an object doing the calculation you initiate an action or controlling activities in other objects but first you will receive a request from somewhere you know about encapsulated data because we are going through you when you delegate responsibility to some specialized class and the controller is holding the state he knows what comes from where and which is back state this is knowing reference to other objects because he has to know where to address becoming request how to get and calculate something so as such this is so called responsibility driven design contrast to what we hear data driven design so MVC model view controller is more about data driven design because then you start thinking about project inside MVC you start thinking about model which fields in the database will be there how different operations will be done and then slowly come from that side in grasp and then you want to use property controller what things are done is different you have to think about responsibility then something happened in the system and usually this is happened through UI client opened URL browser and there isn't event there take the client click on the form click on the link it's doing something that reaction will go to controller and controller sometimes he will do something as a response but usually the recommended way is when controller simply delegate the action that needs as a response to that event to some other specialized classes and just return the state that button on the front end or that link that was clicked from where it came and so on and so on so this part is important to understand and this part is responsibility driven design but not means data driven design is bad but means you have to include RDD in the framework you are using even but framework normally is MVC framework so controller delegate and knows but usually we try to not delegate to single controller too much responsibility means in this case controller will became bloated and this is already anti-partisan he has to delegate it to other objects and do not do too much work himself and when you are using model view controller view controller according to responsibility he has to know where the model is he has to know which events he is reacting and how to use the model in this case so the main two controllers are facade controllers and use case controller facade is usually a single controller in a small Drupal model for example and actually Drupal itself the interface is a facade controller so he is responding to the system events and we are using facade controller when not too many events to control the period in the system for example those usual events in Drupal are covered by the court so you don't care about them you are doing your own model and you are looking what kind of events are in your own model if there are not too much of them facade controller is a good choice facade is a dango 4 pattern so look there and use it use case controller is a thing that we switch to from facade controller when facade controller starts having high coupling already he starts depending of there is appear too much dependency of other classes there are some functionality inside your controller that make it unusable if some class is not working properly or fail or something so single responsibility principles became fuzzy in this case so it's a time to switch and I know Nick had a rule of thumb how many methods has to be in the controller when there is time already to create a new one so maybe we will talk about this but so there is a significant number of events maybe more than 7 no people like this number 7 so until 7 you are ok if more than 7 is time to create another controller but this state of the current scenario is a good way to hold it in your controller in a place where the state is remembered and used when events are coming in this part has to be remembered and used so it's a little bit about MVC MVC is kind of linear controller in the MVC user is seeing the view using the controller the controller reacts to model, model, update with view and user is seeing it so every time with multiple events you are kind of holding the same pattern the same circle and sometimes became difficult because your controller becomes bloated but you are using the single model and in grasp is a little bit different so look at this part every MVC controller is still kind of grasp controller because it is, for example, facade controller can be model view controller but other use case controllers are not MVC they are grasp controllers frankly speaking I was a little bit puzzled when I saw this first time but when I understand that according to business logics and use case for a specific event you can have your own MVC part of the program but are completely independent of our events and our MVC so you are multiplying controllers and multiplying models maybe or hold your models in different classes but multiple controllers will know where to address then the specific events come so for grasp we usually are using this type of language boundary objects are obstruction of the interface so you have some operations that have to be done users enter in the point of sale is reading the card or is pressing print or something like that so there are slope of operations entity objects are application independent means those entity objects are responding to specific events and control objects are those controllers and this is a controller button so UI receivers are not handlers but forms, widgets, view this is a presentation layer so then you press the button on the form it's not going directly to controller there are receivers somewhere it is included already in your framework or you are writing it yourself and this receiver already will interact with controller and here come the part that is a little bit fuzzy for all the developers because actually in grasp terms all of these are controllers handler is handling the event this is a controller controller itself and we see classes called manager, coordinator service, helper those are all class names for controller so when you see something like this in the class name look closely and this handler is really a controller maybe not a facade controller but one of the underlying controllers that will handle a specific flow a specific use case next question I was wondering if you were talking about Drupal because a lot of classes get named controller handler manager or if you're talking about object oriented design it is more about object oriented design but in Drupal, yeah, handlers are controllers when you are using inside your inside your own inside your own development your own development, yeah your own model yeah, they are like it is always there are like controllers and controllers handlers, this name it is not street but it is some rule of thumb and when you see some name okay, this is a controller yeah, so we will go now to the NIC area but finally you see a lot of example like this yeah, this is not a Drupal this is from the .NET something but there is user interface this user interface is interacting with the domain objects his own class but it is kind of working so you can tell this is a controller if you don't know exactly what we talk feel this moment because there is an interaction there there is an event and this event is directed to the specific class and yeah, this is the controller actually no, if you are looking properly, then things has to be done this way this is a real grasp and this is the way we are using controller and try to use specifically this way and then you can create a maintainable system and now is a little bit closer to Drupal you can open it ok we didn't use full screen before because it was some bugs not all pictures were shown and now it is like it is maybe yeah, all images are visible so now, ok does it? ok I don't see it all right yes, it is here ok, so this is an example from a real Drupal module this module is giving maintenance it is on-site Drupal work and it is one of few modules which were in a production state that means not anything, but in real production state from day one of Drupal 8 when Drupal 8 modules were appeared to be allowed in production state this module was there from day one and usually when we are talking from migration of modules also to Drupal 8, in fact that means almost to rewrite it completely but there is a more convenient way at least for us to transfer it to Drupal 7 to Drupal 8 and also use an object-oriented approach all this stuff like adapters, controllers, classes etc. so this module is simple enough you can find it on Drupal work and it is just presentation what is inside in Drupal 7 we have picture of like Drupal 7 in Drupal 8 we have some pieces like controller, form, which appeared in Drupal 8 what we did with Drupal 7 module, we put all stuff which is module specific into separate sub-folder module here and here after that when we put the object-oriented stuff and there will be many controllers I'll show you later we just moved this module folder to Drupal 8 shape of module and then adjust it a bit and done, it works so let us continue with this yes, so the very simple class config handler, if you see handler that means controller and because it handles just configuration it is use case controller so the use case of handling non-configuration we put into separate controller and if you see Drupal 7 class scheme and Drupal 8 class diagram, they are the same or called the same that means the same method, the same stuff and we just are calling these methods from mainstream as it was before in Drupal 7, now we do the same in Drupal 8 but when we'll see the code which is inside it is completely different because config handler, implementation this use case handler the method how to get or set this value in Drupal 7 it is regular variable get or variable set is it visible pieces of code or not very good I suppose that even if it is not very good it is sufficient because it is here at least very very simple pieces, so in Drupal 7 it is variable get, variable set in Drupal 8 it is like Drupal config etc but all these calls are encapsulated into this config handler into this controller backend class which for all main execution stream of module it is the same, so here are two advantages, first we don't need to rewrite every piece of module to replace this Drupal 7 start to Drupal 8 start and another advantage when we have all these calls in one place we rewrite it in one place, we are not jumping between different pieces of code it is everything here and it is quite similar here all variable get, variable set here is like a Drupal config and we have all here so what we have here we are encapsulated into this controller, simple use case for now use case is configuration and we smoothly move this piece of functionality from Drupal 7 to Drupal 8 now a bit more complex example, oh by the way if we see here in Drupal 7 we have default values, in Drupal 8 we have no default values there because they are in YAML file but ok it doesn't matter because anyway we have the same the same class diagram and we have the class and this piece of functionality this use case of handling configuration is the same for mainstream of module execution so we encapsulated all these differences and inside the mainstream of module of mainstream of execution we have no differences because they are all encapsulated inside this controller inside this handler now a bit more complex piece which illustrated the same principle we encapsulate some dp-handling pieces into separate set of classes as well why these dp-handling pieces we write separate classes but not use the main library for handling database because main library is handling database selecting search update delete and here are very specialized commands which are service specific and which are not data handling it is some maintenance of like a packing database and all this stuff so commands are quite different and we are handling them the same this module it handles MySQL server and PostgreSQL server and the initial version of module was always if MySQL do such and such if Postgre do such and such and these pieces of code were scattered everywhere in the module so what's to do is to collect all these pieces all common calls behind the same one dp-handling handler needs also controller this use case controller it is also use case it handles some special database calls which are not select search update delete but service database calls and this is dp-handling so now let's see yes for example the piece like list tables which are in the database this is call from mainstream and this call it doesn't know even whom is it talking to is it MySQL handling classes for MS SQL handling classes we just a YAC handler some handler we don't know what we just know that it produces list tables and after that we do this list tables so main execution stream of module it takes some object he doesn't know who is this but he does know that it supports the contract which interface is the contract that it can provide this list tables so we have here in this piece of dp-handling just optimize tables and list tables we put some common interface which has these two methods and after that we created two type of objects MySQL dp-handling which handles this for MySQL and pg-sql-handling which handles this for Postgres SQL so now let us imagine that we need to add Oracle or MS SQL or something else some other SQL server we don't need to rewrite whole module and whole execution cycle we need just to add one more handler which supports this interface which follows this interface after that all other mainstream will be the same so yes when we get this dp-server handler this dp-server handler so controller use case controller if dp-driver in dp-configuration is MySQL we provide you MySQL handler if pg-sql-pastgres-sql-handling if it would be for example MS-sql-MS-sql-handling so if you don't have it just unsupported dp-server exception so far so what we have we just put some particular controller we wrap it and we provide this controller to main execution stream of module via interface and after that main workflow it doesn't know who is it talking to particularly that's why this loose coupling that means that mainstream is unchanged when you need to add something you can add some other server you just need to write some small one class and done and all starts working with this please note the second line so this is the code in d7 and in d8 is the same no difference it is just we replace code from d7 put to d8 it just works immediately because it is properly encapsulated so that means not just programming but it is programming with fun comfortable easy and it just works and by the way one more piece here it is some small function called cast which returns dp server handler interface this small function it is just some PHP 3 which allows tag hint this new feature which started with PHP 5 and after that moved to PHP 7 to check the type during the execution and sometimes it is very handy because if we put something wrong it will tell us this type is not dp handler interface it is something else and it is much more specific that somewhere appeared somewhere and after that try to find here it explains everything so if it is dp handler interface it should run smoothly if it is not dp handler interface but some other class it will be notified immediately to avoid using an instance of to make this more specific explicit? yes because if we will take for example Cshark or Java the function here will be not public static function but it will be like public static dp handler interface functions such and such so in C++ Cshark Java here we can return type value and we can explain it here but here because in PHP because we cannot do it but we do can do this type in function parameters that is why we put it into function parameters and we return not just object but put it through cast after that we verify the type and we return type parameter or we will be immediately notified that something goes wrong and particular where it is where it goes wrong maybe after that you could probably also use instance off but the difference is people then have to throw the error yourself it's like PHP clears and throws the error for you yeah so I was thinking too so now in 7.2 you can specify return type or it's already in because I checked I was always looking for it because I do also a lot of programming in .NET and I really was missing it yeah it was a really recent addition I think it's 7.2 it might have been 7.1 oh 7.2 yeah yeah yeah because I checked pure 7 but maybe in 7.2 okay I'll definitely double check because anyway this is good working out but anyway it is working out it is explicit it would be much lesser because now what I see is that PHP becomes closer and closer to C sharp just remove dollar sign before variable replace error to dot and you have C sharp and vice versa I should have the method to create and migrate from D7 to D is take the model rewrite it in the object oriented style do the proper config and then copy and paste the business logic copy and paste works and it worked nicely here that was we were surprised that everything start working instantly just copy and paste every single class except because there is info here it's Yamafa the only difference and also there is one advantage of this gradually transferring the D7 to D8 first to rewrite it to object oriented style why because when we rewriting just D7 module regular way to D8 module we have just a big canyon to jump through because it doesn't work when we start to rewrite it but when we start to rewrite D7 module to object oriented style we rewrite it gradually so on every stage of rewriting we can check that module still works if it doesn't work return back and see what happened because this PSR 0, PSR 4 it is all available as separate modules in Drupal 7 and when it has been rewritten to complete object oriented style with this adapters, controllers etc after that we have something which is much more stable in time because we use not just Drupal 7 notation or Drupal 8 notation we use PHP natural object oriented notation which is not going to change a lot of from Drupal 7 to Drupal 8 Drupal 9 etc that's why it is convenient we gradually rewrite the module into object oriented style and we always ensure that it does work when it is completely rewritten by the way it was the same with this module Db maintenance 7 1 line it was regular D7 and 7 2 it is object oriented after that we just grab everything put it into 8 shape and we have Drupal 8.1 that's why it was one of the first yeah because of this simple approach so not only programming but programming comfortable and useful ok and thank you and question please another question obviously with question how do you support factory classes to the controller class are they a type of controller are they not if so or if not then why oh ok I see because it was factory class that you saw maybe it will be for another presentation after one year because first it was adaptive now it is controller yeah maybe always factory dependent injections all this stuff and also dependent injection we put some string because if we put some string after that we begin thinking why it doesn't work but when we do dependence injection we strongly type it is immediately work or doesn't work and it says why doesn't work maybe yes maybe it will be good idea about next presentation thank you and why factory method was here in factory because when we do object oriented programming we use a lot of methods simultaneously and we just pressing now one side or another side of this programming or third one so we showing this method piece by piece but in production module which is not example which is real production we use everything together thank you very good question actually this presentation was initially five to six hours because we tried this Drupal module, a great module that is automatically trying to do a great sound to it and we tried it multiple times so different results finally it came that our method works best and is faster and it give you understanding of the business logic quite good to do even the writing seven for seven is not waste of time because after that you will just cook and fix it after that it will be the same ability to copy and paste from eight to nine in the future big promise that will be easier did I hear from you though your presentation actually started to create your D8 style but still using B7 yes that means what does it mean D8 here we have some Drupal 8 shape using symphony using all this stuff this is like let me return back maybe oh oh ok it's gone already that's why I need ok maybe yes yes yes good that's what I need ok no vice-versa vice-versa yes here so this area like controller form is standard shape of Drupal 8 module and this shape has been done just for Drupal 8 with symphony with all this stuff but great background piece of Drupal 8 this is a PSR for object oriented inside so for making Drupal 7 PSR for object oriented we just install a separate module which allows this and after that it is in references to for example this DB maintenance and other modules so we install in separate module we have PSR 4 we have all object oriented style allowed in Drupal 7 and after that we start writing it in Drupal 7 it's style so we rewrite it and the advantage of this is that we start from working module not starting like from clear table from nothing the working module and we piece by piece gradually shifting it to object oriented style when we'll finish it it is already Drupal 8 style it is ready to move to Drupal 8 without rewriting with copy done about a year ago I got some help from module called X Auto Load yes yes this one X Auto Load yes so X Auto Load plus Drupal 7 yes you are right or inside Drupal 8 we have the same so X Auto Load yes so your path was fairly clean and there were too many obstacles once you wanted to go to D8 pretty you know what you were surprised as not too many obstacles because the path to Drupal 8 it is like two pieces one piece is Drupal 8 itself it is shape of Drupal 8 module and another piece it is our own module functionality which we cannot find in Drupal 7 and Drupal 8 because it is our so we need to rewrite it and a regular path it is to rewrite it in the Drupal 8 style that means mainly to rewrite the whole module but first what we do because it is object oriented encapsulation inheritance polymorphism let us try for example encapsulation so we encapsulate we hide in all specific functionality we put it all into one class this is like here sorry I need this page down yes we found for example all config functionality all config use case use case controller instead of direct calling config calls we introduce extra abstraction layer of this config handler which is controller class almost all problem in object oriented programming could be solved by adding extra abstraction layer except too many abstraction layers so here what we did the class diagram the class looks outside the same for Drupal 7 and Drupal 8 we went through the module we collected all this config functionality encapsulated into one class and made the class interface that means what is open to external users and now external user is stream of our module it is the same it is interesting as we were talking there are controllers because it is too common word here also there are interfaces and interfaces first interface it is interface and implementation implementation means what inside interface which is outside and interface as programming term yes it is like later we use this as well so here it is programming interface that's why on this config handler I was talking interface as not particular this interface but what is visible to outside consumers of this class and implementation is what inside and outside consumers doesn't see it like the car we have steering wheel brake, accelerator gas tap my wife doesn't know about last one so we have like this but inside it is very complex but we don't think about this interface but not implementation so here is the same we collect all functionality encapsulate it into classes which are quite common and after that we provide just as from Drupal 7 to Drupal 8 and because all functionality is encapsulated we are done and somewhere where this functionality is specific for Drupal 7 to Drupal 8 like in config we encapsulated everything and we had to rewrite yes we had to rewrite but just one class and all these pieces they are common it is the same just copy paste change name of parameters we don't need to travel through all modules and collect all there it is here on one page and there next it is like here interface it is a bit different meaning of interface which is interface in programming style but it also provides interfacing like in the first style like interface implementation but we do implementation here programming interfaces as well and because particular object is hidden behind the interface the mainstream even doesn't know whom is it talking to and it is very convenient because it is no scottling that means that in mainstream nowhere we don't have any MySQL or PGSQL specific piece of code that's why we put for example GibiHandler and we just give one one class and with that we are sure that all mainstream works ok thank you thank you very much