Factory Design Pattern in Kotlin 

Really enjoyed the episode! Would like to see more of such episodes on patters. That's useful!

Enjoyed this more than I initially expected. Nicely done and edited. Thanks for uploading!

Really enjoyed the episode! Would like to see more of such episodes with coding and discussion over it.

Nice to listen to the experienced people. Just have read book about design pattern and i would be very happy to see more episodes about them. Thanks guys.

Great episode! The transition to abstract factory was masterful. More please 😊

Hope to see more of this

Nice one - I’d love to see more on design patterns on this channel. Great topic for a series / playlist.

Not sure how others think about this (so please comment what you think), but I think there is more to the Factory Method (or Factory Function / Factory Lambda) pattern than just the use some method/function/lambda to map one type to another. I think what's part of the classical pattern, which is missing here, is that you declare an abstract (possibly default) function in some super entity, e.g. an interface. E.g. `interface GameLoader { fun loadGame(notation: List): List }`. That really lets you vary the `GameLoader` implementation at the call site, without the call site changing. Just having some top-level function mapping strings to pieces isn't really the classical Factory Function pattern, right? That's like calling a type alias equivalent to a type defined from a class or interface. Simply because the signature matches of a random different function that maps strings to pieces, it doesn't mean that it is a Factory Function pattern, because you can plug it in at the call site. There might be different use cases for mapping strings to pieces that do not load a game. Likewise, defining it in the companion object of the source or target type, or just as an extension, is equally flawed: there is no way to vary implementations of the function without actually using the classical pattern, where some interface/super class declared the Factory Function. So: consider wrapping the function in some interface an implementing different variants as implementations. Yes, I know: that is introducing classic OOP boilerplate. But it _does_ provide the type safety that the implementor _must_ inherit from `GameLoader` and that you can only use `GameLoader` instances throughout your code. That is completely omitted in this video. What do you think about that? I do agree that the Static Factory Function (mentioned in the video) is a simpler version of the Factory Function, but they're not the same.

The extension function is fantastic to implement the static factory pattern when you don't want the Piece class to have knowledge of more complex classes or you want to separate the application module into "layers" and you want a piece out of a class that doesn't belong to ita layer

Thanks for this kind of videos, pure gold

Interesting take on if-else vs when. I only use if-else when it fits in a one-line expression, otherwise I go the when route.

very nice intro to thinkings on factory methods. I very much liked the iteration to the final method. Just enough on items to point out nicities of Kotlin. Thanks.

Good Professor Bruegge. I did also very enjoy his lecture.

Can you do the builder pattren next pleaaase

Good job guys! Great content!

Love to see one on the visitors patter

Awesome epsiode as usual

I bought your book, but I am little confused. You describe "builder" pattern, but it isn't a real builder pattern. It is just simple "assembler", without any concrete builders or engineer. There wasn't event any mention, that it is simplified version that is called "builder" by java community. If anyone plans to buy this - it is not bad, but it will be better to just stick with original Design Patterns, and translate those patterns to Kotlin yourself

Thank you for this.

operator fun invoke(notation: String): Piece

Shouldn't it be drop(1) instead of drop(0)? And, do you think the following produces the same result as the first two statements of the method? val pieceType = name.first() val position = name.substring(1)

Nice talk as usual.

is there playlist contain all Alexey episode?

Dialog - excelent way to teach.

"We all are Chinese rooms." Thank you, now I know it's OK to feel this way sometimes! :)

Superclasses shouldn't know about subtypes though. Does it being sealed change things? How about it being in the companion?

love you guys I really like this episode

What are the use cases of fake constructors? They also serve as factory methods.

I really enjoyed it. 🌟

Greate episode

The example is a "factory" of some sort, but it misses the mark on the topic a bit. To me, a factory is an interface my code receives from the caller, and it abstracts away the creation of an object. I don't know the concrete class, but I do know the interface it implements, and the factory builds it for me. In the chess example, it would mean that the individual implementations of "Piece" were unknown within "fromNotation", and it would receive the notation as well as an interface that maps a piece letter to a corresponding object that implements Piece.

Thanks

You could talk also about some other structural patterns (abstract factory or factory method ..), also i'am not a fan of using the static factory method in the Piece itself, we should separate the creation of the system from using it, imagine another team wants only the piece, why they will take also the the factory Nice video thank you, waiting for the next one !

Quotes of great men: "Kotlin is easier than Scala, more type safety than Groovy and more fun than Java." 😁

Nice

хахах, красавчик)

10:55 JEP 427 goes brr

# I wrote a version with sealed interface and data class val notation = listOf("pa3","qc5") fun main() { val gameState = notation.map { Piece.fromNotation(it) } println(gameState) } sealed interface Piece { val position: String companion object { fun fromNotation(piece: String): Piece { val pieceType = piece[0] val position = piece.substring(1) return when (pieceType) { 'p' -> Pawn(position) 'q' -> Queen(position) else -> error("Unknown piece!") } } } } data class Pawn(override val position:String): Piece data class Queen(override val position:String): Piece

You are looking like indian actor(saif ali khan) 😁😊😊