How Do I Escape From Here?

There was a point in time when object-oriented programming was either to adapt or to perish. It adapted. Probably the most dramatic change was in how we started to view encapsulation.
Still, there is a lot of code even today written in the best - or worst! - tradition of the 1990s. Why is that?
This video will teach you once and for all the techniques we use in modern programming to encapsulate the state and operations. Learn to evade that tar pit created by the old coding style.
Download source code ► / zoranhorvat
Join Discord server with topics on C# ► codinghelmet.com/go/discord
Enroll course Beginning Object-Oriented Programming with C# ► codinghelmet.com/go/beginning...
Subscribe ► / @zoran-horvat
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
👨 About Me 👨
Hi, I’m Zoran, I have more than 20 years of experience as a software developer, architect, team lead, and more. I have been programming in C# since its inception in the early 2000s. Since 2017 I have started publishing professional video courses at Pluralsight and Udemy and by this point, there are over 100 hours of the highest-quality videos you can watch on those platforms. On my TH-cam channel, you can find shorter video forms focused on clarifying practical issues in coding, design, and architecture of .NET applications.❤️
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⚡️COPYRIGHT NOTICE:
The Copyright Laws of the United States recognize a “fair use” of copyrighted content. Section 107 of the U.S. Copyright Act states: “Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our youtube channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s), but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above.

[@ScrotoTBaggins]

You have mutated my state of mind suggesting my brain is not encapsulated which is very concerning.

[@adambickford8720]

I remember people advocating *against* adding generics to java collections because it would encourage people to break encapsulation/abstraction. "You shouldn't have a `Collection` of playing cards, you should have a `Deck` to encapsulate that!". And of course, that must be true for all 'collections' of things and you need to judiciously expose what the grouping can do.
Despite what you've been promised not all encapsulation is good, it's a tool with tradeoffs.

[@zoran-horvat]

@@adambickford8720 Agreed.

[@stefan-d.grigorescu]

What about starting with generic ReadOnly collections?
And, in case of state mutating designs, only expose as few mutating methods as necessary for the requirements, but let callers read current state as they want

[@adambickford8720]

@@stefan-d.grigorescu We call those arrays ;)
Kidding aside, the entire premise of collections is a mutable, resizeable container. 20+ years in and java still has no concept of a read only collection (hell, we just got ordered and unique interfaces!)
What you are describing is nothing like how OO was sold or practiced years ago when this advice was the standard. But why stop there? Instead of mutating, just always return a new instance.

[@stefan-d.grigorescu]

@@adambickford8720 try C#. There, we have ReadOnly lists and dictionaries. You can extend the classes or implemement their interfaces. This is really powerful. You can, for example, implement flyweight pattern (if the contained type is immutable)
It's worth playing around with these

[@logantcooper6]

Im going to have to watch this one more than once to fully grasp the concept. Thanks for putting out this content that really stretches me and makes me think!

[@TheHegi]

Long time viewers at the beginning of the video: ohh, I see where this is going...
At the end of the video: how did I missed soo many details...
Meticulous work, as always. Thank you!

[@figloalds]

I mean, I hate encapsulation, but this really changes my perspective a bit, because it's still encapsulation, but it's just not compound, so it removes a lot of redundance, I love it
But also, I tend to prefer anemic models, because in a lot of cases the anemic models with "all public get/set" are REALLY handy for serialization and avoids the creation of many viewmodels and the mapping between model and view model, but I struggle a bit with because it loses encapsulation entirely

[@Michael.SMarsh]

I'm surprised you didn't make Release's AdvanceToNext immutable as well.

[@zoran-horvat]

@@Michael.SMarsh I could, but I wanted to show the interplay of mutable and immutable classes. That is an important concept in design.

[@allinvanguard]

Great ideas! Would you say that extension methods (or soon, properties) would also be an option here in order to reduce the cognitive load of your initial design, as a middle ground between a bloated data class and a completely clean "value" class design? It would provide an option to organize the operations in more digestible parts

