People are too eager to learn syntax and code...... but the "why" behind choices are not clear. You are giving clarity to the "why". Love your energy and presentation.

@ChristopherOkhravi

2 ай бұрын

Thank you for sharing your thoughts. Much appreciated. And thanks for watching 😊

@funkenjoyer

2 ай бұрын

it's pretty hard to learn about abstractions before having any chance at learning about the concrete stuff, even in math you dont start with algebra but you count on your fingers, once you have some idea on what you're dealing with and possibly have encountered a number of problems/issues then learning about the abstract concepts and patterns makes sense

My issue is that I often fall for coupling to distractions.

@ChristopherOkhravi

2 ай бұрын

Underrated comment 😆😆

@clamhammer2463

2 ай бұрын

I snorted

@dripcode2600

2 ай бұрын

Lol!

@bugtank

2 ай бұрын

my man

I missed you my man. I’ve grown quite a lot since your previous series.

@jsmunroe

2 ай бұрын

Keep growing. Get better and better and better. And most importantly have fun!

I'm so glad you're doing more content. Best simple explanations on compex topics.

@ChristopherOkhravi

2 ай бұрын

🙏🙏

The only thing is, please don't overengineer by defining an abstract interface when you only have one concrete type. All that does is obscure the names of your fields and methods unnecessarily and, by extension, what exactly it is each of them represents.

@adambickford8720

2 ай бұрын

100%. Nothing more obnoxious than a code base of 1:1 `IFoo` and `FooImpl` everywhere. "Just in case" isn't free.

@silberwolfSR71

2 ай бұрын

I agree that we should avoid over-engineering, but I don't think the number of concrete implementations should be the only thing we consider. Arguably just as important should be whether the type in question leaves our area of influence. If other modules/people/teams/products depend on our type, it can become quite unpleasant if that type is concrete and needs to change. Another thing to consider is that when other components depend on our type, and we want to test those components, we could argue that we have, in fact, more than 1 concrete type: the default, full implementation, and a stub we create to enable testing of the components that depend on it. I'm not sure how extracting an interface out of a concrete type obscures the names of its methods or what said methods represent. In fact it should communicate exactly that information precisely, while letting us ignore any unnecessary stuff like, for instance, names of fields (these should rarely be exposed to users of our type). In OOP, most types have behavior that defines them. If we share them around, we might as well explicitly declare that behavior in the form of a contract (interface) so that using the types is simple and consistent. One general exception are simple data objects that have no behavior: there's no need to hide those behind an interface, as there isn't much of a contract to speak of.

@adambickford8720

2 ай бұрын

@@silberwolfSR71 Every level of indirection has a cost, they don't all bring value and certainly not by just existing.

@silberwolfSR71

2 ай бұрын

@@adambickford8720I agree. I was trying to argue that the indirection of an extra interface can bring value even if there currently exists only one concrete implementation of said interface in the system. I also argued that the cost of this indirection is not as high as seems to be implied.

@jasonparker9957

2 ай бұрын

This comment should be pinned

I think one upside of having "always code to interfaces" as a rule of thumb is that it gives you an opportunity to stop and really think through the API of your component. It nudges you in the direction of creating useful abstractions rather than just code snippets. Of course, only sith deal in absolutes, and I think it's fine to sometimes code to plain old classes, especially if you did first think about extracting an interface and concluded that there's no value in doing so. To limit the "temptation" for other components to depend on this "raw" class, you can contain it using your language's component-level encapsulation facilities (e.g. make it package-private in Java). If you end up wanting to break that encapsulation, you might want to once again ask yourself if there's an abstraction asking to be born.

@AgodzillaFace98-yj5nq

2 ай бұрын

That's the problem with this approach - you stop and you think. Might seem like a good idea, but not in reality. You might feel like abstraction lord, but neither you nor other people would understand it, and the problem would still not be addressed at that point

@silberwolfSR71

2 ай бұрын

