Use Incremental Coding Technique and Make No Bugs in Complex Features

[@StephaneAmStrong]

Awesome explanation! The incremental coding technique is a game-changer for tackling complex features with fewer bugs. Super practical tips-thanks for sharing!

[@eugene-the-duckovich]

Damn, watching this felt like a big revelation

[@L0wPressure]

I don't use C# but all you're saying can be generally applied to any language, and i enjoy your explanations and way of thinking. Thanks for the content!

[@nickbarton3191]

That first step was beautiful, all the other files turned from red to green in an instant.

[@rustamhajiyev]

Really like that you demonstrate multiple techniques/solutions using the same code but approaching to the problem from different angles. Love your "intro"s 👍😂

[@XXnickles]

Used to watch your courses in Pluralsight; glad to see you are around and keep expanding in these functional principles using the newer language features. I also use the record inherence as a replacement of discriminated unions (the wait will be long for what it seems) Subscribing!

[@ivandrofly]

Nothing to say other than thank you :D - you are the missing person I was looking for on KZbin :D

[@loupiz]

Finally someone who fills the gap between C# and domain design on KZbin. @Zoran Horvat I'have started watching your videos they are great, thank you. I'm definitely not an expert of Blazor but it would be nice to use a pattern to prevent modifying the _CitationPartial.cshtml file each time a new segment type is added to the application (perhaps having a list of views where you can add new ones whenever segment types are added).

[@zoran-horvat]

If you watched my video on discriminated unions, then you will see that the problem you have outlined is the signature of functional modeling - adding a new type to the set of related types is a breaking change to all the consumers, UI included. I think that trying to fix that is a lost cause, for many practical reasons.

[@loupiz]

@@zoran-horvat I get a bit confused with discriminated unions I must say. To me they tend to violate the open/closed principle. I would be interested to hear your thoughts on that.

[@zoran-horvat]

@@loupiz OCP does not apply to DU - it is a concept from object-oriented programming, while discriminated unions are the modeling tool from functional programming. Actually, they achieve their greatest power by breaking OCP - the ability to define behavior where it belongs, rather than where the types are defined. You can watch the video on discriminated unions to get a better grasp of how they help in design: kzbin.info/www/bejne/p5DXeWakn9V0fMU

[@amarsha4]

@loupiz I thought the same thing. I'm from a purely OOP background so this seemed suboptimal to me. I'll have to watch some of Zoran's functional programming videos.

[@davidghydeable]

You can actually do this. In you view you call . Then you create partial views corresponding to the class names of each segment type. You will also need to create a partial view for the base type even though this will never actually be used. .NET seems to need it to be there.

[@noopcode]

So The Vision decided to retire from being an Avenger and became a programming guru instead? Excelent video Mr Horvat

[@ivandrofly]

Video-mark: 2:45 - string

[@handlez411]

I have a question... Every video breaks my head. Is there a way to learn C# your way? Does Patreon have a section where we can start from the beginning to relearn programming?

[@zoran-horvat]

@@handlez411 No, but I have the course on Udemy called Beginning Object-Oriented Programing with C#.

[@temp50]

I have a feeling that you either didn't see soo much ugly (a.k.a. very smart) code or just elegantly skipped this little potential problem. :P Just an example: You said that just by exchanging the string to an other type wont'be a breaking change. The reality is that every time someone expecting that property to be a string via Reflection / lazy loading by exact type matching, or via any other type of magic.. , it could be a breaking change at runtime! So, step 0: Reverse engineer the whole application and try to find all of these things before changing anything.

[@zoran-horvat]

You are advocating precisely the mistake I have tried to expose in this video. There is no problem in identifying all the places that depend on string, but attempting to do anything with that would be a catastrophic error in a large project. If you ever sent a PR with 100 changed files, I would reject your work as a certainty, because you would not be able to explain what makes the resulting code correct. Now back to the beginning: Can you introduce a seam in code so that only a few files change, and each in only a few lines? If you can, then you have my attention.

[@AK-vx4dy]

Almost Smalltalk 😉

[@jonny.rubber]

And put all strings into Const.c 😂

[@aprobinda]

13:57 This runtime type information looks like a violation of LSP: `if (segment is BookTitleSegment book)` because foreach references the base class CitationSegment but has to know about its subtype. What do you think about this @zoran-horvat? Excellent video with useful content, by the way, I enjoyed watching it. Thank you for the time you invested into it.

[@zoran-horvat]

The portion of code you are referring to is a pattern matching expression typical of functional code. The types pertaining to CitationSegment are effectively functional types, rather than object-oriented classes. I would strongly advise you to watch the videos where I have addressed that technique, primarily this one: kzbin.info/www/bejne/p5DXeWakn9V0fMU

[@aprobinda]

@@zoran-horvat thank you for clarifying. Having watched the recommended video, I see why LSP does not apply, but more importantly, I learned about a new approach.