[@zoran-horvat]

@@allinvanguard Yes, that is always an option, but only provided that encapsulation is not done in the way that jeopardizes the containing class, as my initial design did.

[@fluffydoggo]

It would be nice to see a new abstract list type that lets us do validation for adding new items so I dont have to write the same wrapper class of a List.
Also at 2:00, I would prefer to return an IReadOnlyCollection using List.AsReadOnly so the caller of the Authors property cant cast the result back to a list and mutate it

[@vatyunga]

I'm not sure about this. Interfaces tell the intended usage, and I'm not sure if it's necessary to protect it from casting. I mean you could always break something with reflection and we're not worried about that.

[@zoran-horvat]

@@vatyunga I agree with that. I don't worry about casting when doing the design. Returning IReadOnlyCollection now fixes the interface forever, potentially limiting some future decisions.

[@fluffydoggo]

@@zoran-horvat thats why I chose IReadOnlyCollection instead of one of the more concrete collection interfaces.

[@krss6256]

Thanks for the video. Could you please also make a video on how this refactoring translates to entity type configurations?

[@zoran-horvat]

@@krss6256 Yes, I plan to do some videos about persistence, too.

[@tore28]

Injecting IEdition via the constructor is standard dependency injection. You control in the IoC container if that injected object is either a singleton or scoped object, i.e. can have multiple instances. I am not sure what the gains of chainging the interface IEdition to return itself in the AdvanceToNext method instead of void. But returning void should be avoided in functional design.

[@zoran-horvat]

@@tore28 The accent in this video is on encapsulation. Whatever the way of injecting the object, that object becomes a liability if it is mutable independently of the containing object, and simultaneously bound by the containing object's invariants. In the shortest: such an object is a walking bug.

[@nickbarton3191]

Book, Books, Author, Authors, seems normal to me.
Immutability also facilitates chaining; I've got it everywhere, Point, Vector, Vectors.

[@LordErnie]

Isn't the promoting of composition and immutability something that leans more towards functional programming?

[@zoran-horvat]

Don't forget that composition was a big thing during the 1990s when it had literally saved OOP from destruction. The growth in complexity of online businesses was so rapid that prior practices based on inheritance could not sustain it any longer. That was the time when OOP as we know it today first appeared.

[@imranhussain8700]

Beginner Level
Intermediate Level
Advance Level
Z(Zoran) Level😢😢😢😢😢

[@miikavihersaari3104]

OOP adds a lot of unnecessary complexity that has nothing to do with computation and solving the actual problem. I understand it can seem like its useful in large enterprise projects where certain things need to be enforced, such as privateness of fields and immutability of public fields. Virtual methods and runtime polymorphism makes modularity effortless, but code complexity increases and understandability suffers as well as performance. A simple mechanism is always easier to debug and understand than a complicated one.

[@zoran-horvat]

@@miikavihersaari3104 There is no simple mechanism in a business application because a business already brings the complexity in. It's there. You cannot just remove the intrinsic complexity by selecting one coding style over another, though I hear fairy tales about doing so almost daily.
Funny enough, nobody has ever shown me the code that is simple in a complex domain. I only hear the stories.

[@miikavihersaari3104]

@@zoran-horvat I completely agree with that, although I wasn't suggesting that intrinsic complexity could be reduced by a coding style. I was talking about added unnecessary complexity, which goes on top of the intrinsic complexity. Now you need to deal with two domains instead of one.
But yes, you cannot simplify a problem below its fundamental level of complexity without leaving something fundamental out.

[@miikavihersaari3104]

@@zoran-horvat One more thing I'd like to point out is the perspective of constraints. Choosing to adhere to the SOLID principles or choosing to construct your program from GoF design patters brings with it a non-trivial set of constraints, which is added to the set of constraints that already come from the business. So you're effectively narrowing the space of all possible programs, which also forces you to take longer paths than you could take without the constraints. When the constraints coming from the business are especially difficult, the additional constraints coming from arbitrary principle choices aren't helping or supporting the work of constructing a solution.
Also, many of the GoF design patterns exist only because of the constraints of OOP, not because of computing itself.
What are your thoughts on these?