@@AgodzillaFace98-yj5nq I'm not completely sure what you're saying. My best guess is you claim that having to stop and think when _using_ your components is generally not good. If that is your point, I agree. We want to have neat components that are straight-forward to use and that have unsurprising behavior. I believe that having a think while designing them lends itself well to this goal. If you're instead implying that the act of thinking through the design of your components is inherently detrimental, as any solution you come up with is bound to be more complex and difficult to understand than your first impulse (e.g. a straight-forward class), then I disagree. Granted, at face value, class + interface seems more complicated than just class (though I'm skeptical of the difference in complexity warranting the claim that suddenly no one is able to understand the component). But ideally, only a very small number of components should care about both the interface and the class. For most components, all they care about is the interface, which I'll argue is much simpler than having to know about the full blown class and its implementation details. Moreover, one would hope that taking a moment to think will also steer you in the direction of the simple class, if that is in fact most appropriate for the given situation. If you don't believe that is the case, you should argue for _better_ thinking, not less. You say the problem would not be addressed by coding to interfaces. As I see it, there is more than one problem. One is a system that is difficult to change. Often this is the result of tight coupling between components, meaning if one component needs to change in order to meet changes in business requirements, many other components (that are not conceptually affected by the update in business rules) also need to change. Coding to interfaces, together with dependency injection, can help reduce this coupling, making change less painful. Say you have a few dozen components spread over several different modules that all depend on class C to do some work. Now your requirements state that for the components in one of the modules M, C should have different behavior. What you would likely do at this point, is create a new class C2 that functions in this new way, and then modify all the components of M that depended on C to use the new C2. If the components depended on an interface IC instead, none of the components would need to change, you'd simply wire up your dependencies in such a way that all components of M now get a C2 instead of a C. M's components shouldn't have to care that the IC they're getting is behaving differently, as long as it still adheres to the contract of an IC. Another problem is testability. If a component X depends on a class C, it is difficult to test X in isolation, because you can't substitute a dummy for C (without relying on reflection or similar hackery). Additionally, the behavior of X is tied to that of C. So you're really testing X(C) rather than just X. Now if C changes, your tests of X may need to change as well.

This is a key principle I follow for years now. It offers so much possibilities. You have to rethink how you design your code and will not end up with too many interfaces. I have designed a full http library which has exactly two interfaces and all the features. I use objects as transformation and processing of data, not for holding data. That results in very few interfaces, high flexibility and no nonesense interfaces like "BigDecimal" etc.

I just love how you explain things. Sometimes i used your design pattern videos over the GoF book, because they are just so good. Really love the new content you‘re creating 👏

@ChristopherOkhravi

2 ай бұрын

Really happy to hear that. Thank you for watching 😊🙏

Man your content can easily be addicted,i love ur way so much Keep going 🎉🎉👍🏻😁

@ChristopherOkhravi

2 ай бұрын

Thank you 😊

Awesome video, man! I'm a developer with over 25 years of experience, and your video still taught me a lot! Now I'll have to watch all of your videos! Thanks!

I love reading Yegor's articles, because he's so extreme. This is a pretty good idea. Thanks for sharing.

If you do not find a good and obvious abstraction then it is better to keep it concrete. Bad abstractions are usually a much bigger pain to deal with than concrete classes. Just remember to inject your concrete class so it is easier if you need to change it in the future. (if you need to mock it in tests then you of course need to do whatever your language requires to be able to mock it.)

@ChristopherOkhravi

2 ай бұрын

100%. We agree. I like the Sandi Metz quote: Duplication is far cheaper than the wrong abstraction.

The concept is very good, the lesson is very good... the way that the letters and icons where draw on the whiteboard...oh my! Its gorgeous!

Its good to see you again, with great explanations.

I'm so glad to see you again!

Wow what a throwback! The first videos I watched from you were your vids about SOLID. You helped me ace some exams back then. Good to see you back! :)

@ChristopherOkhravi

2 ай бұрын

Happy to hear that 😊

awesome stuff Chris. thanks for making these videos.

Chris -- Thanks for your videos. As an old OOP developer, I enjoy listening to your lectures. When I was writing lots of corporate code I had very few people to discuss these concepts with. So I did the best I could reading many books. I would very much like to hear your thoughts regarding the 'Factory Method' design pattern. I implemented it in various ways, but I never had guidance from an academic point of view, LOL. It would be great to hear your perspectives. Thanks.

