Dependency Injection with Spring4D

hello good morning good afternoon good evening wherever you are in the world this is Nick Hodges the director of engineering at Embarcadero and I'm here today to talk to you about dependency injection in Delphi my contact information is there for your use if you want to talk to me and let's get started so the code for this talk can be found at the following bitly link di in Delphi so if you want to download the code or any other code some of the code that I've shown particularly the file of your application that we'll look at at the end of the presentation you can do that so what is dependency injection well dependency injection is really a 25 year old term for a 10 cent concept it's something that's very very powerful but very very simple dependency injection is really just the notion of asking for your dependencies don't create them simply ask for them from another entity that creates them for you imagine you had a house that you were looking at buying and it didn't have any plugs in it everything was hardwired into it all the appliances all the lights all this everything was hardwired into the wall with no plugs this would be a house without dependency injection because it would be a house that had no interfaces for the electricity throughout the house and without that electrical plug to plug in items you lose a lot of functionality a lot of capability to and a lot of flexibility to change things from one to another you need to unplug your vacuum cleaner to move it from room to room you would want it hard-coded hard-coded you wouldn't want it hardwired into a wall socket in the basement so a house with no plugs is like a house without dependency injection so what is dependency injection mark semen in his book dependency injection net says as this software a set of software design principles and patterns that enable us to develop loosely coupled code and that is really all it's about is developing loosely coupled now loosely coupled code is good so dependency injection is just a means of creating loosely coupled code it is not merely the use of a dependency injection container as many people think you can do dependency injection without ever touching a dependency injection container and in fact we will do a lot of dependency injection in our demo demos before we ever touch the container so since it creates loosely coupled code your question might be why would you want that well because loosely coupled code is all kinds of goodness if this is your class diagram then you have heavily coupled code so a couple code is really bad in that it's hard to maintain it's hard to update it's hard to change you make it will change in one area and it affects the performance or the functionality and a completely different area uncoupled or loosely coupled code you can't have completely uncoupled code you want loosely coupled code is good because it allows you to easily and quickly isolate errors to switch and in implementations if need be any number of all of good things come out of having loosely coupled to code so if you're going to do dependency injection and you want to avoid dependencies you have to wonder what is a dependency well a dependency is anything that a class needs to do its job so for instance tea class a is said to be dependent on tea class B when you can't compile tea class a without tea Class B in other words if you just created a simple console application put that unit in there for tea Class A and it also pulled in and compiled tea Class B because of piling tea Class A then they're dependent on each other and dependents are created when you actually well create one you call create on an object in delphi in your application you create a dependency and once you call create you are stuck with that object that you've created you can't change it easily to use a different implementation you can't easily update that code you can't easily maintain that code code that has dependencies is difficult to maintain so here's an example of creating a dependency here we've got a widget class with a method called send widget an internal it to it it creates a widget sender class calls the method on the widget Center class and then frees the widget sender now this is fairly normal code and you're probably thinking hey I write code like this all the time well what you've done here is you've created a dependency on the tee widget sender class if you write a better implementation tee widget sender or you need a different implementation of tee widget sender you are stuck with this particular tee widgets under you're going to have to create a new one plug it in right code and you're connected to it as well we don't know what happens when we call send widget we don't care but sometimes it may be connected to other things throughout the code that you don't want to be connected to so creating tee widget sender creates a dependency and the dependency injection is all about removing dependencies so what are some basic rules to follow for dependency injection a first rule is code against interfaces or abstractions programmed to an interface not an implementation this was first made famous by the Dingell for book the design patterns book written by angle for Erich gamma in particular is the one of tributed to whom this quote is attributed and this is probably one of the single most important things I would try and teach a new software developer is to program to an interface not an implementation now rule number two is keep your constructor logic very simple if your constructor is doing more than straight assignments you're probably not doing right you're probably creating and putting logic into your constructor for a reason that is not good so here we have a tea order processor calling the constructor and we're passing in two parameters a order validator and a order entry and we're assigning them to the internal fields that hold those values and that's all the constructor does if your constructor has an if statement in it you probably need to split that constructor into two halves two classes two new classes if your constructor has any kind of logic in it then you need to find a new place for that logic constructor logic should be very simple should be simple assignments where number three is don't actually create anything don't actually construct anything delegate the task of creation to objects whose specific job it is to do that whether it be a factory or a dependency injection container you should as a general rule avoid constructing anything now we'll talk a little bit later about what some of the types of classes that you will want to construct but as a general rule if you wrote the class yourself don't construct it use a some type of object creator some type of factory or a dependency injection container to create it for you in other words I want you to use constructor injection as much as possible I want you to inject a class's dependencies into that class through the constructor so there are three types of injection I talked about constructor injection a moment ago we'll talk about it here a little more thoroughly here's a perfect example of constructor injection you've got a class called a fruit grow tea fruit Grove it's got a constructor that takes a tea fruit or an eye fruit picker interface it stores that interface locally in the F fruit picker field and then when it was time comes time to pick the fruit the fruit picker dot pick fruit method is called here's a beautiful this is a beautiful example of constructor injection the constructor declares to the world hey I need a knife root picker it doesn't say how the eye fruit picker should be implemented it just says it needs an eye fruit picker and that is something that you must capaz to the class in order for the class to do it you don't want to create the tea fruit picker inside the constructor because then you'll be stuck with that one particular fruit picker here we're programming to an interface against an eye fruit picker and we're passing it into the constructor as a required field for the class to do its work properly you should use constructor injection to it as I said to Clara classes required dependencies this should be the primary way of doing dependency injection a class has a set of requirements as a set of dependencies hopefully I'm only one or two maybe three but if it gets past that then you should think about breaking that class into more sub classes or some sort of smaller classes not sub classes and those dependencies that you inject through the constructor should be required dependencies for the class next kind of injection will look at is property injection here we have a ninja star interface that has a procedure on it throw and we don't necessarily want to create a ninja with a throwing star because every ninja has a sword that's required as we can see by the constructor but the ninja star is injected as a property and set as a property in order to allow you to vary what kind of ninja star you throw but allow you to provide any type of it from the implementation for that ninja star and you can inject that dependency the ninja star dependency via the property value by setting a property after construction that's property injection you should use property injection declare optional dependencies for a class that is dependencies that a class doesn't necessarily need but might want and it's normal for you to provide a default implementation of that optional dependency it can be a totally functional is dependent dependency so there's no no values in your in your code and you can simply create that dependency as a function list object in your class here's Method injection at work again we've got a ninja start a ninja sword we have a ninja who takes the sword as a required dependency through the constructor but there's a procedure called throw ninja star that takes a single ninja star as a implementation and interface and eye Ninja and star interface as a parameter in the method throw ninja star and presumably you would use to some kind of code that actually would throw call the throw method on the ninja star interface use method injection when the dependency will very frequently or when the dependency needs to be disposed of after each use so in the case of our ninja star there may be any number of ninja star types for point eight five point two twenty pointed whatever types of ninja stars that you want to throw and you don't want to have to manage all of those as dependencies on in the constructor when you want to just throw a star right away so you can use Method injection to pass in any type of star ninja star that you want so that is a varying dependency you use Method injection now I said earlier don't create anything that's not entirely true like kind of I didn't lie to you but I encourage you to not create things unless they are what we call or might refer to as a creative all creatable is a class that you should be creating manually that is something like t string list and RTL or utility classes inside of the libraries that you use that are non-volatile they don't change they are firmly fixed in your code they don't bury and they don't need to be used or should be used inside of a container or passed around as dependencies now an injectable class is a class that you should be asking for through dependency injection there are classes that you've written as part of a business logic they're usually volatile they're changing they're all their properties changed and run time things like that basically classes that you write yourself should be injected classes that are part of the library should not be injected there creatable z' should be able to create them and injectables are things that you should inject so what are the benefits of dependency injection I'll run through this quickly first maintainability application that uses dependency injection and proper dependency injection is highly maintainable mainly because each individual class is separate from each other it doesn't cause errors changing making a change in one class doesn't cause changes to other classes in the property in the application highly maintainable as a benefit classes are very testable when they're loosely coupled if they depend on dependencies that are handed to them you can hand the maca dependencies instead of regular dependencies and test the classes in isolation as you should be doing with unit testing dependency injection makes for a very readable code classes are simple and small they generally will follow the single responsibility principle if you're coding well and so your code is easy to read in each individual class is a simple straightforward thing classes are also very flexible dependency injection allows them to be used in multiple ways and reused in ways that are that you might not conceive of it it's a time that you write them so a dependency injection lets your classes and your application be very flexible you can easily replace a given implementation with another implementation and you can do that on the fly you can do that at design time whenever you want dependency injection based applications are also extensible because it's easy to instead because it's easy to inject required functionality it's very easy to inject something new or to inject something a new implementation that enables you to extend and the capabilities of your class of your class in your application dependency injection also allows for parallel development what do I mean by that what I mean is that to you two groups can be working on a project before either group is done with the project because of what you can do is you can just declare an interface and then code to that interface and give the other team that interface for your service and they can code against that service knowing that sometime in the future your service will be implemented so it allows for teams to work together much more efficiently because once you define an interface you can code against an interface without actually having an implementation of it so you can code against the interface before the interface is actually implemented so let's talk a little bit about the a dependency injection container finally I've mentioned it a number of times eventually if you keep pushing back the creation of your objects that is you continually push objects to be created at the composition root of your application your composition root will get really busy what I mean by this is as follows let's say you have a class that has a dependency class a has a dependency on class B so you pass an interface to a type I class a I'm sorry I Class B to Class A well at some point that object has to be created so if you continually passing back the information the creation of objects you're continually pushing them back pushing it back pushing it back you'll eventually get to the composition root which in delphi applications is can be either the DPR file or sometimes the main form create main form creation out of the on create event or the constructor of the form your main form so that's the place where all the creation and the connections between the classes and the dependency injection constructor dependency constructor injection takes place so at that point there should be a whole bunch of things to be created and we'll see this in the demo so we need a solution for creating all these objects painlessly and without a mess and that is the dependency injection container a dependency injection container is the thing is is a container that takes on the task of creating objects for you you can do it automatically on-the-fly when a dependency is recognized by the container as being needed by another class that's been registered with the container so the dependency injection is a very powerful Factory for creating tasks and objects for you it should create every object that you need that are injectables it shouldn't create create a pose but any object which is deemed injectable should be created by the dependency injection container and luckily Delphi has a very powerful very capable dependency injection container as part of the spring 4d framework you can find it at spring Ferdie doe org it's maintained by Stephan Glinka who has done a great job maintaining it the Delphi container spring for Delphi container can create objects it can implement interfaces and it can manage the object lifetimes other lifetimes of those objects that you do create so it's very powerful so a container can to manage injection for you it can automatically do constructor injection and property injection you can use attributes to declare that something should be injected you can allow for custom constructors to be called by a delegate to call and you can manage the lifetimes of the objects by calling as singleton or as per thread things like that enabling you to manage the lifetime object of the objects lifetime management is done well at creation point the default is transient meaning that it's created and you are responsible for freeing it you can also call a singleton singleton per thread you can pool your objects if you want to if you have a pool of objects you can do any number of things you can even implement your own lifetime manager by implementing these hi lifetime manager class interface with a class ok enough slides let's go take a look at some code ok for code we're going to take a look at two applications one is a very simple application that demonstrates very simply how you can take an application that is highly coupled and decoupled it and then the second one will be more of a real world example of File Viewer from my book dependency injection in delphi so this first application here is called starting out and that's because we're starting out with dependency injection and it just does something very simple it processes an order so if we go look at the T order processor you notice it creates an order creates an order processor calls process order passing in the order and then writes order successfully processed frees everything up no big deal the order processor is the place where the real money hits the road rubber hits the road money doesn't hit the road rubber hits the road and it's the place where we actually create the form of form valid order validator and an order entry system the orders valid by the order validator then we go ahead and enter into the database and the order might say the order has been processed an order is just a simple class that there's nothing in order validator is just a class that returns true if the order is not nil and an up order entry is again just something it returns and returns true if the order is not nil and writes out to the console no big deal but again the real money is made in this order processor call here this process order class now this application is very highly coupled to these two classes order validator and order entry if I wanted to for instance test this class to order processor I couldn't really use unit tests because I would have to call the real order validator in the real tea order entry classes and I'm trying to get a mock class into this class would be very difficult because it doesn't use constructor injection well let's fix that so I'll take a order order validate or of type T order validate or as well as an a order entry type T order order entry like so and I'm highly meticulous so I do that then we grab this to copy it up to here and instead of creating these classes now we've passed them in a order validator and the order entry gets a order entry like so now this all works fine with one exception of course now that when I construct this thing I've got to pass in and order validator and order entry so we'll simply go over T order validate or an OE t order entry like so we will create them as needed here or create the order entry now order entry gets T order oops gotta line up can't have your code out of whack to our entry dot create like so now once we create them of course we need to free them and will o be free and yeah free like so and this should work and it does okay so now we've moved the creation back one level let's move it back even further let's do this let's take a order let's be a little more efficient about it let's go to the order processor let's take this copy it go dealer to processor take it there let's grab these things here and we'll actually take them back to the very beginning here and put them here like this and we're just pushing this creation all the way back to the equity root of the application a composite root of the application and no II like so and then of course now we have to go to do order processing and make sure that this is also part of the declaration so that we can then if we try and run this we'll just move this whole use a statement up here like so and that should all line up then we'll go back to here and we'll pass in oh we need to pass in order validator and order entry like so and save everything this should work and we run it and we get an error because we should go try Oh Oh ease out free Oh weed free and we need to go back over here and take that out actually take this try out like so and now it should run and it does baboom okay so now you'll notice that we've got the constructor constructor of this all the way back to the very beginning of this application it's right in the composite root it's in the DPR file we can't push the construction back any further but we're not doing something that I said we should be doing and that is coding against interfaces so I'm going to create a unit I'm going to add a unit that it's already existing called EU interfaces and I'm going to have these classes implement these interfaces so order validator for instance should just simply interface object implement I order validator like so and then order entry it should t interface object comma I order entry like so so now those classes need to know nothing more there our interfaces excuse me and we can come back here to the do order processor play the location we can get rid of these declarations we don't need them anymore we can change this so that it takes this as a entry and this actually should have done this earlier shouldn't I yes I should have liked so whoops I got order validator order validator order entry make sure this compiles and it all compiles that's good see if it runs runs and that's good but now we want a code against these interfaces so basically what I want to do is I want to change this interface change all these two interfaces interface changes to an interface and now you'll notice something really cool you'll notice that because I can use the new interfaces unit here to get rid of the squigglies there I don't need to use these two units anymore I don't actually have to couple myself even to the units that declare what an order validator and order entry class implementation is are excuse me so it doesn't matter I could just take it and go against the interfaces and now you'll notice that this unit doesn't even depend on those other classes in the implementations units so now let the compiler tell me where my errors are and the compiler is going to tell me that a order validator and a order entry are not the right thing that this constructor is expecting so again we'll make the constructor expect in interfaces like so we'll remove again decouple the two units by removing their declarations like so this becomes an eye order validator this becomes an eye order entry same with this down here so now we're coding against interfaces let the compiler find any errors that exist and we can run it and we get an error because we're not passing interfaces here we don't need to try finally anymore because we're passing interfaces like so and everything's an interface now and everything should be decoupled and we run it and it works so now we've got ourselves in a situation where the let's go back to the good old order processor and you'll notice that this order processor doesn't know anything about anything except interfaces doesn't know anything about how to process order validators it doesn't know anything about anything except interfaces notice the unit just uses the orders unit which won't worry about the orders class and the interfaces unit and that's it that's all it uses same with order validator a loader validator just uses the unit interfaces order entry just uses the user interfaces entry that's it so if we go back to the root of the application you'll notice that these constructors here are at the root of the application now this is a very simple application you can imagine a complex application that was done the same way there would be tons and tons of calls to create here that need to get passed into procedures that get sent out to do multiple things excuse me so this creation stack here could kind of get not so pretty well let's use a to use a dependency injection container to take care of the creation these objects for us so we will add a unit that I've got prepared already so we have this you know it's called you register stuff and you're not gonna believe this but what it does is it register stuff okay so we've got a register stuff we pass it a container of type tea container and tea container is the type in the spring container unit that is the container or the dependency injection container that we're going to use and let's see I've also added a little code here to create the container so could you create it culture I and of course because of course we have two container free when we're done but that's one constructor that's good to do because we're right there in the root of the program so it can create things if we want to now let's hold off on talking about this registry just a second and do a couple more things to make our application even more dependency injection oriented let's go to a tea order processor and let's make tea order processor an interface interfaced object and it's going to implement I order processor like so and if I go to I order processor the order is constant so it's not going to compile if I don't change this Const here and Const here let's make sure that compiles yeah compilers your best friend when trying to figure out whether your code isn't syntax is correct well won't tell your codes crack they'll tell you your syntax is correct did you get the idea let the compiler find your errors when you're doing this kind of thing is kind of refactoring so now the to order processor gets created in the do order processing event and we want to create an eye order processor instead of a tea order processor and now we don't have to free it like so because it's an interface and we refactor it like so now the I order processor it was being used instead of the tea order processor okay so the next thing we're gonna do is there's do order processing call in fact doesn't need these two parameters all it's going to need is a single order processor which is of type I order processor all right and now we don't even need this reference here because we are going to use we're going to take this line I'm gonna take it copy it actually I'm gonna exit out and we're gonna use a order processor as the or processing of orders so now we'll go back we're continually pushing in the product continually in the process of pushing our construction back to where we want to go so you want to register stuff the due order processor doesn't take an order validator an order enter anymore it simply takes an order processor so we don't need these two anymore like so and we go oh P equals container dot result I order processor like so okay we run it and we realized that we forgot to change the implementation declaration like so and we run it and we don't need this over to processor anymore and we run it and it all runs now shouldn't notice something very very curious going on and no time throughout the process well first let's look at the register stuff as I promised here I we have a container and I take the container and I'm gonna say look I'm going to register a type with a container type I'm registering as theater processor and that tea order processor implements I order processor its name if I order entry our tea order entry and I order validator and tea order validator and what this does is it tells the container that when I have an i order processor appear create up a new team new order process for me and pass it in return so you'll notice that that's what happens here we call resolve I order processor so I resolve the I order processor to return me an instance of an implementation of opie or i order processor right and it passes that order processor into the I order processor do processor order class there as it has her function excuse me as as it's always done but you'll notice that the tea order processor class doesn't actually create or in no place in the entire application in your code anyway are these I order are these were to validate order entry class is created and that's because they're automatically created by the container when needed the container I register the tea order processor class with a container the container looks at that tea order processor class and it says hey this constructor needs an eye order validator I know about I Oliver validator I know how to create one and it needs an ID or entry I know about I order and sure I know how to create one and it does it automatically for you inside the container so you never have to worry about even creating your own stuff at all all you do is have the container created for you automatically and that's the beauty of dependency injection is that now we have an application or the order in order units all by itself the order validator is completely decoupled this is a very testable class right you can pass in fake orders the only thing it knows about is the I order validator interface the order entry is the same way and then order processor which if you recall was the class at the very beginning that was very highly coupled is now coupled to nothing more than a bunch of interfaces the container does all the work of creating everything you need you could make a single call to the Container resolve like so called do order processing passing in the order processor which has been properly created and has been properly instantiated with the order validator an order entry that it needs because the container knows how to do that and the code will work as expected but you'll notice again that this code is all now complete it's very very loosely coupled really the only coupling takes place inside this unit with these uses clauses here which connect up the interfaces with the classes that implement them and that is a well contained little unit where the coupling takes place otherwise all your classes are standalone classes that know how to do one thing one thing only and they magically create all the code all the classes that you need when you need them by a via the container okay so run a little short on time so I'm going to quickly take a look at the file display or application that again is part of the Doug the my dependency injection and Delphi book which you can purchase at lien pub comm so this application is pretty straightforward it does one thing and one thing only and that is display files it'll display any file bit mat this is the list of files that it knows how to display so for instance if I grab my title cover of my book and knows how to display the picture that's the cover of my book if I know how to if I grab a PNG file and knows how to show a PNG file if I grab a just a random file that doesn't know about it prints information that it can grab about that file like so it can print text files XML files any kind of file it one it'll display basic information about it now this application is completely modular and completely decoupled so let's close all the other pages here and take a look at this application first let's look at the main form it just consists of a panel a couple of buttons and a list box if we go to the code you will see that there's not a lot of code here in the form matter of fact there's almost none the first thing is though it does create a container and registers the interfaces to the container and that registers a bunch of displayers the displayers are classes that know how to display specific types of files and you can create and add your own displayers if you want to because it's totally modularized and I suddenly realized that I create the container open oh I do free time sorry I freed in the destructor of the form form destroy event I just simply put all the extensions into the list box that you know what kind of files you can look up and here's where the real money hits the road again register interfaces takes a container registers a tea file displayer as implementing the eye tea panel tea display on panel ops the I display on panel interface same goes true for file extension getter and filename getter and here's where we have a bunch of displayers a text file display and a picture display er that know how to register and display these specific kinds of gifts and P and G's and BM bitmaps and JPEGs and whatnot like so so that's where all the registration occurs the money is made again with this single resolve call here which sets up the file display and now the father displayer is ready to do its business and the only thing you ever have to do is display on panel it's called display on panel and pass it the panel that you're displaying whatever file it is that the file display er wants to display so if you click on the button only thing that happens is you call fire to file display er display on panel and you pass it a panel that's it that's all that happens in the main form and again that's a very simple decoupled solution because all the rest of the work is done in all these other classes that are completely decoupled from the main form and from each other so for instance here's the notion of a file display it implements the eye display on panel interface and you create an addition you get you could pass in an eye file named getter and an a file extension getter and it goes off and it gets a file name by calling the file extension getter get extension and the filename getter get file name once it does that it displays the calls of this player and gets it a display and just displays it by its extension and the men displays the file name in a given panel this class is completely standalone it only depends on a unit called F file display interfaces which is probably pretty familiar it looks the same as the one from the last deck example this is a simple display registry which we use to just hold on to these lists of extensions and displayers which will display that extension by of the I display file interface by the way it's just a glorified dictionary that manages that the frame extension getter simply gets the extension from a given file name the file name getter prompts for file name and prompt for file name is a call inside of ECL dialog so it just prompts you for a file name that's all it does and it sends the results back in the in the function sent fills the result with the value that you pick and that's it it just returns that value picture displayers again here is a picture display err there's a text file display err that creates a memo and aligns it to the parent and puts it on there and you'll notice that all of these classes really depend on nothing other than this interface unit and so the classes are completely decoupled they're completely separate from each other they're all testable those are all easily manageable and it's hard to make a change in one that will affect any other class because you simply are just interconnected by other interfaces remember it's the registration this reservation function where all the coupling takes place and this is a safe closed loop if you will of coupling that make sure that everything gets registered and automatically created you'll notice that I don't create for instance the file getter in extensions because the T file displayer class knows about about that No there we go and so we have a working functioning application that you can take a look at in the source code that comes with this talk in my book my book explains all of this probably better than I did in this presentation I hope and I hope that looks better anyway I should say and we have an application that is a functioning real application it can easily be extended by creating new implementations of I display file then you could register extensions against those new I display files no big deal very easy to manage very easy to do so let's jump back to the slides so here's some other resources I've mentioned my book a couple of times it's called dependency injection and Delphi you can get it at lean pub right now and the soft copies will be available soon on Amazon and create space and another good book is Mark Siemens dependency dependency injection and dotnet it is very thorough and deep in discussion the dependency injection of as well but it is all dotnet I recommend my book of course but mark book is very good as well so thank you and now it is time for questions great Thank You Nick so Stefan's asks or Stephens asking if there's a good introduction to using interfaces coding in Delphi by Nick Hodge it has a pretty good introduction into them and there's a lot of you a lot of information on the internet as well is about using them probably a good source would be to study dr. Bob's work on it with the cell if you type in interface segregation principle that'll tell you about a lot about how to use interfaces properly if you search on google for interfacing interface segregation principle is P that's part of the solid coding sol ID coding net printables Uncle Bob or dr. Bob all right dr. Mann Uncle Bob's more well known for that dr. Bob may have stuff on it too but he may but yeah yeah Uncle Bob's got some good stuff on solid in your book coding Adelphi put a link to that that's a good place as well thank you take a look at 3-play yes great mark sorry I missed you joined late I guess you missed the audio problems oh so that's probably maybe I have to a question you register all creation of objects in the container what if the constructor requires more than other objects maybe pass an integer valuables values or numerators or something else you know that's an excellent question I didn't get time related to cover that in the demonstration that I gave there is a way to do that with its called register you can register a factory class too that matches the signature of your of your constructor and then that teaches the container how to create something with a specific factory signature and of course you can read about it in the book there's a demo of doing that yeah I have I don't have the third one yet I need to get the third one but I have the other two very good books I hear lots of good feedback from others I always I tend to get I will admit very fanboy so happy he's look to see if other people also agree with with my opinions before I repeat them because I just case I've heard back from the peoples on your books well I appreciate that very much thank you sure I was just I got around 3 by 3 and I was just playing with it so a little does are fun yeah I got Android in running on it and Adelphi app connected and running and yeah I son that our Facebook just don't work really nicely okay any other questions since I did a great job of explaining everything so there's no questions as usual yeah so what's the difference between coding in delphi and more coding in delphi so what's curious where to start should they start with rake the regular first one and then go to the more coding at delphi or well that's what I'd recommend yeah I read the first one read the second one the second one is just more of the same kind of thing that you got in coding in Delphi the second one covers oh gosh hang on let me grab one I just look guy here says patterns threading parallel programming aspect oriented programming which is a really cool topic I'm a big fan of and solid code is in more coding in Delphi yep so that's what what you get I guess thank you and the first one here there it is generics interfaces which Stefan was asking about exception handling anonymous methods collections are TTI runtime type information in numerators attributes dependency injection which you just talked about today and unit testing but your new one dependency injection Delphi goes into way more detail I take it than me it does and I learned quite a bit about there's I shouldn't say well I have learned but there's been a lot of advances in dependency injection since I wrote the book originally so a lot of different few points a lot of different ways of looking at things that are better and more more better more faster more cheaper and now in the first one as well you talk about unit testing leave it in the mock objects encoding in Delphi as well I believe there's a chapter in there on narcotics this has been so long since I looked at this thing yes testing with an isolation framework isolation framework is the proper term for you what it is commonly referred to as a mock framework but there's more to it than just mocks as you will just learn when you read the chapter 14 encoding and Delphi now the does your new book going to isolation frameworks Lawler's are purely about dependency injection it's purely about dependency injection doesn't talk about unit testing or mock so stubs or anything like that that's one of the my understanding least one of the big advantages of properly loosely coupled code and dependency injection is that it makes it very easy to test yes that's tired yeah I never did you was gonna say my head with unit testing long time ago is I was like everything's so coupled I can't test anything and now it's like oh that's because I was doing it wrong yeah if it's hard to test you're doing it wrong does the book also cover abstract classes I saw Delphi supports those as well right you know I discussed that very briefly about abstract classes I used interfaces throughout the book you can use abstract classes as an abstraction certainly stress coating against an abstraction if that's an abstract class that will work just as well as an interface yep their abstract classes and inheritance are one way of doing things I think interfaces is more flexible more elegant in my opinion it took me a while to get to that opinion too it depends on your taste yeah some people you know don't really like what do you call it they don't like abstract classes some people don't like interfaces some people prefer abstract classes both will work just as well and after classes actually have some advantages one is that you can add functionality to that base object class that descends down through the other classes and then then that is an advantage that you can't get with interfaces but the book covers abstract classes very briefly and deals with interfaces throughout yeah so let's see where's the set so we just there's a questionnaire about mvvm and we just did this phenomenal session on advanced coding practices I'm trying to find one replay for it here with Daniel 8 Itay and he did the camp with this framework called the Columbus egg which he showed this to me and it's just like wow this is amazing and essentially what you do is you you have all your code your data access objects in a data module and then you use the Columbus egg framework and it creates an mvvm as it completely decouples your form from your data access layer I handle all of this is called the Columbus egg yeah Columbus egg by Danielle hey Tay I'm gonna have to look at that that sounds cool but he sure the smell like oh my goodness this is exactly it because everything I've seen before about Google in the VM has always been like will you write all the codes from scratch and that's what I like about Delphi is I don't have to write all this plumbing code from scratch and this just makes it all work beautifully where's find it why can't I not find it he did it so you did a webinar with this on here we go and so son get on it yep yeah he did a he's got a couple books out as well and a training training based on those books and all sorts of great great glad to hear that that's delightful hope to look at that closer today Chrissy he should have a blog post that has the recent post he's apparently a very prolific blogger but yeah this is really good stuff here if I can find it no not find it okay but each time it was on github so yeah I just search for Columbus egg Delphi and it came up yeah on github but he did a webinar with us on modern Delphi architectures and so actually it's a Daniel github.com / Daniel Teti Daniela Teti / Columbus egg or number 4 Adelphi John right there yeah so yeah check that out if you're wanting to do mvvm awesome awesome stuff there or I'm not sure if it's MVM or in the mvvm or MVC or whatever but it's that idea of decoupling your data access layer from your that's a terrific idea oh yeah hey somebody put it into questions there yeah yeah and it does the thing I love about it is it lets you do it all without having to write all that plumbing code yourself one doesn't like to write plumbing code if one doesn't have to exactly I learned that even though Delphi spoils me I don't have to write code I've learned it's ok to write code when I need to but yeah that's review the library yep yep so very cool stuff fantastic Nick thank you for your time and for all the you're welcome very welcome thanks everybody for joining us for this and thanks everybody appreciate it preciate you sticking around and we'll see you all online later bye alright

Channel: Embarcadero Technologies

Views: 7,176

Rating: 4.9058824 out of 5

Keywords: Embarcadero

Id: j9qvJiDz7ME

Length: 59min 55sec (3595 seconds)

Published: Mon Apr 17 2017