[@zoran-horvat]

@@miikavihersaari3104 Patterns and practices are meant to constrain the design to the safe and useful area, effectively ruling out typical mistakes. You can see the same forces at work with functional programming. Every functional program is an object-oriented program, but not vice versa. When viewed that way, you see that applying FP practices effectively removes certain OOP habits - those that proved over and again as the source of troubles.

[@miikavihersaari3104]

@@zoran-horvat Design patterns are meant to offer a common design language for software engineers to communicate and understand the parts and components of their solutions, but using design patterns also increases complexity, which makes it more difficult to understand a program. So there is a sense in which the idea is against itself.
There are widely used practices and principles that are not necessarily very useful and don't result in safer software, for example SOLID principles. The goal of SOLID is to make software easier to understand, maintain and change, but there is no simple metric to prove that SOLID in fact achieves this. One thing can be proven, though, and that is that SOLID results in drastically less performance.
I think all of this is an important larger topic that should be respectfully discussed more often in the software industry. Exchanging ideas and looking at many different perspectives has the potential to yield improvements and gain truly valuable insight.

[@AnNguyen-tommy]

Em like đầu tiên nha thầy

[@johnhershberg5915]

I find this video a bit weird. It starts off being about encapsulation, but you end with a complaint not against encapsulation but against mutability. You changed Edition to be immutable. But you're not explaining WHY it's better for Edition to be immutable here. To me (as a noob wanting to learn) this makes very little sense. Why constantly return new objects that have to be garbage collected just for the sake of immutability? Especially in this case where Edition is private anyway. There's no chance of a consumer of Release to overwrite it.
So it's very much not clear what advantages your refactor from Edition being mutable to immutable gives you

[@zoran-horvat]

@@johnhershberg5915 I think I did explain. I said how exactly the mutable variant leads to a bug prior to turning it immutable.
BTW forget about garbage collection. You don't ask a hundred other questions about CPU architecture, buses, memory access, cores, hardware controllers and a myriad other things, so why such fixation on garbage collection.

[@johnhershberg5915]

@@zoran-horvat As someone working in games the GC is something I'm always aware of. If I arbitrarily create objects like that I'm guaranteed to get hickups when the GC has to fully clean them. I've been changing my code to be more functional/oop hybrid and your videos have been a great resource! So I thank you.
As far as the bug you're showing, it's the Author not necessarily being in the correct culture. But I don't see what this has to do with immutability. The AdvanceToNext method that does the mutation actually seems fine to me. I don't see an issue with mutating Edition. So I think this video would benefit from an extra 30 seconds showing a potential bug with Edition being mutable

[@zoran-horvat]

@@johnhershberg5915 Why complain about the immutable design and then say "as someone working in games"? You could've said as someone developing embedded systems; as someone in the mobile development... whatever. Learn to form a proper sentence as an engineer: prerequisites-analysis-conclusion. Why do so many programmers start their posts from the conclusion and present it as an absolute?
If you said in game development - immutable design triggers frequent garbage collection - causing flickering, I would just say: yes.
When you say immutable design causes garbage collection, you leave me no other options but to point out that it is how it works by design, there is nothing wrong with it, and maybe to suggest you to go out and play.

[@johnhershberg5915]

@@zoran-horvat I wasn't complaining about immutable design, in fact I use it a lot more now that I've learned it from you.
My goal here is to learn what class of bugs you're avoiding by introducing immutability in this particular case. Because if I understood that then I could apply it to my own work.
This isn't a criticism of you or your content. Just pointing out something that's unclear to me about this video

[@zoran-horvat]

@@johnhershberg5915 There is the part of the video just before turning that interface immutable where I have pointed the bug that can happen otherwise. It is actually one of the greatest design flaws of OOD in general, which can only be solved in OOP by mercilessly cloning every single object, which nobody does. People just try to pay attention and hope for the best.