Wonderful videos, Christopher!!

Glad you're back on KZread :D

Thanks for the lesson,

that would be great to see your explanation on more common use cases like an e-commerce for instance. I really enjoy your teaching style man. Thanks for the content!

I missed your content. Enjoing it, even not being programmer myself. Glad to have you back!

@ChristopherOkhravi

2 ай бұрын

Thank you 🙏😊

I'M SO FREAKING HAPPY LOVE YOU THANK YOU

you are inspiring! very happy to ser you again here! wish you the best thank you for everything 🎉

Your videos are really helpful man. Thank you so much

I love your teaching approach :)

Gold, instructive. Thank you for your time.

@ChristopherOkhravi

2 ай бұрын

Likewise. Thank you for yours 🙏😊

Thanks for the video. Yegor Bugaenko sometimes makes a bit extreme statements, but overall the book is great.

@ChristopherOkhravi

2 ай бұрын

I agree 😊 But I think the exercise of pushing an idea to its limits just to see how far we can take it is tremendously valuable. So I very much appreciate the extremes 😊 Thank you for sharing your thoughts. 🙏

love to have you back

Excellent content as always

Thanks for introducing me to Elegant Objects. It looks really interesting.

Glad, you are back! All the best! :)

@ChristopherOkhravi

2 ай бұрын

Thank you 🙏

Seeing your video after 3 years.. I followed your solid principle closely

Great content, plus nice style. Congratz and keep discussing such nice topics.

Great Content

Hi Chris. Brilliant as always and I highly appreciate. But this time I completely disagree. "Always use interfaces", "Couple to abstractions" these two definitely lead to premature abstraction and are extreme statements. They also lead to meaningless IDoSomething and DoSomethingImpl : IDoSomething. In my opinion one should couple to abstracton (or use interface) only if there is more than one implementation of the abstraction. Otherwise coupling to implementation is the only right choice. I also think that one should start with just an implementation and later abstract things out when needed.

@aoidev3809

2 ай бұрын

I think abstractions must be carefully thought out, since they are better to not be leaky, for them to be useful and stable... that means you better work them out upfront, which means you need to see the variations of data clearly. The abstractness of the example doesn't give the impression of being carefully thought out. Like, here we assume an endless possibilities of variation. In reality those possibilities are more concrete. You cannot program what you cannot even imagine to exist, there's even no place for speculation (or some people may find endless possibilities for speculation, but we want to get a job done as fast as possible) There are known knowns, known unknowns, and unknown unknowns. The last one we don't even touch until the time comes. And it is more of an architectural thing, than designer

@aoidev3809

2 ай бұрын

So, to sum it up, I agree that example and the message are misleading, but I don't agree in suggested way of work, when you refractor design out of concrete code

@user-ev9jg6ts6e

2 ай бұрын

@@aoidev3809 It's impossible to design-first all the abstractions. It's an iterative process. YAGNI.

@InforSpirit

2 ай бұрын

I think common problem with these kind of imperative statements is that these are not spesific enough to close of other user cases where example is useless (simple programs). This example is mostly valid for complex pipeline programs. Rendering and game engine are good examples, because there is oneway of abstraction towards hardware. For renderer there is no distinction between player or Npc, both are just blobs in screen, but in higher level those had meaningfull difference.

dude is the best!

never leave again. Best OOP design channel

@ChristopherOkhravi

2 ай бұрын

Thank you for the very kind words. And thank you for coming back 😊🙏

what if I'm not expecting any variation? Interfaces are costly: they make the code more complex, and sometimes I am 100% certain my interface/abstraction will forever match a unique concretion. Then it doesn't make too much sense to use interfaces here?

@PhilipStCroix

2 ай бұрын

probably wasteful still, but it often helps with unit testing since you mock the api instead of the concretes dependencies

@user-ev9jg6ts6e

2 ай бұрын

@@PhilipStCroix This way you end up with tons of useless mocks and tigly couple your tests to your code. Mocking eveerything is bad practice.

@jason_v12345

2 ай бұрын

