WEBVTT 00:00.440 --> 00:09.200 Okay, so finally, let's add the missing implementation for those abstract methods in a stripe processor 00:09.200 --> 00:10.280 class. 00:11.480 --> 00:14.780 And then the PayPal processor class. 00:15.080 --> 00:18.740 Now those are really dumb implementations. 00:18.740 --> 00:23.900 They just echo something so that we know that methods were called. 00:23.900 --> 00:32.120 And the actual implementation of those is not something that is bothering us right now. 00:32.150 --> 00:32.810 Okay. 00:32.840 --> 00:38.960 I think now we should see how we use all of those processor classes. 00:41.000 --> 00:47.720 So to illustrate those examples, we're going to create yet another class. 00:47.720 --> 00:50.840 But we are not going to write it on screen. 00:50.870 --> 00:59.250 I'm just gonna quickly make it from some building blocks using some of my editing magic. 01:00.510 --> 01:04.410 So the class in question is an order processor. 01:04.830 --> 01:11.490 So that's a class that is responsible for processing some user orders. 01:11.520 --> 01:15.090 Let's imagine that is an e-commerce system. 01:16.080 --> 01:24.030 So this order processor a part of performing its duties with regards to whatever needs to be done when 01:24.060 --> 01:25.260 order is made. 01:26.370 --> 01:30.240 It's going to accept a payment processor. 01:30.570 --> 01:38.910 So this means that the order processor can work with any of the payment processors that we have stripe, 01:38.910 --> 01:41.040 PayPal or cash. 01:41.880 --> 01:46.800 We additionally get a runtime polymorphism. 01:46.860 --> 01:53.940 So this means we can change the payment processor at Runtime. 01:54.780 --> 01:56.880 It doesn't have to be predefined. 01:57.000 --> 02:04.860 When you create an order processor, you can then choose maybe depending on some conditions or selected 02:04.860 --> 02:08.370 payment processor which one to use. 02:08.400 --> 02:12.090 Now generally this technique that we've seen here. 02:12.090 --> 02:21.150 So passing an object by constructor or through constructor this is important because this is called 02:21.150 --> 02:24.120 composition Teeths. 02:24.360 --> 02:27.240 Now it is a very important technique. 02:27.240 --> 02:36.360 And a lot of people a lot of software developers prefer composition over inheritance. 02:36.510 --> 02:45.450 This means that passing classes around that can have some specific functionality is preferred to extending 02:45.450 --> 02:51.940 base classes to add more functionality to the base class, and I agree with that. 02:52.090 --> 02:56.530 Now there are some obvious cases for inheritance. 02:56.560 --> 03:04.810 Like we've seen right here where we defined an abstract class which had some base functionality. 03:04.840 --> 03:07.630 Specific to online payment processor. 03:07.630 --> 03:10.270 But that's a specific case. 03:10.270 --> 03:13.150 And those specific cases. 03:13.180 --> 03:16.000 Make sense to use inheritance. 03:16.810 --> 03:22.300 But generally I also think and I agree with most developers. 03:22.330 --> 03:27.100 That you should heavily rely on composition. 03:27.190 --> 03:31.870 So passing around objects that provide certain functionality. 03:31.870 --> 03:34.930 And if additionally those. 03:34.960 --> 03:43.150 Objects implement interfaces, you've got much more benefits like loose coupling. 03:43.600 --> 03:46.660 That's another term you can remember. 03:46.660 --> 03:46.660 Member. 03:46.720 --> 03:54.730 This means that the order processor isn't really tightly coupled with any specific payment implementation. 03:54.730 --> 04:01.600 It can accept anything that can adhere to this specific interface contract. 04:01.600 --> 04:10.750 And additionally, composition gives you possibilities for easier testing because it will be much easier 04:10.750 --> 04:21.460 to unit test by providing mocks for this specific interface than creating or using some actual implementation. 04:21.460 --> 04:27.160 So we are doing some of the software engineering best practices in here. 04:28.870 --> 04:38.080 So next up this class is getting a process order method which needs to do something, whatever that 04:38.080 --> 04:38.680 is. 04:38.710 --> 04:40.690 We're not going to go into details. 04:40.690 --> 04:49.010 And finally it's using the past payment processor to process the payment, and it is logging whether 04:49.010 --> 04:51.260 this was a success or not. 04:51.260 --> 04:55.280 And this also gets a refund order method. 04:55.280 --> 04:59.450 So this is our order processor class. 05:00.260 --> 05:04.430 Now finally it's time to have a complete demo. 05:05.690 --> 05:08.900 So let's start with the stripe processor. 05:09.140 --> 05:11.660 Then let's add a PayPal processor. 05:11.660 --> 05:15.020 And finally let's create a cash processor. 05:15.050 --> 05:24.140 Then we are creating separate instances of an order processor class which have different payment processors. 05:24.140 --> 05:27.290 And finally let's process some orders. 05:27.830 --> 05:32.600 So if I run this now well we have an error somewhere. 05:32.870 --> 05:37.100 So stripe processing was fine as we see. 05:37.250 --> 05:43.790 But there was a fatal error invalid API key in line 27. 05:44.180 --> 05:49.100 That's an online payment processor for 150. 05:49.730 --> 05:52.580 So we do that with PayPal. 05:52.610 --> 05:58.370 So apparently I must have passed a key that's too long. 05:59.030 --> 06:05.180 So this is actually 34 characters. 06:05.750 --> 06:05.990 Okay. 06:06.020 --> 06:07.790 Let's quickly fix that. 06:08.150 --> 06:10.250 This should be 32 characters. 06:10.250 --> 06:14.480 That's what that was the requirement for PayPal processor. 06:17.300 --> 06:27.200 And now it seems like everything is fine because we get the messages from stripe, from PayPal and all 06:27.200 --> 06:30.740 the info that things were processed successfully. 06:31.910 --> 06:40.610 So whether this logic functions properly is not as important because that's basically dummy logic everywhere. 06:40.700 --> 06:46.790 And the last three videos were mostly about the software design. 06:46.790 --> 06:56.420 So about the interfaces and their purpose, about abstract classes and abstract methods and all those 06:56.450 --> 07:06.140 either design patterns or software engineering keywords that I think that a good developer should know 07:06.140 --> 07:14.570 or at least be a little bit familiar with, because in the future, if you'd like to work with any kind 07:14.570 --> 07:25.460 of a framework like Laravel or Symphony or any other PHP based software, you might and you will definitely 07:25.460 --> 07:33.050 will encounter all of those designs and keywords and best practices.