Unfortunately it is not possible to get the free month without giving skillshare a credit card up front. Something they don't advertise until they have your email. If only they could be honest, give a free monht, then force people to add a credit card when trial was over... But now, It's a no thank you from me. Not your fault though.

Yeah... that's standard practice for many subscription services nowadays. If you don't want to give companies access to your credit card, there are services (like privacy.com) that offer temporary credit card numbers you can destroy at any point in time. I haven't used these services myself, but I might in the future as I share some of your concerns.

Indeed! I always forget to use that. It would have been quite useful in this example.

Haha, I know the feeling :).

I'm in Australia, so I watch it in my morning with breakfast. My wife says that @ArjanCodes has a relaxing voice so she doesn't mind me nerding it out 😅

@@virtualraider yep I concur. ArjanCodes and coffee are a good Saturday morning here in Tasmania.

Glad to hear you like it, thanks!

Glad it was helpful!

Thank you! Glad you liked it!

Glad to hear the videos are helpful!

You’re welcome Cheeba!

Interesting... That could be the reason - I'm going to experiment with this, thanks :).

Great suggestion!

It looks like strategy has a time delay between setting and usage and commands are used immediately. If a dog is set to happy strategy, then later, commanding it to speak makes it bark. If the dog is set to scared strategy, then commanding it to speak makes it go "rut's sat, raggy?"

Just because the have similar sounding names or what? They really aren't similar at all. In the command pattern, you have a bunch of different operations that you are frequently executing throughout the application. Usually these commands have completely different interfaces. You take all these different operations, rewrite them so that they are invoked using objects that all implement a common "command" interface with an "execute" method. Each individual command still has to be created with its own interface, but instead of invoking the code directly you can at some later time call "execute" on the command object to run the code. Then rather than calling all the different objects directly, you write a "Controller" that you use to encapsulate the later execution of these methods. You can add any kind of code in the controller to do a number of things, like keep track of undo/redo lists, package the commands into batches if you want them executed transactionally, etc. In the strategy pattern, you have several chunks of code that do similar things and that you notice naturally already have the same interface that is being invoked in the same way. Or you have a chunk of code that you can identify a simple interface for, and you want to encapsulate it into its own object so that you can write other versions of it with that same interface. So you write a Context object that invokes the interface, and pull out the common bits of code that share that interface and encapsulate them in Strategy objects that all share the same interface. Then you pass the strategy object dynamically to the Context, usually at run-time. This allows you e.g. to select between different strategies at runtime without having to write multiple contexts invoking the same interface. Command objects usually all have very different interfaces and you know that you're creating them when you create them. The different interfaces are not abstracted away, instead you use the different interfaces when the different command objects are created, and then you simply call "execute" at a later time to invoke them. In the strategy case, the strategies explicitly have the same interface, you aren't creating strategy objects by using different interfaces, you are usually writing the strategies in code, but then at run time the contexts use the same interface to invoke any one of the strategies. In the example Arjan gave, the transactions all had different interfaces: a deposit and a withdrawal took just an account and an amount, but a transfer took a from account, a to account, and an amount. Withdrawal, deposit, and transfer were not three different strategies because they don't have the same interfaces. And the code he was writing wasn't deciding about whether to run a withdrawal, deposit, or transfer at runtime: he had to know which of each he was invoking as he wrote the code, but he invoked them all through a controller that deferred execution of the commands to some later point and managed their execution.

The TL:DR version: Command is about decoupling setup from execution as shown in this video. Strategy is about changing the behaviour of your code by swapping components in the code for others with the same interface. E.g. think of swapping the factory containing a tile set to create a level in a video game once you reach the next level.

also looking forward to seeing more demos accompanying TDD, i found myself difficult using TDD in my daily programming

The memento pattern is related to the usecase presented here, which is to revert an object to a previous state. However, it does this by storing the previous state directly though, instead of modifying the state back and forth like the Command objects are doing here. Mementos are useful to combat side-effects of redoing and undoing which cannot be completely reverted by a Command.

I suppose the correct thing would be for the batch command to reraise the ValueError after rolling back.

You got this!

Thanks, glad you like the videos! Yes, I cover all those topics in detail in the course.

Haha, yes I have to be careful 😊

Thank you Clemens, good suggestion!

Haha, that would be nice 😊.

@@ArjanCodes after bookkeeping for my sports club for 10 years I can only think on double entry. Where transactions are immutable and each contains two or more (account, amount) tuples with a total amount of zero.

Protocol classes in Python work with duck typing. There’s no need to inherit from a protocol class as Python will infer the type from the methods and properties that are present on the object you pass to a function or method.

Haha, yeah - I'm still figuring out the optimal settings for my camera, but I'm getting there!

That's likely from his use of the automatic code formatter called "black". VS Code allows you to define a code style engine such as black, autopep8, prettier, and others that will automatically enforce their style rules on your source code while you edit, or apply them across the entire document every time you save the file. Some people love these formatters, some people can't stand them.

Thanks for the tip!

Not really. I’m going to show what happens when you change the design to not store the state (account balance) at all but rely on the transaction history instead.

@@ArjanCodes Looking forward to that. I was thinking that if you want to store a large number of transactions in the history you would turn them into flyweights to save memory 🤔

I am bit on the fence about that, since it clashes with the single responsibility principle. Then the class would have 2 reasons for changing: when its logic changes and when it's dependency changes.

... assuming you don't have "lots of money" already.

This is a bizarre question. Of course his dataclasses have behavior: they're classes for crying out loud! It's even in the name: dataCLASS. If they were just containers for data with no behavior, he could use named tuples or lists or dicts or some other data container (although he may prefer using dataclasses even in that case, idk or care). But a dataclass is a *class*, i.e. an outline for objects that have both data and behavior. What characterizes them among other classes is that their objects require no special initialization apart from providing values to the fields. The assumption that your object's behavior and identity depends only on its fields, because there is no special initialization, gives you a lot of nice guarantees and enables you to build out all kinds of nice functionality in such a class for free with a bit of boilerplate. With Python, a lot of the boilerplate for that nice functionality is done for you with the dataclass decorator.

The main reason is that I find dataclasses help a lot in reducing boilerplate code, in particular writing class initializers and methods to convert an object into a string.