bingo. Don't overengineer. You can always "extract interface" if and when the need arises

@mhandle109

2 ай бұрын

Yeah. Some classes don’t need abstractions. BigDecimalInterface would be a joke.

Thank you for your content :)

@ChristopherOkhravi

2 ай бұрын

Thank you for watching 😊🙏

Thanks :)

Thanks

Thanks for another amazing vid 🙏. PS: a full course would be awesome if that'd be possible to you :)

@ChristopherOkhravi

2 ай бұрын

Thank you very much for the feedback. What topic did you have in mind? OO design in general?

@arminium56

2 ай бұрын

@@ChristopherOkhravi right now I'd really appreciate an algorithm and data structure course but anything you share is a blessing :)

finding your videos may be after half a decade. Welcome back :)

@ChristopherOkhravi

2 ай бұрын

Half a decade. Yikes 😀😬

Great video, however would love if you could do a follow-up video on this, perhaps providing 4-5 different examples, showing how the structure is similar and/or different in each. I think I understand the theory, however with just a single example in this video (move/attack/thunderbolt), I'm not 100% sure of the mental rules I need to apply when deciding when to use classes VS interfaces, ie what is regarded as data VS behaviour, when is creating an interface a waste of time etc. Having more examples of this would really reinforce the concept.

@avidrucker

2 ай бұрын

Agreed

Very good content. Would you be open to create a video about the Expression Problem?

Love your channel

@ChristopherOkhravi

2 ай бұрын

I’m happy that it’s useful. Thank you for watching and engaging. 😊🙏

I agree with the theory and this is the way. Love the way you explain it as well. My problem with it is in practise you end up doing lot of abstractions and don't get the benefits. Like if you have the hard rule of "Any public properties or methods should be interface" lot of the the time you end up with only one use case of the abstraction and of course more bullet proof for changes later.... if they happen ... but usually they dont. I think these rules apply much better to something like items, moves etc... but other cases in programming becomes just tedious work? Really curious to hear your thoughts if we should just default to abstraction like this or think about it first.

@ChristopherOkhravi

2 ай бұрын

I completely agree that “always” is too strong. But in my estimation it’s better to shoot for “always” than not because otherwise we’ll skip doing the right thing too often. Thank you very much for sharing your thoughts.

Apart from helping to respect the open/closed principle the interfaces are also needed to unit test using mocks. To paraphrase an adage: "No class is an island" and when you use them in another one you need the interface to mock them.

Keep going❤️

This is what happened, when you don’t have in the language features : functor, applicative and monad (free monad) to compose classes nicely without the need of interface. Either you have these nice Functor abstraction or you get yourself nice with interfaces.

@NostraDavid2

2 ай бұрын

Knowing FP is a boon to the OOP and procedural programming paradigms. Though of you make a game you MAY (big may) want to stick to OOP for performance (though that might not matter for your game). Outside gamedev FP may be better suited for one's needs.

cool vids !

Many thanks for mentioning my book :)

@CouchProgrammer

2 ай бұрын

👏👏👏

@ChristopherOkhravi

15 күн бұрын

Thank you very much for writing such a great book 😊🙏

it would be great if you cover system design someday

Great video. Could you cover how to handle mirrored hierarchies such as that in ML libraries (a config class and the model class are tightly coupled) => for each config you need a model class and vice versa. Or is this a valid use of mirrored hierarchies?

Did anyone here bother reading the book though? Because even if you scan the content for 30 minutes, it's full of bad advice, overthinking and pointless rambling. That said, it makes some good points.

my man making banger videos again. this means he is taking a sabbatical from his studies lmao (as someone taking postgrad as well)

@ChristopherOkhravi

2 ай бұрын

😊 Best of luck with your postgrad. In my case it’s that the kids are getting old enough for it to work and that I’m starting to get the hang of my teaching job 😊😊 Thank you for caring 😊

People should take Yegor's ideas as thought experiments, not advice, as he takes them to far beyond pragmatic.

Return of King

Love your content man. You remind me a little of Mr Bean.

How applicable do you find these videos/concepts to languages that have added OOP after their creation or through frameworks(Angular)/langauges(Typescript) as opposed to those that have had them from the beginning?

