วีดีโอ

Hey, thank you so much, Yan! I appreciate that!

Thanks, Peter! Yeah - I had played with Chain of Responsibility implementations recently, but I wasn't as happy with my ideas for it at the time, so I moved on to other patterns. I'll pull up my notes for it and see if I can look at it with a fresh perspective!

Thanks, Fabiano! I'm glad it's resonating so well with everyone!

Thanks so much! I'll add that to my running list of video ideas!

Thanks so much, Mike! I really appreciate that!

Oh wow, that's really great to hear - really glad that you're picking it up so quickly! I'll keep at it!

Thanks so much, Tony! It sounds like the format is working well for everyone, so I'll keep at it!

Thanks, Mankin! Yes, that's a good point. I think also as you start getting more distance between each enum entry, they start to feel less optimal as a choice. With the 5-parameter constructor that I had at the end of the video, they started spreading out a bit, but at least they did all fit on a single screen. But like you said, if we were to add a few more entries, it could start to become more difficult to keep up with them!

Hey, thanks Zeynep! I'm glad you enjoyed it! 🙂

Thanks - I've had a lot of requests to show shortcuts lately! My keyboard shortcuts are very customized, but most people are particularly interested in how to edit with multiple carets, so I'm going to cover that at the upcoming livestream. 👍

Yes, thanks Arthur! I probably should have just done that in the video - I can't think of any reason not to make the interface sealed here. 👍

Yes, good thinking, Pavlo! 👍

Maybe the term "state" here is closer to the term "state machine" than "object state"

While working on this video, I did feel like there's a bit of irony in that these state objects hold literally no state of their own. Yes - we basically made a finite state machine, and that's the sense of the word being used here. Maybe the term "State Pattern" was more intuitive back when the GoF book was written (I was just a high school kid writing QBasic at that point), but I can definitely see how it could be a confusing term these days!

There certainly is something nice about having all that code line up like that! 🙂

Transitions should be as simple as swapping the instance of state in the context. Unsupported operations should probably fail with IllegalStateException, a convenient way to throw it is to call the "fun error(message: Any): Nothing" function from the Kotlin standard library.

You certainly can use a class if you like! Even in the GoF Design Patterns book, they mention a lot of flexibility in how you can implement this one. If you've got states that have no instance variables of their own, you might prefer to keep them as singletons, as we're doing here, to avoid the cost of instantiating the additional objects for each user - the book points out that when we do that, the states are also very similar to flyweights from the Flyweight Pattern. For cases where that's not as important - which, these days, might be most cases - you can just instantiate a new state object each time, which would clean up the function signatures (because you wouldn't have to pass the user object for each operation).

@@typealias thanks for explaining!

You want all of the design patterns in a single video? That might end up being a pretty long video! 🙂

@@typealias ofc not in single video. One design pattern per video is great

Haha, okay gotcha! I'll keep at it, then - only about 20 videos to go! 🙂 I actually might end up having to do a single round-up video for a few of the "leftover" patterns that wouldn't really warrant their own videos. Like - singleton wouldn't take too long to explain. And for some of the others, Kotlin doesn't add much. Anyway, thanks for clarifying!

@@typealias omfg this is my dream to see these videos! Thank you so much! Can't wait!

Well, adding another function would require us to revisit each of the state objects - I think that's what you're getting at. Even then, though, I would find it easier to manage the smaller, more focused functions that are grouped by state rather than large functions that are each trying to juggle different implementations for multiple states. (But if I'm misunderstanding your point, let me know!)

Ahhh, yes you're right! Thanks for catching that. Should be printing `it` instead. 😅

I also prefer typed parameters in lambda for other developer's sanity.

Explicitly writing the lambda parameters is always an option, of course. It all depends on the team's conventions, or in case of solo projects, the developer's preferences.

@@ArthurKhazbs Absolutely, you project your rules, but here we are educating people, it seems :) and when I see such in the code: `val editProfile: (String) -> Unit` - how am I supposed to understand what would be passed here? And in this case I see at least 2 solutions - either name it `(email: String) -> Unit` or use tiny type - `value class EmailAddress(val email: String)` - then its inferred in the type what will be passed.

Yeah! I almost never use semicolons... In this case, at a glance it looks like it might be part of the println() statement, so it'd be easy to miss what's happening!

Ah, thanks. I'm not this fast in real life. In most videos, I end up doing a bit of post-production work to smooth things out. In the next livestream, I'm planning to cover some tips about using multiple carets, which accounts for most of that shortcut game.

@@typealias it's a cool skill to have. I love intellij IDEs but for web I have to go to Vscode but have enabled intellij keybindings there

Well, with class delegation, we unfortunately can't change out the implementation at runtime. So whatever the implementation is at the time the class is instantiated, that's what it'll be for the life of the object. (Or did you have something in mind with property delegation rather than class delegation...?)

I appreciate it, Houssam! Thanks for being at the premiere!

Hey, thank you so much, Emmanuel - that's very kind of you to say! I haven't got any online courses just yet, but I'm planning to start working on them after I put the finishing touches on the book.

Thank you so much, Sergey! I'm glad there's been so much great interest in the topic. I'll keep at it!

Hey, that sounds great! Everyone starts somewhere, and you don't need a logic background to get going. As long as you've got an excitement about programming, and as long as you're willing to take time to learn things, you'll do fine. I'm almost done authoring a book about Kotlin, and my aim was to make it accessible, even to those without a programming background. You can read it online here: typealias.com/start/ I hope that helps you get started!

Yes, for developers who aren't already familiar with the approach, it can require some thought to figure it out. Ultimately, it's really just function composition using extension functions, where each Logger calls the previous in the chain until it gets to the underlying `consoleLogger`. So, the function created by withUniqueId() calls the function created by withThreadName(), which calls the function created by withDateTime(), which calls the function assigned to consoleLogger.