Programming With Intent - Method Design Part 1
HTML-код
- Опубликовано: 28 сен 2024
- You'd be surprised, how simple changes to the way we write code can speak a thousand words, making our intent clear and thus easier to read, understand and maintain.
Methods are the fundamental units of work and have a direct impact on how we reason about the code we write. Good method design leads to good class design and thus good system/API design.
In this presentation, we’ll learn about C# principles of good method design and implementation. Method’s that are designed and implemented well:
1. Clearly express our intent to the caller
2. Clearly express our intent to the maintainer and our future selves
3. Make it easier for the maintainer or our future selves to comprehend
4. Are at the correct level of abstraction
5. Are efficient
2:33 Method Design
2:48 Tell me a Story, Don't make me think
9:17 Naming is Everything
13:26 We Don't expose our privates
14:59 Public methods should not be Virtaul/Abstract
15:49 Methods should be sealed
16:41 Methods should Autonomous and Pure
19:47 Need to know Basis - Method should be provided with the bear minimum information
20:20 Methods that are Actions/Commands should be void returning
22:37 Methods that are Queries should return only what they claim or not return at all
28:48 Common Practice is not Common Sense
31:39 Don't validate formal arguments
32:13 Callers Data - Caller's problem
33:11 If you lock the front door and you lock the back door - you're safe in the house
35:18 Clean up and valid input data at the Entry points of your system - front and back door
35:43 No Empty Strings. Strings can either be null or a valid string.
![Yailin La Mas Viral, @kreizyk.official - Dale 2 (Remix) [Video Oficial]](http://i.ytimg.com/vi/JaYHBzgqz94/mqdefault.jpg)
![Cody Johnson - I'm Gonna Love You (with Carrie Underwood) [Official Music Video]](http://i.ytimg.com/vi/yy9PuYMU29g/mqdefault.jpg)
each time i watch one of your videos , I feel that need to appreciate your work(masterpiece), please keep it up man.
Thank you Farzin for your kind words and for showing your appreciation by taking the time to comment. Very encouraging indeed.
Shiv you provide soooo much value for free. If programmers implement this stuff correctly they could save their companies millions down the line. Thanks for sharing this with us!
Thank you Ruben, for your comment. All of the projects I've been developing for the past 10-15 years have been implemented using these ideas/principals and once folks on my teams adopt to this paradigm, they're amazed at how well it all works.
I agree so much about methods not returning at all if they aren't a success. I have seen so many tutorials where people check null at every level, because they are returning FirstOrDefault. Throw the exception and catch it in the UI is what I have learned to do, glad to see this reinforced here.
Yes! And use .Single() instead of FirstOrDefault(). Most times folks really mean "exactly one".
I call this paradigm - Programming to Exceptions (there is a vide on this). You won't believe how clean and simple your code becomes!
In this video lot has been offered and went over beautifully to give clear insights for the developers. Usually most of us don’t follow this sort of approach while coding. We just follow what has been learnt & taught at the start off our careers. But this video helps lot for do the coding far better and smarter. Thanks Shiv for posting .Net Videos. Whatever you covered all the topics help a lot to use them in development. Basics are always explained with simple examples is fabulous approach.
Thank you Ma;;a! Appreciate your comments!
I like your teaching a lot, this is by far the best thoughts about programing I ever have come across. Thanks!
Hello Shiv. Another great content. Thank you very much. I can't seem to find the second part of the Method Design. Can you help me out with it's name? Thanks in advance.. Bests.
Great content and very interesting. But where is part 2?
Thank you Fredrik! There are many parts that are part of "Programming with Intent". Please take a look at my Programming with Intent Playlist. Almost every video I've made over the last 3-4 months has been part of PWI.
Hi, when do you plan to release the second part of the lesson?
If I follow the TDD principle, my methods may not be initially private.
Dem Bulson I'll be posting Part 2 next week. With regards to private methods and TDD, sure if you're tasting a method then that method can be public but any methods you define that are called from this public method should start their lives as private. Also also as regards unit-testing and TDD you may want to look at my video titled Unit Testing Rebooted (ruclips.net/video/OBoq3zkL8r0/видео.html) for guidance on what Martin Fowler and Kent Beck have to say with regards to Unit Testing and what Kent Beck's vision of TDD was initially when he wrote the book on TDD. It's quite different from what folks are bandying about in the software community.
Thanks, I get it.
Hi Shiv. Thanks for the great video. I always enjoy listening to your philosophies on coding and I learn a lot from it. So I am looking forward to the remaining videos in the series. It's been a while, so my most important question is that I hope you are well.
Two quick questions:
1. 1:03:30 - Use var where you can.
My perspective on this is to use var only when what is on the right is very obvious or where it is essential. If there is doubt on the right as to what the type can be, then I would prefer to know the type and so not use var unless its essential. I dislike seeing var all over the place because it feels weird to me to have a typed language but treat it like it is not typed. I recall when there was a time we did not have var in C# and as I understand, it was only implemented as a convenience.
Also on this, if you are using a more generic name like var, are you really programming with intent because you are saying you don't know what the type should be? Perhaps I'm taking the philosophy to the extreme by saying if I want an int, I should be specific and say its an int because this is my intent. But maybe I missed the point?
I look forward to hearing more about this.
2. 1:16:50 - Booleans.
Given your reasoning for not using bools, it would imply that one should also not use enums or other types that can be used for switching within the method, and perhaps one should also not change functionality by testing the type in some way and deciding what to do based on the type. For example testing if it is a type of one class or another (so the argument might be of a superclass of both classes). I'm assuming there might be exceptions to switching on type of class for example with reflection etc as this would be the purpose in most cases of using it. Is this correct?
Finally, as mentioned I really enjoy the philosophies, but trying to implement these ideas (design patterns, methodologies, best practices) really slow down my programming. :) There are very few places where I worked, that allow extra time for such practices to be implemented. They want it done last week. I try to implement them in my own small projects, but most times (not always) I cannot implement them in real projects (or I can only implement basic or essential philosophies). I tried the technical debt argument with the business folk, it rarely works.
Sorry for the long comment. Thank you again for this excellent video.
Hi Francis, Great to hear from you! As regards var, I'm saying the same thing as what you are. In addition, I'm saying that it may be that the method on the right side (if there is one) needs a name change if the return type can't be inferred. So, yes, as long at a human being can infer the type, use a var.
As regards enums. IMHO, I don't see enums in the same category. There are cases where a method needs multiple bools. In that case I'll use enums instead of bool (it make the method signature clearer, especially at the call site). If one is using enums primarily to make a method more generalized then I'd say that use falls in the same category as bool. However, if you watch my Polymorphism video, you'll see I use an enum and switch case in order to determine that instance type that should be created such that the rest of the code can use these instances polymorphically.
In this video, I say methods that have bool arguments or return bool are "suspect". So maybe enums can fall in the same category. However, If my "message" gets across clearly, I'm hoping folks don't find ways to "beat the system" :) and thus loose sight of the core message by trying to be "Cleaver".
Hi, thank you for great video and great principles ! I'm curious about how you ensure all these princples accross your teams to make sure "boogieman" won't arise in your house ? Isn't it fragile to build a system on no coder will make mistake ? Otherwise isn't it time consuming to go through the codes of other team members ?
It involves propper training and stringent code reviews, yes. Nobody is intentionally trying to let the boogieman in the door and the entire team is watching for any code that doesn't comply. It's a lot easier than you might think, but it does involve time investment during the initial phase of a project especially if the team is new.
Keep in mind that the "other way" has a ton of issues that go in noticed, unresolved and lots of production bugs. So you either pay price up front to train folks on the team and ensure strong code reviews or you pay for it later by way of unmaintainable code and bugs
@@Matlus You got a point I guess 👍 it's just that we are not patient to get the MVP out sometimes even if it's not viable 🤷
Amazing Video! Loved it!
Can you please share some books based on these guidelines.
Abdurrehman, Thank you for your comment! These guidelines are mainly my own. Of course I'm sure I picked up a few from some books I read, such as .NET Framework design guidelines. But I also know there are many guidelines in these I don't agree with.. So what I present here and in the rest of the Programming With Intent series is mainly my own distillation and learning over 15-20 odd years.
@@Matlus Sir, These videos are really golden words! Without a doubt! And the way you teach - Amazing!! I can't find "Method Design Part 2" of this series... Is there only one part you made?
@@arm-pr2ki Thank you for your kinds words! Very encouraging to say the least. The other parts are not necessarily "Method Design" but rather they cover "Programming With Intent". I have a playlist called Programming With Intent. Lots of other parts really. the API Design Parts 1 and 2 are on the lines of Method Design. But I'm almost certain you'll enjoy all of the videos in that playlist. But every video I've published on my channel (on programming) is near and dear to my heart and thus important :)
@@Matlus Do you have any Git account or something where you upload your codes, where i can study and learn from your projects?
@@arm-pr2ki I do. I generally link to the source code in the description of the video. But I don't have a full blown project on GitHub yet. github.com/matlus
Hi Shiv. Nice video. I do not agree with all your guidelines, but most of them are fine. I am exciting to see the next video in this series.
Hi @Christian. Thank you! Yes, I can imagine folks might not agree with some/all of the guidelines I've presented here. From experience, some of what you may not agree with is probably to do with some information that is missing, that is, since I haven't talked about "Programming to Exceptions" yet, some of the guidelines (or goals) presented here may not be agreeable. Nonetheless, I'm curious to hear your perspective if you care to describe them.
Hi Shiv. Thanks for the reply. I will try to explain some of my opinions.
17:00 (Methods should be Autonomous)
- I agree, but it is allowed to use private fields that are passed to the object through the constructor.
17:00 (Methods should be Pure)
- I agree, but again allowing it to use private fields that are passed to the object through the constructor.
20:27 (Methods that are Action or Commands should be returning void)
- I would extend that to also including returning Task in case we are doing async programming.
32:28 ( Don't validate formal arguments)
- If by validating you mean business logic, I agree.
- I will still validate for null arguments in methods/ctor's. "Fail fast"
35:27 (Data validation)
- I dislike the usage om primitive types for arguments in methods/constructors. Also called primitive obsession.
- I rather introduce a new class instead, and the contructor will validate the primitive type instead and through exception if not of the right kind.
- e.g. class EMailAddress{}. If you got a instance of this, it is valid.
50:00
- For me it looks like the best solution is to use Polymorphism instead of so many "ifs"
Autonomous - Essentially, you don't want to use state. So if the private field is providing "state", then no. But if the private field is an aggregate class and that class is also stateless and follows the same principles, then yes, that's fine. Every class should look like a black box to the caller (I'll explain Class Design in another video). So the caller if this class should be able to call a method on this class without any prior "setup". Calling the same method with the same arguments should result in the same outcome. For classes whose sole purpose is state change (the leaf nodes of your system), of course that's probably not possible. For all the rest of the classes that should hold true.
Pure - For pure methods, my answers is the same as for Autonomous methods. The real difference between Pure And Autonomous methods is that Pure methods do not change state and do not rely on state (pre-existing state). Both can use "helper" classes (unknown to the caller). So calling the same method with the same arguments (their values) should result in the same outcome.
Validate Arguments - Data is cleaned and then validated (business logic wise) at the entry points of your system. After that, I've never had the need to validate arguments throughout my system. Now there may be some rare cases, but as a general rule I wouldn't :). But I know how it goes, the "rare cases" are rationalized be become all the time :). And what I'm saying is, your going in position, should be to not validate. As you can image, it requires that your entire system is designed/implemented this way, not just one to two classes. If you do have a case where you know you have to (not just a feeling or to be in the safe side :)), then please let me know. I'm really curious now.
Data Validation - Who's calling the constructor. Why is the caller not sending valid arguments? I mean, the caller is interested in using the services/capabilities of this class. So if the caller desires a valid outcome, the caller should ensure it does right by the called :). If you have a gasoline engine car, would you put diesel in it? If you, want to be able to drive the car so it can take you places, then its your responsibility :). Its a different way of looking at things. I treat the root cause, not the symptom.
Replace Conditional with Polymorphism - Yes, sure. I just do it where it makes sense, honestly. I'm very judicious/practical when it comes to my system designs, rather than being dogmatic. I work with folks with varying levels of skills and experience and sometimes one makes design decisions based those considerations as well. At one point I looked at the code for one of my projects and we would have had 230 or so more classes if we did that everywhere there was a conditional.
Thank you for taking the time to describe your issues. I imagine many folks will have the same issues. All I can say is, give these principles an honest try. It is a shift in paradigm. Remove unessential checks/test, and fix the issue at the root, rather than every class mistrusting it's caller.
Thanks for sharing your knowledge! Had a short question based on one of your statements, more specifically "Method names should use the vocabulary of the Domain/business". How would you handle this when the client's business operates on a non-english language, while obviously still coding in english? Would you translate it to the best of your ability, or confer with the client about the proper translated terms? I assume some ambiguity could arise when making loose translations of the Domain vocabulary, both for class and method names.
That's a very good question Anders. I'd ask the business folks for guidance/advise on that unless you feel the business folks aren't interested or don't care. I've had both cases, and in the case where they're not showing interest I've keep pushing them. But I should say, most methods names translated literally and I think that helps the dev team since they're the ones having to "talk" to both sides (business and code). But I felt the business folks need to "own" it and also be able to converse comfortably using both terms.
@@Matlus Thank you for the fast and informative answer!
@@foxcodex You're most welcome Anders! Happy to help.
There are practical challenges implementing these guide lines if you are extending a code base, adding features etc. Most of the times it's unacceptable for the team to understand the importance of cleaning the Base solution with these guidelines.
What a voice sir really i like it
Thank you! Hope you like the content as well?
The anomaly that you mentioned in "actions should return void" section can be corrected by using an object as formal parameter and set the id of the same object when inserted.. please correct me if i am wrong.
If I understand you correctly @Aamir.... The parameter to the method will have a DTO that includes an Id property in addition to the other properties that are inserted. If so this is not what you want to do. For many reasons. First: At the time of calling the method, I don't know that the Id will be something I don't need to fill in. Second: Should not use reference types like this. That is magically getting modified and the caller needs to know that that's what is going to happen. Third: A method should be given only the information it needs and nothing more. So the Id is not what the method needs. So really its for all these reasons this design is not Showing me it intent. Things are not obvious. But the point of "Programming with Intent" is to show me your intent, make things very obvious, don't make me think, don't make me wonder.
Hopefully my reply makes sense?
Sorry, can someone please help me with other part of this series, could not find playlist for this.
I have a playlist called Programming with Intent. That playlist has all of the videos in the series
@@Matlus Yes I just read few comments and go to know, you called it PWI.
Thanks for all the efforts, all videos are very detailed and informative ❤️❤️❤️
@@saurabhchauhan232 Thank you!