Will you ever do functional programming in the same way you do OO, i feel like you could teach me and many others what monads are :D

I'd say it depends. For example, the project I'm working on currently is an API where most of the classes and interfaces have a 1 to 1 relationship. For each interface there's exactly one class and not expecting more. In which case I think it only makes sense to use an interface if you need to mock it in tests. Otherwise it's a useless additional file you need to maintain.

Yes and yes.... Great video!!! Programming Design Patterns => SOLID Principles => Coding to an Interface. If you code to an interface you will find yourself following most of the SOLID principles and can easily read and understand most design patterns. But why do this? Simple: you are creating code that can be changed, while being less likely to break (like a strong tree) and is testable. Why is this important? If your code is low prone to error and more flexible, changes will be more robust and quicker. For a busines this means lower cost. For the developer, justification for their job and rate. Don't believe me? Ask Southwest Airlines how much it cost them when their ticket system went down.

GREATE GREAT!

This might be a good idea in some cases, however, the difficulty that it introduces when it comes to navigating your source code/execution flow is often overlooked. I think this is a very important aspect of programming that can make debugging and understanding execution flow much more time consuming. It should not be a rule. Rather, it should be a trade-off.

Classes should indeed be used for data variations. But, more than that, classes should be coded for immutability. Objects created to encapsulate data, should be immutable (like String class in Java). Coding for immutability has some advantages, one of which is being inherently thread-safe. This in turn, makes you code perform better because, among other thigs, you don't have to block processes by using synchronization. This is a good thing to keep in mind.

What happened to Thunderbolt and Scratch? How are they implemented?

Create example: I use interface to describe behaviors not data.... (true the behavior acts on the data.... e.g. getters and setters). One last comment... this is at the heart of OOP (along with Events/Messaging .... don't want Alan Kay to think I didn't hear what he said about OOP).

I definitely agree that the core 'domain' should be modeled with interfaces but sometimes a class is just a class. Don't cargo cult, ask yourself what the actual (not future/theoretical) value of the code is. I don't need my 'utils' class to implement an interface. (I'm well aware of the OOP dogma around util/manger classes and remain completely unconvinced) I'll ignore that in languages like java, interfaces can have a default implementation further blurring the line of (abstract) classes and interfaces.

I really wish this were in e-book format.

@ChristopherOkhravi

2 ай бұрын

I did write a book on OOP. But it’s less about design. theobjectorientedway.com/ Thank you for watching and for the feedback 😊🙏

Are you going to bring back videos relating to fp?

I wish i could comenup with a clever comment.... Not the case 😂! Great video.

@ChristopherOkhravi

2 ай бұрын

Nevertheless, thank you for watching and for commenting 😊

Not every class need abstraction, some classes could be concrete too. like if we conceptualize hierarchical pattern between responsibility and behavior,= or subtyping then we can go with abstraction using interface but at the other end utility or extension classes should be concrete in application.

Is an interface (as in a class with only virtual methods and no data) the best option in this scenario? It seems like any kind of Move would want to get and/or set data in a Player. If you were to do this using interfaces, every implementer of the interface would have to fill in some getter or setter method. Seems like a base class would be better, but correct me if i’m wrong. Still nice video though 😊

You are right, but people careful other principal. A class need change for one reason and not be forced to change when creating other method in your interface.

I mostly agree. Usually this is true. However, there are, in my experience, cases where there's really nothing to abstract from a data class. It really only applies to data classes, not to service classes. But I've absolutely worked on systems where we built an interface for a given data object and... the interface ended up doing nothing but making life more complicated, not less, since there was no logical alternate implementation. There was never another implementation, ever. But we still had to deal with the interface, and that meant double work every time we added a method. Now, there are cases where you'd want to have multiple interfaces the data object implements. That's an under-rated concept. One issue with your example on the board: IMove as written assumes all moves involve another player. "Player A attacks player B" and "Player A moves forward 2 spaces" would, I expect, have different interfaces. So the model would have to be further abstracted in some way.

@ChristopherOkhravi do you mean that? public class Attack : IMove { private readonly int _damage; public Attack(int damage) { _damage = damage; } public void Use(IPlayer target) { target.Health -= damage; } }

@ChristopherOkhravi

2 ай бұрын

Exactly. Something along those lines 😊 Thank you very much for typing it out 😊🙏

@CyberMarshall

2 ай бұрын

@@ChristopherOkhravi Thanks a lot! 🙏🙏

Go kinda forces you to this great pattern

But on a serious note, does this “rule” carry over to the other languages which doesn’t have the workaround “interface” for multi-inheritance but have pure virtual classes instead?

decoupling comes with costs it's not free.

@ChristopherOkhravi

2 ай бұрын

Very interesting point. Would you care to expand? 😊

@kevalan1042

2 ай бұрын

@@ChristopherOkhravi My thoughts on this: By telling users to couple to IMove instead of to Attack, you add complexity to the user's code, because for attack-specific code they have to check if the IMove is an Attack, right?

Just a note that Yegor is a supporter of russo invasion of Ukraine, totalitarian, and he also made many hate speeches before. He is also banned from many conferences outside of russia due to his believe of government should be a god and people should just follow orders.

@ChristopherOkhravi

2 ай бұрын

Oh no. This makes me very sad. 😢 Thank you for sharing this. I certainly prefer to stay out of this debate and want to focus on the software discussion.

@expeditiontoabyss3597

2 ай бұрын

@@ChristopherOkhravi I can totally relate, and you can't check every author's bio before reading his book/post. Thanks for your kind response.

@user-lk1fw1lp8b

2 ай бұрын

Does it invalidate any of Yegor's statements regarding object-oriented design?

@user-td1me8eu3f

22 күн бұрын

@@user-lk1fw1lp8b No. But buying his book brings him money, which he pays taxes on in Russia, which is used to kill Ukrainians. This is the chain of consequences

Create a concrete type with a general name like Animal. Use it. When time comes your application needs Dog and Cat, change Animal to an interface and implement it in Cat and Dog. This way you keep you clients safe and don't pollute your code with files that are not needed yet. I was taught thid rule by Nikita, and who told him, I don't know.

The problem is that you can easily be tempted to ruin this by adding a concrete method to your prematurely chosen interface. You should focus on having as few types to dispatch between as possible before you start abstracting. Imho, Go has it right by making consumers define interfaces instead of having providers define interfaces (decoupling/elimination of imports instead of dependency inversion). If many consumers end up needing the same method, make it a shared interface. If you have one cluster of consumers that need one set of methods and another cluster of methods that needs another, make two smaller interfaces that are used for the different call sites. The most important thing is to avoid having shared interfaces with a large number of methods since those make the interface way less useful since those basically enforce that you will actually only have one or two implementations.

IMO this approach will lead to class explosion very quickly, if ill take the refactoring rule you discussed about in previous video, i would take this rule when i "touch" the code the third time. Regardless thank you for another enriching video

Do one on AI and how it will share future prospects for software engineers

little mistake, YegO'r, not YE'gor) great video as always)

@FroodyBanana

2 ай бұрын

It's LEVI-OSAH Not LEVIO-SAH!

The name of the abstract class would make more sense as action instead of move. Move can be types of actions, and move could mean the character in the game could you are referencing moves location, or it is their turn and they make a move, which is some action. This would decrease the ambiguity of the abstract class name and make the code more reader understandable for different developers.

@ChristopherOkhravi

2 ай бұрын

Makes sense. This was raised as an issue in the related video and I mostly agree. I wanted to make sure to keep it consistent with that video here however so opted for no changes. On the flip side it makes sense in my mind that a “move” is something you can do in a game. In my mind I was thinking of the old Pokémon battles and since there’s no physical movement there the name made sense to me 😊 Nevertheless I think you are right that it could be clearer 😊 Thank you for your detailed comment 😊🙏

Actually, this was an empty space for me before, thanks for clarifying. And one more thing, when we say interface, I assume that we still mean Interface or Abstract class, right?

@ChristopherOkhravi

2 ай бұрын

I’m very glad to hear that. 😊 Yes generally the point is that we should couple to an abstraction. Which would include abstract classes. It should be said however that it can certainly be argued that we should always prefer interfaces and never abstract classes. Classes can only inherit from one abstract class but can implement multiple interfaces. So the former is less flexible.

@jorkhachatryan317

2 ай бұрын

​@@ChristopherOkhravi Thanks, now it's more clear.

This seems to be a tradeoff though. By telling users to couple to IMove instead of to Attack, you add complexity to the user's code, because for attack-specific code they have to check if the IMove is an Attack, right?

@ChristopherOkhravi

2 ай бұрын

Good question. The need to type checking is an indicator that we need to restructure our solution. If we need to distinguish attacks from other moves then we should not mix objects of the two types in the same collection. We can still however couple to the abstraction rather than the concretions. In other words the battle menu might consist of two collections for example. One containing things that you apply to the opponent and one that you apply to yourself. For example. See what I mean? Thank you very much for the question and for watching 😊🙏

@kevalan1042

2 ай бұрын

@@ChristopherOkhravi Thank you for the response. I still don't understand what should be the driving factor for introducing an abstraction. For example, why not introduce an additional abstraction above IMove, maybe IAction? And one more above that?

I see the strategy pattern in the solution.

And what happens when we are using a dynamically typed language like javascript or ruby?

@ChristopherOkhravi

2 ай бұрын

In dynamically typed languages we can still “think” in terms of abstractions. We write code that works for any concretion of our abstract ideas. But the abstraction is never written down as code. Thank you for the very relevant question. Will try to dedicate a video to this in the future. Thanks again 🙏😊

Question, if we are to inherit for data changes, and implement for logic changes, why can't I inherit structs in C# XD

Idk, I generally agree that if you can stick to interface you should, but writing good interface is an art and if a lib doesn't expose the method you need in an interface, coupling to the concrete class seems more and more acceptable to me as times passes. Sure, doing so might break the lib correctness but in the context of your app doing what it needs, "correct" coupling with a lib isn't worth much. Though if you have control over both interface and consumer code sticking to interface is the best option. That said, interface are the only kind of technical debts you can't pay back until the next major version so overusing them seems bad too. Also, there is another (niche) angle where interface aren't necessarily the best option: performance critical code. The way I see it, interface are about commitment to a contract but there are things that can't be modelled as part of the interface (error safety, memory usage, perf). Coupling to concrete class doesn't change that fact but if the contract is not sufficient, there's little point setting it up.

Blueprints

Making that a general rule is ridiculous. Abstraction always comes with an overhead cost and it has to be weighed if it's worth it. I hate working with dogmatists who want to cram abstractions into everything. It's a maintainability nightmare, especially in a project with evolving requirements.

@ChristopherOkhravi

2 ай бұрын

Thank you very much for the perspective. Generally, if you have examples or stories from past experiences do feel very welcome to share them here. I’m not trying to push. Just saying that I’m sure that people, myself included, would appreciate the opportunity to learn more 😊 Thanks for watching and commenting 😊

@HyperionStudiosDE

2 ай бұрын

@@ChristopherOkhravi Just to be clear, my post wasn't aimed at you. I'm just ranting because I hate dogmatism in programming.

Hello!

I wasn't sure if this video is a joke until about half way through lmao

@ChristopherOkhravi

2 ай бұрын

Hmm. That doesn’t sound good. Is it because I am expressing myself poorly, or because the idea seems silly, or because it seems as if I was saying that we should never use classes? Thank you very much for your feedback 😊🙏

@jinyeom766

2 ай бұрын

​@@ChristopherOkhravi Oh no, the video's great, it's just that I don't take any videos seriously today (it's April Fools) :D

@theMadZakuPilot

2 ай бұрын

@@ChristopherOkhravi probably because it's April 1st

@jinyeom766

2 ай бұрын

@@ChristopherOkhravi As for a real feedback, would you recommend the book you mentioned in the video?

@aoidev3809

2 ай бұрын

Please remove this comment from the top, it's misleading and made me stumble

4:36 Demonstration of how to implement the shape interface

@ChristopherOkhravi

2 ай бұрын

😆