Podcasts about solid principles

Testing is a super important part of the software development process to ensure that bugs don't make their way into our code. But what exactly is testing and how do we do it? In this episode, we cover some different types of testing - manual testing, automation testing, functional testing, and non-functional testing. Even if you work with a test analyst or QA, it's really valuable as a developer to understand what testing actually is and how it all works so you can make sure you're using those good testing practices in the work you do. Links Check out Episode 37 Breaking Down the SOLID Principles to learn more about interfaces New episodes come out fortnightly on Wednesday morning (NZT). Follow us on ⁠⁠⁠⁠Instagram⁠⁠⁠⁠ & ⁠⁠⁠⁠Tik Tok⁠⁠⁠⁠ @hot_girls_code to keep up to date with the podcast & learn more about being a women in tech!

Will you be replaced by AI soon? How do you do test video games to deliver a bug-free gaming experience Have you seen what is being called the world's first AI software tester. Find out in this episode of the Test Guild New Shows for the week of April 7. So, grab your favorite cup of coffee or tea, and let's do this. Time News Title Link 0:00 Register for LinkedIn NewsLetter https://links.testguild.com/wwA8x 0:17 Automated Mobile Game Testing https://testguild.me/5cwbhd 1:25 Ai the replacement game https://testguild.me/yy7nl6 2:30 RAG for Quality Engineers https://testguild.me/2cuhbp 3:31 CoTester the world's first AI software tester https://testguild.me/9u4e6m 4:33 cypress-voice-plugin https://testguild.me/x8p9k0 5:40 SOLID Principles for Testers https://testguild.me/tr9qgb 6:59 Once upon a time a cy.session() https://testguild.me/zemnre 8:00 Performance analysis for security https://testguild.me/kfnyjc 9:04 Eliminating SQL Injection Vulnerabilities https://testguild.me/hmf0sx

What do Clueless and the SOLID principles have in common? Well, we think a lot! This week we are chatting all about the SOLID principles; what exactly they are, how they came to be and why they matter. We then explain each of the principles in classic Hot Girls Code style - breaking down all the jargon and using some fun and relatable examples inspired by the hit 1995 classic Clueless New episodes come out weekly on Wednesday morning (NZT). Follow us on ⁠Instagram⁠ & ⁠Tik Tok⁠ @hot_girls_code to keep up to date with the podcast & learn more about being a women in tech!

Jesse chats with Gavin Carew, 2207 BE Alum and Jack In the Box Software Engineer about his Turing story, his tips for being a successful Turing student, his job search, coming up to speed on Kotlin, his current work, advice for current prospective students, asking questions, and optimism for the future. A few classic Jim Weirich conference talks are What all Rubyists should know about Threads - https://youtu.be/4zbN29UkNQw?si=s9v1kqIg22K2v0iu and SOLID Principles in Ruby - https://youtu.be/1BVFlvRPZVM?si=nJ05gm2wI1kOSFHf If you or someone you know are code curious, we encourage you to attend a Turing Try Coding Event. You can register for a Try Coding class at turing.edu/try-coding.  

Materiały dodatkowe:CUPID - the back story, pierwszy artykuł Dana Northa o kwestionowaniu zasad SOLIDCUPID - for joyful coding, kontynuacja tematu na blogu Dana NorthaCUPID - for joyful coding, nagranie prezentacji z konferencji NDC London 2022Patterns of Software: Tales from the Software Community, Richard P. Gabriel

When one gets married, you envision growing old with the one you promised your life to. What happens when in a blink of an eye, that love is taken away? In this episode, I am speaking with Falon Bonner who lived this exact scenario. After becoming a widow at 35 after a car accident took her husband, Falon had to determine if she was going to let this tragedy break her or if she was going to survive this event. After years, she found strength in God and chose to thrive. I invite you to join our conversation as Falon and I discuss: Single Mom Young Widow Entrepreneurship Trusting God https://www.facebook.com/falon.baker.5/videos/10209677808014836 (Our Love Story) Being needed https://www.griefshare.org (Grief Share) Licensed Therapist Support Grief Rock bottom Goal Setting Abundance Freedom Honourable Mentions https://www.apa.org/news/press/releases/2021/08/post-traumatic-stress-symptoms (Survivors of trauma struggle to move on from the loss of loved ones) https://oneexceptionallife.com/trusting-god-in-difficult-times/ (7 Solid Principles for Trusting God in Difficult Times) https://tinybuddha.com/blog/tragedy-can-help-us-find-our-lifes-purpose/ (Tragedy Can Help Us Find Our Life's Purpose) https://www.verywellhealth.com/processing-loss-through-grief-counseling-5225423 (Turning to Grief Counseling When You Need Help) https://www.parents.com/health/mental/how-to-parent-while-depressed/ (How to Parent While Depressed) Where can you find Falon Bonner? Website: https://falonbonner.squarespace.com/new-page-2 (https://falonbonner.squarespace.com/new-page-2) YouTube: https://youtube.com/channel/UCA2kzkbIGSU5DcCM9w0rAMw (https://youtube.com/channel/UCA2kzkbIGSU5DcCM9w0rAMw) Facebook: https://www.facebook.com/falon.baker.5 (https://www.facebook.com/falon.baker.5) Instagram: https://www.instagram.com/falonbonner/?hl=en (https://www.instagram.com/falonbonner/?hl=en) ————— This podcast is hosted by https://www.authenticallybeyou.com/ (Bianca Kesha Hughes). Known for authenticity and heart-work services, Bianca is the ultimate trailblazer in the mental health and wellness field as a therapist, coach, speaker, and podcast host, inspiring her audience to let go of the illusion of perfectionism. Ready to learn more? Contact her https://www.authenticallybeyou.com/ (here)! ————— If you would love to connect with Bianca, join her in these following spaces: https://authentically-be-you.ck.page/3f2e85ebda (Insights and Inspirations) https://www.itdidntbreakme.com (Podcast Website) https:// https://www.facebook.com/authenticallybu (Facebook) https://www.instagram.com/authenticallybeyou (Instagram) Interested in inviting Bianca to speak so she can inspire your audience?https://www.authenticallybeyou.com/biancaspeaks ( Click here) and fill out a short form. ————— Have you been moved by what you heard in this week's episode of "It Didn't Break Me"? I invite you to leave an honest review of how this episode impacted you. Also, share this podcast with a friend. We all have a friend that needs it! Song Credit: Encore by King Sis This is a https://crackersinsoup.com/ (Crackers In Soup) production.

Patrząc na tematy związane z Domain-Driven Design czy książki, można by powiedzieć „DDD - to nie takie proste”. Z Michałem Giergielewiczem rozmawiamy dziś o tym, jak można wejść w ten świat i jak zbudować solidne fundamenty pod przyszłe poznawanie bardziej zaawansowanych wzorców i praktyk.

Get clarity on how to build great software in 2022 in a world exploding with methodologies and languages with the legendary software craftsman Uncle Bob Martin. The Clean Coder ✨is known for Test Driven Development ✅ and his contribution to SOLID

In this episode Dave Copeland and I discuss what we like about SOLID principles and what we don't.SOLID is not SolidSustainable RailsDave Copeland on TwitterDave Copeland's Website

In this episode we welcome back Tony and Klaus to talk about the [SOLID](https://en.wikipedia.org/wiki/SOLID) Principles, and how they relate (or not), to C++. Tony is about to give a keynote at C++ Now about his take on the SOLID Principles. Klaus has been giving a talk on applying SOLID to C++ and even Phil has recently given a talk on a similar topic. Perhaps somebody should have mentioned this to Tony before! Along the way we get plenty of SOLID advice, discover what the single responsibility is that Tony's objects have, what COLID is, who is going to argue against Liskov, and who is just there for the jokes. The answer, of course, is: it depends.

Matt and Ben join an argument on the Internet, which is always a productive and rewarding use of one's time. They discuss the SOLID principles from two different perspectives, and judge them. Listen in for the verdict. Then, Ben ponders how programmers learn, and whether sailors are happy. Matt gets a new puppy.

The Covid pandemic has prompted many businesses, especially accounting firms, to take stock of who and they are, where they are going, and what they need to do to continue to be successful in a changed world. Randy talks with Jon Hubbard of Boomer Consulting, who specializes in helping firms identify branding opportunities, assess their strengths, and using the eight step process known as the Firm Pipeline Builder, grow their business. Get the full show notes and more resources at https://TheUniqueCPA.com

Mark Seemann, who joins to talk about SOLID principles, is a self-employed programmer and software architect, book author, PluralSight author, public conference speaker, Humane Code Video author in Cleancoders.com. Main points What coding problems does SOLID solve? Single Responsibility Principle (SRP) Open-Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP) Links Mark’s Twitter Mark’s SOLID course (PluralSight) Mark’s PluralSight courses Mark’s personal blog Mark’s Humane Code Videos Book – Dependency Injection Principles, Practices, and Patterns Video Teaser The YouTube Video URL The post 71. SOLID Principles | Mark Seemann appeared first on SalesforceWay.

Steve Smith (@ardalis) is an entrepreneur and software developer with a passion for building quality software as effectively as possible. He provides mentoring and training workshops for teams with the desire to improve, and has published many courses on Pluralsight. Steve has been recognized as a Microsoft MVP for over 15 consecutive years, and is a frequent speaker at software developer conferences and events. He enjoys helping others write maintainable, testable applications using Microsoft's developer tools. Connect with Steve at https://ardalis.com/.Show resources:Follow Steve on TwitterSteve's Pluralsight coursesSteve's personal websiteWeekly Dev Tips podcastAccelerate your career with devBetterFull transcript:Barry Luijbregts  0:25  Welcome to another episode of developer weekly. This week, I'm talking with Steve Smith, also known as our Dallas about solid principles. Steve is an entrepreneur and software developer with the passion for building quality software as effectively as possible. And he also has published many courses on Pluralsight thanks for being here. Steve. How are you?  Steve Smith I'm doing great. How are you doing?  Barry LuijbregtsYeah, I'm doing I'm doing all right. You know, the, we don't really have a hard lockdown here in the Netherlands. So it's like an intelligent to go fit lockdown. But we might be ramping up with countermeasures. Again, as we see the cases coming up, you know, people are going on holiday. Steve Smith  1:08  Yeah, yeah, as we're recording this, it's late July of 2020. And in the United States, at least we're seeing like 60 or 70,000 new cases a day. So we're probably not as lucked out as we should be. But I'm doing my best to stay home as much as I can. Barry Luijbregts  1:23  Yeah, most people here are pretty cautious as well. Although now that it's summer, you see lots of people just, you know, they want to go out and do stuff. They also want to go on holiday. So you see people stress spreading out over Europe, they're going on holiday to France or whatever. So I'm very curious to see what's going to happen when everybody comes back from all those places.  Steve Smith  1:44  Who knows, you know, we're having same things happen here, I think. And it's it's difficult because some states in the United States are trying to implement things like a quarantine for people coming from outside the state. But there's there's no borders for it. There's no there's no checkpoints at the At the state borders, there's no way to implement such a thing except voluntarily and, you know, if people are gonna take the pandemic seriously and do it voluntarily, I think they would at least be wearing masks and things. I don't think you can expect people to voluntarily self quarantine for 14 days. Barry Luijbregts  2:16  No, definitely not going to do that, please. Most people probably aren't. Yeah, that's difficult times weird times. But hey, at least we can do our thing. Online as as as most of our work, so that's a good thing. Yeah. We're very forthcoming in disguise. Yeah, absolutely. So I follow you on Twitter. And I also sometimes read things on your site weekly, Dev tips.com. I enjoy that. And I always just learn something about design patterns and code quality stuff like that C sharp. So how did you get into code quality and design patterns? Steve Smith  2:52  It's been something I've been interested in since I discovered them. So as a, as a human, a junior developer, I was always interested in trying to write Better code and just trying to get better at what I'm doing. And so I would read books that had titles that sounded like, you know, that sort of thing. So, you know, in the early days, it was design patterns and refactoring, you know, those classic hardcover books from the 90s. And then more recently, there were books like clean code, and, you know, classic books like code complete. Also from the news. But Stephen candles, get a more recent version. So all of those books just sort of try and describe ways that we can write code in a more consistent, more maintainable way. And I do my best to, to try and write code that that I can be happy with later. And of course, I always fail because I always find better ways to write my code. And if you're not, I think you're not improving. But I think the, the striving toward getting better is the important part.  Barry Luijbregts  3:56  Yeah, definitely agree. It is very difficult to you know, Basically, sometimes when I create something new, it's just, it's a big, messy ball of stuff, right? And then I try to make it pretty and beautiful. But it's sometimes difficult to just know how to go about that. So it's good to learn principles and and more rigid and solid principles to do that, right? Steve Smith  4:20   Yeah, and a lot of it has just been an evolving of my understanding of object oriented design. Most of the design patterns and things that I talked about are mainly object oriented principles. And when I first was learning about object oriented design, and jointed principles, I was very much thinking of them as literal objects, like in the space of the problem that we were working with, right? So if you're, if you're working on a shopping cart, you know, application, then you might have objects like customer and carts and product or something like that. And until I started getting into design patterns, I didn't really think More abstractly than that, right? That was something that really opened my eyes to the idea that you could use objects to be these abstract things within your solution in ways that you never would have thought to do if you were strictly thinking about them as, as nouns within the requirements that you were trying to build, right? Barry Luijbregts  5:18  Yeah, I think they're very interesting things. I've also dove into the cloud design patterns, as well as I'm totally into Microsoft, Azure and other cloud providers, which are things like retry pattern and stuff like that. It's a bit different, obviously, then, things that you might do in C sharp, the classic design patterns. They're very interesting things. Steve Smith  5:41  Yeah, once you know that design patterns exist, you can apply them in any field it seems or in different subfields within software development. So I mean, the point that the the authors of the Gang of Four book make is that they borrowed heavily from a book that was on architecture and town planning. Yeah, that's where they took the their structure of how they described the different patterns from. So it's clearly not something strictly limited to software or even just one type of software modeling. Barry Luijbregts  6:12  No, absolutely not. No, I don't think so. So, and then one way of applying those patterns, I think and making better and higher quality code is then using the solid principles. Can you tell me what those are and what what those are meant for? Steve Smith  6:29  Sure. So I suspect many of your listeners probably have already heard of solid but solid is a is a convenient acronym of acronyms for some object oriented design principles. And so real quickly, they stand for the single responsibility principle, the open closed principle, the liskov substitution principle, interface segregation principle, and then the dependency inversion principle. And these have been around some of them since the 80s. That's Two of them were first coined by professors and researchers in the 1980s. And the other three, I think were in the 90s. So they're they're not anything terribly new, although the acronym itself wasn't turned into solid until, you know, I don't know, probably 15 years ago. The first time I read about them, they were described in a book that didn't put them in that order. And so if you were going to make a word out of it, it wouldn't have been solid. It would have been like, oils or something. But yeah, so having having him as a name that you can actually say and pronounce. I think it certainly helps them from a marketing perspective. Barry Luijbregts  7:40  Yeah, definitely. So these are 10 principles, is that the same as patterns as in design patterns. Steve Smith  7:48  They're not that the idea is that you have principles that you can use when you're evaluating a design. And then you can use a pattern to try and change the design. implement a particular kind of design in a certain way. And then the nice thing about design patterns is that they're reusable. And so if you are faced with the same problem later on, you might be able to apply a pattern that's that's known to work on that problem. Either because you've used it before, just because other people in the industry know that this is a well known solution to this class of problem. Right? And so you want to use both you want to have principles are more abstract, they're, they're not something that's going to directly tell you exactly what to do. They don't have like a UML diagram that says, This is what this principle looks like. Right? Whereas a pattern is more specific, still broad still, like not something you could just copy paste into your code. But it's, it's like a recipe. It's like, okay, here are the basic things that you need to use this pattern, and then to apply it correctly, and so they're related and so you can use a pattern to To implement a principle or to fix a violation of a principle, if you will, but but they're, they're different. And then the other p that often goes along with those two, principle and pattern is practices, right? And so there's a bunch of books out there that talk about patterns and practices and principles. And I think they're, they're all related, right? And practices are things you actually do in the course of writing software that can be helpful. Barry Luijbregts  9:27  That's, that's a good distinction to keep in mind. And then principles are more guiding things that tell you the direction in which you might might go, and in which you then look for solutions that you might implement with the patterns. Right. So let's get into these the solid principles, like they're not new, of course, it's always good to repeat and maybe some of our listeners haven't heard of some of the principles. Steve Smith  9:55  Sure. And, and I've taken to saying recently that if you're a senior developer Upper right even whatever that means to you, you know that maybe that means you've got five years of experience or, you know, you you have people that you're mentoring. If you're at the level that you consider to be a senior developer using an object oriented language, like C sharp or Java, you should be able to teach people the solid principles. So, you know, if you're not at the point where you just know them and can teach them to someone else, you probably want to, to get to know them a little better, I would say. So, the first one is the S is the single responsibility principle. And that one basically says that your classes should be focused on doing one thing and doing it well. They should have one responsibility that they are all about doing and they should be cohesive meaning the things that are in that class, the state and the behavior that are married together within that, that classes encapsulation boundary should all be focused on the same thing. If you look at a class and you can easily see that you know, Half of the properties and methods work together and the other half work together. But separately, maybe that's two classes, right. And you could refactor that, to split it up into two classes that each did their own thing, and didn't have to worry about the other parts that the other one was doing. Barry Luijbregts  11:16  And does this only apply to the class level or also to the methods because in a class that has a certain responsibility, you could have a method that tries to do two three things, maybe that are slightly different as well. Steve Smith  11:29  Sure. And obviously, if you're following it at the class level, you want your methods to be focused. And there's other principles that apply and code smells, which is another whole topic that apply at the method level. But generally, these principles apply at the class level. Although it's certainly true that you know, if you if you have a class that follows single responsibility, its methods should be fairly small and focused on things within the realm of that responsibility. Barry Luijbregts  11:57  Yeah, I've seen people try to get away from It weird stuff, you know, that's 2000 lines of code class, Red Hat a certain responsibility, but then the methods to do all sorts of weird stuff.  Steve Smith  12:11  Yeah, well, and I don't know that it's clear what a responsibility is. So when I teach these principles, I try and lay out like, what are some examples of responsibilities, because it's all too easy for someone to say if I if I go back to the, you know, the simple shopping cart example I mentioned, it's very easy for someone to say that, you know, I've got a class called shopping cart manager. And it's only responsibilities to do anything and everything related to the shopping cart. And that includes checking out adding items, removing items, validating, checking all the prices, verifying all the sales, making sure you know, that the customer follows whatever discounts they have taken care of handling and calculating all the shipping and on and on none, right. So it's not, it's not correct to say that the responsibility is you know, everything to do with Some broad topic or some broad object within the system. Like that's, that's probably too big, you know. So things like validation or responsibility, persistence as a responsibility. interacting with other collaborators is a responsibility. deciding who your collaborators are is a responsibility. If you're if you're inside of the class and all of the things you're working with, you're newing up or calling statically. That class is deciding specifically what other things it's going to work with. And that's a separate responsibility. Right. That's something that could be done somewhere else.  Barry Luijbregts  13:34  Yeah, definitely. It's it's probably difficult to find the scope of the responsibility for yourself. It's it's a bit of common sense, of course. Steve Smith  13:43  Yeah, it takes it takes experience, I think and it takes Yeah, I mean, some of you could say it's common sense, but that's common sense. Isn't that common? And a lot of what I think of is common sense is, is really just experienced, but you have a hard time. You know, saying what it is exactly right. Yeah. So it's it can be hard, right? But at the end of the day, if you are following the single responsibility principle, what you'll find if you if you compare two projects, or two designs that do or don't follow it, is that you will tend to have more classes, and those classes will tend to be smaller. Right. So when we think about how that affects our practices, and maybe our tools, that means that we should get better at finding files in classes within our solution, and organizing them in such a way that it's easy for us to work with more files that are smaller. If you're only comfortable scrolling through 2000 line long classes, and you don't really have the the muscle memory or the experience of working with lots of small classes, then it's gonna feel unfamiliar to you. It's gonna, it's gonna there's gonna be friction, right? And so, moving toward following this principle sort of requires that you skill up In in working with smaller files, which isn't necessarily what, what a lot of developers are used to. Barry Luijbregts  15:05  no, no, I see a lot of them do it. Well. So this is very good. Good principle. All right. So that's the single responsibility principle. And the second one is the open closed principle. Right? Can you tell me about it? Steve Smith  15:21  So the open closed principle is sometimes confusing, because it says that your classes should be open to extension, but closed for modification. And what that means is that you should be able to change how your class works, what it does its behavior without actually changing its source code, without having to recompile it and redeploy the code to run it. And at first, oftentimes, if you've just hearing about this principle for the first time, you might scratch your head and be like, well, how the heck does that work? How am I going to change my code? Does without changing my code. But if you think about it, we do this all the time, right? The simplest way to take some code and change what it does without actually changing the code is to provide a parameter to it some kind of input that when you change that input, it changes what the code does just a parameter. And so a lot of how you implement the open closed principle is just about how we specify behavior by passing it in, in the form of parameters either at the method level, or as a constructor parameter or a property. Barry Luijbregts  16:33  So this could mean that if you have a constructor in a class that has a certain parameter that takes, let's say, a logging mechanism or something that you might be able to inject a completely different logging system in there, then they would originally have and therefore, change the behavior of the class to lock to a different system or different output for instance. Steve Smith  16:57  Sure, imagine that you wrote some code and you literally just hard coded all of your logging. And you said, I'm going to log everything to C colon backslash log dot txt. And you do and you write that code and you and it works great and you ship it. But then somebody wants to run this code, and they want to log it somewhere else, or they want to run it on Linux that you know, doesn't necessarily have a C, colon, backslash, right, or a Mac. And so now you're stuck, like you've hard coded too much into a particular implementation. And the only way to change it now is to recompile it because you've compiled all that stuff right into that routine that class. So like you said, If you instead passed in some type of a logger, class, or abstraction, or interface, and then you can implement it in such a way that maybe for you, it's fine for it to just log to a local file on your C drive. But someone else could implement that in a different way. And instead, it could be logging in any way you can imagine, right? It could go to a database, it could go to a different location, it could go to something some debug viewer, right? Yeah. And and so Now your code is open to extension and closed to modification, meaning you don't need to modify it. You don't have to change the source code now in order to get that that extended behavior. Barry Luijbregts  18:11  Yeah. Which is a great principle. And I think you shouldn't take this too far. Obviously, as in, if you have a database layer or data access layer that uses SQL server or something, you shouldn't always make it so that it can also use all sorts of other databases, for instance, right? Steve Smith  18:30  Now, yeah, not necessarily, right, every every way in which you allow your system to be extended, makes it more abstract, makes it generally more difficult to quickly understand what it's doing. So when you look at the code itself, and you try and see what like, what does this code actually doing, if it's very abstract, and there are a lot of ways that it's hooking into other things that are being passed in through parameters or constructors or dependencies, it can start to become difficult to figure out where the actual work is being done. And that's a common criticism that gets laid against, you know, overly abstract, overly designed object oriented systems. And so there's a balance here, right. And so you don't want to try and make your system extensible in every possible way up front. Instead, you want to wait and see where the changes are going to occur and where the pain is coming from. So I like to tell developers to follow PDD pain driven development. And if it's causing you pain, then use these principles or these patterns to find a way to alleviate that pain. If you if it's not causing any pain, right? If just logging straight to a sequel and text file is fine, and nobody's asking for anything else, then leave it alone. It's working. But But after the second or third time that somebody is asking for a new way to do something, you should recognize that this is an axis of change in your system. that's likely to continue to be an axis of change. And so consider making it extensible Barry Luijbregts  19:58  Yeah. Oh, that's a great That's a great principle. Pain driven development. I love that. Yeah, but it's definitely true. Especially even for things like performance optimizations, you know, I love to do performance optimizations myself, and I can just spend weeks on it. If you just let me. It's just it's usually really not necessary. Because it's fast enough, probably by default, and nobody asks for it as well. Right? So only if it's a problem, then you should really focus on it. Steve Smith  20:28  Yep, exactly. It's a it's a premature optimization. Yeah.  Barry Luijbregts  20:32  All right. So that is the open closed principle. And then the next one is liskov substitution principle. Can you tell me about that one? Steve Smith  20:40  Sure. So this is the only principle that's actually named for a real person, which is Barbara liskov, who's a professor at MIT. And she coined this back in the late 80s. And the idea is that your objects should not just be oh sorry if your objects that inherit from another object or type should not just be that thing, right, they shouldn't just have an is a relationship, like we hear so often when we first learned object oriented programming, instead, they should be substitutable for that base type, anywhere and everywhere that they might be used. And so where you commonly see violations of this principle is where you might have a fairly large class or interface that you're implementing. And you, you only need some of it right now. And so you you leave some of the bits either undone, or maybe they're throwing and not implemented exception. And so you ship your code like that. And later on, somebody comes along, and they need some, some some instance of this, this interface, this type, and they see that there's already one that's been made. There's there's a provider or an adapter or whatever you want to call it that you've created for them. And so they they inject that into their system and they expect it's just going to work. And at runtime, it blows up and it says not implemented. exception. Right. And so it wasn't fully substitutable for the parent. And that's that's the best case scenario. That's where it's, you know, obviously broken, right? Because it's giving you that exception. What's worse is when it's not really easily detectable that it's doing the wrong thing, or it's not doing what it should. And that's, that's a much tougher bug to find. One of the ways you'll see this manifest in your code, is if you're doing something that should be polymorphic. Like you have a for each over a bunch of types, but they might be not actually that type. There might be a subtype. And then inside your for each loop, or inside your method that takes an instance of this base class, you're checking to see which specific subclass they might have. Right? So you like, Hey, I'm going to print out all the employees. So I say for each employee in this collection of employees, and then inside your loop, you say, Well, if employee is manager type, then I want to do something different. Like right there. Your brain Making liskov substitution because now you're checking to see what kind of type this thing is it shouldn't matter, right? That's what polymorphism is all about is you should be able to treat it exactly like its base type. And if you can't, if you have to know what its actual type is, then you're breaking that principle of object oriented programming. Barry Luijbregts  23:18  That's it. That's a great principle. I see that a lot actually, in production API's still, yeah, that you hit something and then it's not implemented yet exception. Terrible, right? Steve Smith  23:29   And where that's really a problem is because of the duplication that it entails. So if if there's one place where you need to know that subtypes specific type, because you want to do something different, okay, that's not terrible, right? That's fine. But it tends to spread. So you know, in your application, it's not going to be just one place probably where you're checking that it's going to be everywhere, you're dealing with a set of that base type, right? There's going to be some exception for some certain type that's implemented a different way. And so now when whenever some new features comes along or some change needs to be made, you've got to remember to go to all those different places, and, you know, tweak them to make sure they work just right now. Or maybe you add another subtype, and it behaves even different still from the other ones, right? So again, you've got to go to all those places where you're not using polymorphism correctly, and make sure you've got enough checks in all the right places for that new behavior. And that's where that's where you end up missing some in bugs creeping? Barry Luijbregts  24:25  Yeah, that's definitely where the bugs creep in. Yeah. And those are difficult to find as well. Certainly. Alright. So that is a liskov substitution principle. And then the next one is interface segregation principle. What is that? Steve Smith  24:40  So really briefly, the interface segregation principle says that classes should not depend on methods that they don't use or functionality that they don't use. So if you have a class, and it depends on an interface, let's go back to that logger example. Right you you've got this method that will log a line of text But then it also has some method for, I don't know, copying the log file to a backup store, right? Well, your class doesn't care about that it only cares about logging stuff. But But now there's this other method that that's all about copying things to a different store. And if that method changes, then you're going to have to recompile your code because you depend on that, even though you're not using it. And so you end up having larger ripple effects from your changes. When you have larger interfaces. And you have classes depending on pieces of those interfaces. They don't use, they don't need. So the the general way to follow the interface segregation principle is to do two things. One is to have very small interfaces that are basically following the single responsibility principle doing just one thing well, and then to having clients control their interfaces. So instead of shipping interfaces with a framework or with some set of base classes that you know, the company Many architects put together when you're writing the actual service that needs the thing. You write the interface that exposes exactly what your service needs. And then you implement it with whatever you need to write. Barry Luijbregts  26:14  Yeah, and it's very specific. Steve Smith  26:16  Yeah. And this this way, it leads into the next principle, the dependency inversion. Because, you know, normally what, what developers, especially junior developers expect, is that someone's going to give them the the framework in which to work, right? They're gonna be like, okay, here's, here's the, the, the high level structure, you just fill in the details, including stuff like base interfaces and base objects and things like that. Yeah, interface segregation, kind of says, Hey, actually, as you're creating this service that you're writing, if there are certain things you need from other dependencies or other things, you know, create an interface that is specifically for your service, or at least specifically for services like yours. And so you may not end up with an interface for every single class that needs something that would probably be overkill. But you should have some very small, very cohesive interfaces that work with your set of services that all need sort of the same thing. The dependency inversion principle, I don't want to I don't want to skip over because I actually think it's probably the most important of these principles. And what it states is that you don't want to have your high level modules depending on low level modules. Instead, you want low level stuff to depend on high level. And that kind of presupposes that we know what high and low level means. So let's let's define that real quick. Low Level means closer to an input output, you know, closer to writing bits on disk or taking input from the user, right the user interface or the data access layer, talking to the file system. That's all low level stuff. High Level is more abstract and you know the the concepts of the overall software like, you know this, this customer wants to add this item to their cart, right? It doesn't know anything about specific operating systems or file formats or anything like that those are all low level details. All right. And then related to that the high level and low level modules shouldn't depend on specifics, they should depend on abstractions instead of the other way around. So it's what's commonly the case, if you don't follow this principle is that you write code that just depends directly on its infrastructure. So if we go back to that logging example that we've been using, you know, you write some simple console app, you want to log some stuff out. So inside of there, you just new up a file using the file system API's that are in the framework, and then start writing lines directly to that file. Right. There's no abstraction there at all. You're working directly with a low level file protocol. And you probably don't have any interface You wouldn't need any interfaces in that example, because it's just a, you know, program.cs console app. But as a result, it's it's not very testable. So very extensible. It doesn't really follow object oriented principles at all. And to get it closer to being able to do those things, which needs to do is introduce some abstractions, and then depend on those instead of the details. And where this plays in the biggest benefits. And what I've seen is when you switch from having a classic interior architecture, where you have a UI that depends on a business layer that depends on the data layer that depends on a database. That's the classic model that that folks have done for decades. That's what I cut my teeth on as a junior developer was building things like that in the late 90s, early 2000s. You if you switch that and you flip it on its head and you say, No, we're going to have the the low level, the data access layer, the file providers, all those low level two Things, instead of having the business layer depend on those, we're going to have those depend on the business layer. And if you start thinking about domain driven design, which which also have a course on Pluralsight about now that that domain model is your business layer, that's sort of the core of your application. And the infrastructure, the data access layer, depends on that core instead of the other way around. And that's, that's what the inversion is talking about the dependency inversion principle, is inverting the dependency. So instead of having your high level code depend on low level code, you flip that and it's the other way around, Barry Luijbregts  30:37  And because of that, you can also switch things out way more easy, the low level bits, or you can use another implementation or something like that writes to disk or writes to another database or whatever. Steve Smith  30:48  Right now your code is incredibly modular, and there are many seams in it that make it much easier to test. Barry Luijbregts  30:54  Alright. So those are the solid principles, which are great principles. To follow, but how do you embed those in the development process of a team? And make sure that everybody's following them? Steve Smith  31:09  I think the the best thing is to have everyone sort of know what they are, right? So have some sort of level setting, you know, some lunch and learn or everybody watch this Pluralsight course or some training or whatever, if necessary, right? If there isn't already that that understanding. But once people at least know what they are, then in whatever passes for code review on your team, whether that's pair programming, or formal code reviews, or looking at pull requests, be be very clear about which principles you're citing when you offer feedback related to those. So if you're working with someone, and you're pairing on a class, and you adding some functionality, and so you add another method to this class, and the class is getting bigger, and this new thing isn't really related to what we were doing before. You know, it would be perfectly reasonable to say, Hey, aren't we sort of breaking single responsibility principle here, maybe we should put this in a new class. Like that would be, you know, one way that you would implement it. And I think just that's, that's really the best way is for team members to keep these principles in mind when they're looking at code when they're designing code, either as they're writing it or as they're reviewing what others have written. And then use the principles as a way to evaluate the quality of the code. Barry Luijbregts  32:25  And then constantly try to identify them as well, if you see them or as you try to design your codes. Steve Smith  32:33  Yeah. I mean, if you see that they're being egregiously broken, right, then the principles are something that you can cite, right? It's not just you saying that, hey, I think that this is too big. You can say, well, this principle that's been around for decades that many people in the industry feel is a good thing suggests that maybe we should try and keep this smaller or keep this, you know, dependency at arm's length or whatever it might be. Barry Luijbregts  32:56  Exactly. That is, that is a great practice. I think lots of people already do that. Hopefully I've seen it a lot, especially during code reviews as well. I've had a lot of reviews where we also talked about the solid principles. So that's very good. And if you're not doing this yet, then please dive into these principles and to try to embed them in your, in your process. I do any additional resources that listeners might be able to visit to learn more about these principles. Steve Smith  33:31  Sure. So I've got a couple of Pluralsight courses that are relevant. I've got two different courses on solid principles. One of them has been archived, but you can still get to it from my author page on Pluralsight. If you don't have a Pluralsight subscription, you can use a trial from their homepage and you'll get like a 10 day period when you could watch whatever you want. I also have a podcast of my own, where sometimes I talk about these principles. I have some some episodes in the past. I've covered them Which is at https://weeklydevtips.com/ or on https://www.youtube.com/weeklydevtips channel. And you can also follow me if you like, I'm frequently talking about these things at conferences or on Twitter. So everywhere online, you'll find me as ardalis, which I'm sure will have a link to in the show notes. Barry Luijbregts  34:17  Absolutely. Yes, I will link to all of this in the show notes. This was delightful. Thank you very much for teaching me about the solid principles. And we'll see you next week on another episode of developer weekly. Steve Smith  34:31  Awesome. Thanks. Barry Luijbregts  34:35  Thank you for listening to another episode of developer weekly. Please help me to spread the word by reviewing the show on iTunes or your favorite podcast player. Also visit https://developerweeklypodcast.com/ for show notes and the full transcript. And if you'd like to support me in making the show, please visit my Pluralsight courses to learn something new.  

Video content can be found here: https://www.youtube.com/channel/UC0BAd8tPlDqFvDYBemHcQPQ/

Solid Principles in 6 mins

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 53, on the Liskov Substitution principle. Liskov Substitution Principle This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Need to level up your career? Looking for a mentor or a the support of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help members improve. Interested? Check it out at devBetter.com. Show Notes / Transcript We're in the middle of the SOLID principles this week, with the only one who is named after an individual. The Liskov Substitution Principle is named for professor Barbara Liskov, who teaches computer science at MIT. She gave a conference keynote some years ago in which she defined substitutability in object-oriented systems, essentially stating that one type could be considered substitutable for another if there were no situations in which the original type worked but the new one did not. The typical definition used today is that subtypes should always be substitutable for their base types. If this isn't the case, it likely means you have the wrong inheritance relationship, or your interface isn't cohesive enough, or there is some other code smell you should consider addressing through refactoring. So, although it isn't mentioned in the name, LSP is all about inheritance hierarchies. That's the first thing to remember. Many developers, myself included, learned about inheritance with the aid of the IS-A relationship. That is, you can consider using inheritance to model a problem if there are two related concepts and one IS-A more specific version of the other. You might have a Car class, with an SUV subclass. Or an Animal class with a Mammal subclass. These work because an SUV is a car and a mammal is an animal. Sometimes, though, you might have an IS-A relationship, but it's not sufficient and it leads you down the wrong OO design path. The classic geometry examples involve squares and rectangles and circles and ellipses. A square is a rectangle; a circle is an ellipse. But take care if you try and use inheritance to model them, since depending on how you do so you could introduce breaking changes into your application. Imagine if you have applications using your Rectangle type that assume they can independently set the height and width of the rectangle. Then someone introduces the Square type that inherits from Rectangle and implements height and width properties so that setting either one will set the other, too. This ensure the resulting type is always a square. But it also means that a method that takes in a rectangle and modifies its height and width to different values will break, because the first value set will be silently overwritten by the second. Another classic example involves birds. What if your base bird type includes methods like Fly and properties like Altitude? Then, someone introduces subtypes for Ostrich and Penguin. Trying to substitute these in to methods that expect certain behaviors from Fly and Altitude is likely to cause problems. The problem here is that the initial assumption that all birds can fly was inherently flawed. In business software, we don't usually worry about birds or squares, but we often model things like policies, accounts, orders, etc. and often there are different varieties of these concepts. You'll know when you're violating LSP when you see code that shouldn't care about the specific variety of something, but has to run a type check to do its work properly. A method takes in an Account, and then checks to see if Account Is PremiumAccount, for instance. This signals an LSP violation, and can usually be corrected with a refactoring that shifts behavior up or down the inheritance tree. Pretty much the only place where you might have a conditional on the specific type of an instance of a class is in a factory method that's responsible for creating that specific type. Otherwise, the Replace Conditional with Polymorphism refactoring is your friend. Use it to eliminate excessive conditional logic from your code by making proper use of inheritance in your object model. Obviously examples of these principles are tougher to describe in a podcast than in video, so to see them in action check out my courses on Pluralsight on the SOLID principles. I just produced a revised course for 2019, but my original SOLID principles of object-oriented design course is out there as well and uses different examples, so you might get benefit from seeing both of them. You'll find links to both in this episode's show notes. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring Fundamentals That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 49 on the Single Responsibility Principle. Single Responsibility This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript The Single Responsibility Principle, or SRP, is the S in the SOLID principles macronym. The short version of it is that a class should have only one reason to change. Specifically, the reason referred to here is tied to the application's requirements. Each class should only be required to change in response to a single change in the application's requirements. These requirements typically correspond to real world things. For example, let's say the application needs to display a report for quarterly sales performance. The system's requirements might be that the report be rendered in a browser, that it include all sales for a given quarter grouped by individual sales representative. Either of these requirements might change in the future. Perhaps the reports need to be emailed as PDFs. Perhaps they need to be calculated monthly instead of quarterly or rolled up by sales region. Ideally, the format of the report and the details of how it is calculated should be separate responsibilities of separate classes. Why is SRP important? Back in episode 15, Maintain Legacy Code with New Code, I explain one reason. Every time you change a class, you risk breaking classes that work with it. When a class has multiple responsibilities, it will likely need to change more often. Also, it's likely these responsibilities will be tightly coupled together by the class, making it harder to change them independently and further increasing the inherent risk of changing them. Let's say you have to fix a bug in an application. Would you rather have to work in a single class that literally only does the thing that has the bug in it, or would you prefer to work in a 2000 line long class that does 10 different things, all of which are intermixed in the class's 50 methods and properties? I know which one I prefer. Too often, developers new to SOLID will hear about SRP and misunderstand a bit what a responsibility really is. They might have a class they've carved out from the rest of the application. Something like CustomerManager. They'll happily explain how CustomerManager is only responsible for Customers in the application, and thus is following SRP. But upon reviewing the code, it's clear that CustomerManager is responsible for Customer validation, Customer persistence, and Customer formatting for various user interfaces. It's responsible for notifying Customers when they place orders and oh yeah, it also is responsible for Customers placing orders, as well as managing their orders and their payment providers and their account history. But don't worry - CustomerManager only has one responsibility: Customers! Although I said responsibilities typically map to business requirements, they don't typically map to entities like customers or orders or policies. This is because these entities will often have a lot of rich behavior that can be isolated into separate responsibilities, often with cross-cutting concerns within the application. For instance, how a customer is validated will likely be very similar to how an order is validated. The same goes for persistence and UI formatting and a host of other activities. Each of these is a responsibility, and should be isolated in its own class. Now, it might seem like breaking up big classes into small ones is going to result in a lot more code, but often just the opposite occurs. As you pull cross-cutting concerns like validation, persistence, logging, notifications, formatting, etc. into their own classes, you'll often find ways to standardize the codebase and reuse these classes. A common way to achieve this reuse is through the strategy pattern, which I discuss in episode episode 19. The Strategy pattern lets you move responsibilities out of a class by delegating to other classes, which are often defined as fields or properties on the original class. These fields or properties have their instances set by having them passed in through the constructor, in what's commonly called dependency injection. Dependency injection and the strategy design pattern go hand-in-hand, and are my favorite way to refactor to achieve SRP in classes that I find have too many responsibilities. If you'd like to learn more about SRP and SOLID, check out my newly revised course, SOLID Principles for C# Developers, on Pluralsight. It's a complete update of my original SOLID Principles of Object Oriented Design course that has been in the top 100 for Pluralsight since it was published in 2010. The new one is shorter and streamlined, though it doesn't cover some topics the original course has. The new course also uses Visual Studio 2019 and has all of its course samples on GitHub. Check both of them out and let me know what you think. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring Fundamentals That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 47, in which we'll introduce the SOLID principles. I'll spend a little time reviewing these principles in the upcoming episodes. What are the SOLID principles of object-oriented design? Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript Depending on how long you've been programming, you may have heard of the SOLID principles. These are a set of 5 principles that have been around for several decades, and about 15 years ago someone - I think it was Michael Feathers - had the idea to arrange them in such a way that they formed the macronym SOLID. Prior to that, I think the first time they were all published together was in Robert C. Martin's 2003 book, Agile Software Development: Principles, Patterns, and Practices in which their sequence spelled SOLDI - so close! This same sequence was used in the 2006 book Agile Principles, Patterns, and Practices in C#. So what are the SOLID principles? As I mentioned, SOLID is a macronym, meaning it is an acronym formed by other acronyms. In this case, these are SRP, OCP, LSP, ISP, and DIP. All those Ps at the end of each acronym stand for principle, of course. Listing each principle, we have: Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion You may already be familiar with these principles. If you're a developer who's using a strongly typed language like C# or Java, you should be extremely familiar with them. If you're not, I recommend digging into them more deeply. Applying them can make a massive difference in the quality of code you write. How do I define quality? Well, that's probably a topic I could devote an episode to, but the short version is that quality code is code that is easy to understand and easy to change to suit new requirements. It's easily and quickly tested by automated tests, which reduces the need for expensive manual testing. And it's loosely coupled to infrastructure concerns like databases or files. How do these principles help you to write quality code? They provide guidance. You need to write code that solves a problem, first and foremost. But once you have code that does that, before you call it done and check it in, you should evaluate its design and see if it makes sense to spend a few moments cleaning anything up. Back in Episode 6 - you are listening to these in sequential, not reverse, order, right? - I talked about Kent Beck's approach of Make It Work, Make It Right, Make It Fast. SOLID principles should generally be applied during the Make It Right step. Don't apply them up front, but as I discussed in Episode 10, follow Pain Driven Development. If you try to apply every principle to every part of your codebase from the start, you'll end up with extremely abstract code that could do anything but actually does nothing. Don't do that. Instead, build the code you need to solve the problem at hand, and then evaluate whether that code has any major code smells like I discussed in episode 30. One huge code smell is code that is hard to unit test, meaning it's hard to write an automated test that can just test your code, without any external infrastructure or dependencies like databases, files, or web servers. Code that is easy to unit test is generally easy to change, and code that has tests is also easier to refactor because when you're done you'll have some degree of confidence that you haven't broken anything. In upcoming episodes, I'll drill into each principle a bit more. I've published two courses on SOLID at Pluralsight where you can obviously learn a lot more and see real code as opposed to just hearing me through a podcast. The first one was published in 2010 and so the tools and look were a bit dated. The more recent one is slimmed down and uses the latest version of Visual Studio and .NET Core. There are links to both courses in the show notes - the original one also covers the Don't Repeat Yourself principle. Let me wrap this episode up with a very brief overview of each principle. The Single Responsibility Principle is generally applied to classes and suggests that classes should have only one responsibility, which can also be thought of as one reason to change. Responsibilities include things like business logic, ui logic, data access, and more. Following this principle, you'll tend to have smaller, more focused classes. The Open/Closed Principle suggests that you should be able to change the behavior of your system without changing its source code. This generally relies on some kind of parameter or plug-in capability to provide new behavior to an existing class or service. The Liskov Substitution Principle cautions against creating inheritance hierarchies in which child types are not 100% substitutable for their base types. When violated, this can result in messy code and bugs. The Interface Segregation Principle suggests that classes that use interfaces should use all or most of the interface's exposed members. This then leads to interfaces that are small, focused, and cohesive, much like SRP. Finally, the Dependency Inversion Principle recommends that low-level concerns depend on high level concerns, not the other way around. This means for example that business layer code shouldn't directly depend on data access code, but rather an abstraction should exist that the business code works with and that the data access code implements. At runtime, the data access code will be provided as an implementation of the interface the business code is written to work with, providing loose coupling and more testable code. Show Resources and Links devBetter SOLID Principles for C# on Pluralsight Refactoring Fundamentals on Pluralsight SOLID Principles of Object Oriented Design on Pluralsight (published in 2010) Agile Software Development: Principles, Patterns, and Practices on Amazon Agile Principles, Patterns, and Practices in C# on Amazon See Visualizations and Subscribe to WeeklyDevTips in YouTube Clean Code on Amazon That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Кто ходит в гости к нам в подкаст, тот поступает мудро. В данном выпуске у нас было двое мудрецов, которые, надеемся, превратятся в постоянных посетителей. С ними мы расставили точки над темой Full-Stack, немного поспорили про необходимость async-await, погрузились в тему Fat Controllers. Ссылки: Demystifying Async/Await: https://chrisstclair.co.uk/demystifying-async-await/?utm_source=csharpdigest&utm_medium=email&utm_campaign=featuredО том, как из C# я перешел в Elixir/Phoenix: https://habr.com/en/post/435796/When to use C# LINQ with Query Syntax over Method Syntax: https://michaelscodingspot.com/when-to-use-c-linq-with-query-syntax-over-method-syntax/?utm_source=csharpdigest&utm_medium=email&utm_campaign=featuredVisualizing thin ASP.NET Controllers via SOLID Principles: https://makingloops.com/visualizing-thin-controllers/?utm_source=csharpdigest&utm_medium=email&utm_campaign=featured6 types of code you shouldn’t have inside your .NET controllers: https://makingloops.com/fat-controller-causes/?utm_source=csharpdigest&utm_medium=email&utm_campaign=featured Скачать: https://dotnetmore.ru/wp-content/uploads/2019/04/DotNetAndMore-11-FatControllers.mp3 https://dotnetmore.ru/wp-content/uploads/2019/04/DotNetAndMore-11-FatControllers.mp3

This will be our last session Marko Kunic , we will be discussing Solid Principles by Uncle Bob, we will also touch on the future of PHP.  Marko is currently a Software Engineer at Lendable and has been working professionally with PHP for several years. He enjoys doing open source and making other developers job easier, loves helping people, learning new things and reading software books.   You can connect with Marko on:   https://twitter.com/kunicmarko20 https://github.com/kunicmarko20 https://linkedin.com/in/kunicmarko20   If you liked this episode and want more on this topic click here: https://c2bsolutions.podbean.com/    We would love to stay connected with you   Contact us to discuss how we can help you recruit PHP Developers today!    Visit our website: www.c2bsolutions.co.uk  Call us on - 01582 965330  Email - Info@c2bsolutions.co.uk Linkedin - https://www.linkedin.com/showcase/php-division-c2b/ Twitter - @c2bsolutionsuk    

Why Laravel This week I am speaking to a champion in the Technical community. Clement  started his career as an intern and working his way up to a Technical Lead with experience leading a team. As a FullStack developer, His skills entail PHP, Symfony, Laravel, BDD,TDD, Solid Principles, Mobile development etc. You can see more on;  https://clem.io/ .For more on our PHP Jobs - Visit - Www.c2bsolutions.co.uk .  You can learn Laravel from Scratch- click here  You can see more on Advanced Laravel - click here Follow our Jobs on Instagram - click here 

The SOLID principles were proposed by Robert C. Martin to make software designs more understandable, flexible and maintainable. During our first podcast Paul, David and Christian will dig deeper into these five legendary design principles and discuss which experiences they made by using them during their daily work.

Why Laravel This week I am speaking to a champion in the Technical community. Clement  started his career as an intern and working his way up to a Technical Lead with experience leading a team. As a FullStack developer, His skills entail PHP, Symfony, Laravel, BDD,TDD, Solid Principles, Mobile development etc. You can see more on;  https://clem.io/ .For more on our PHP Jobs - Visit - Www.c2bsolutions.co.uk .  You can learn Laravel from Scratch - click here  You can see more on Advanced Laravel - click here Follow our Jobs on Instagram - click here   

SOLID is a mnemonic acronym for five core principles to designing and implementing solid object oriented code. They can and should be applied to any object oriented design and serve as the core of certain methodologies built around OOP such as agile. The goal of the principles is to make it easier to develop, maintain, and scale. Read more › The post SOLID Principles appeared first on Complete Developer Podcast.

In this episode we talk about the SOLID principles with Steve Smith (Ardalis) S - Single Responsibility O - Open/Closed L - Liskov Substitution I - Interface Segregation D - Dependancy Inversion Contacting Steve Smith Website:  Podcast:  Twitter:  Github:  LinkedIn:  Pluralsight:  Other Links: Dev IQ: 

Lake Michigan Christian Center

Panel: Ward Bell Alyssa Nicoll John Papa Joe Eames Charles Max Wood Special Guests: Peter Bacon Darwin and Megan Kingdom-Davies In the episode of Adventures in Angular the panel speaks with Peter Bacon Darwin and Megan Kingdom-Davies. Peter is an Angular Developer, known for maintaining AngularJS and the creator of Jammy. Megan is an event organizer with White October Events in the UK and has organized the Angular Connect Event. The panel and guest discuss the great environment of the conference and the business and community connections they form during the conference. In particular, we dive pretty deep on: •Angular Connect Conference details and what it is about Who is it for? What is the selling point? Creating contacts and connections Office hours of the conference Informal conference events Meeting new people in the community Closed Captioning Diversity and inclusion of the community Facilities available for gender, religious, physical, and psychological specifics How many attendees and how big is the conference - 1100 attendees/ 60 speakers Big announcements?  Angular Elements  Mobex Chicken Dance and much more! Links:  Megan Kingdom-Davies Peter Bacon Darwin http://www.bacondarwin.com angularconnect.com Picks: Charles Why are you using AngularJS? Email or Tweet ar @cmaxw Joe •NG Conf. Cabin Pressure Joe’s Plural Sight Course on Migration  Ward Burke Holland How to uppercase a stray envious code Peter Video talking about Jenny https://www.youtube.com/watch?v=VkSmaFAuaH4 John Psych Shai Solid Principles of OO  Peter Stack Blitz Soonish     

Panel: Ward Bell Alyssa Nicoll John Papa Joe Eames Charles Max Wood Special Guests: Peter Bacon Darwin and Megan Kingdom-Davies In the episode of Adventures in Angular the panel speaks with Peter Bacon Darwin and Megan Kingdom-Davies. Peter is an Angular Developer, known for maintaining AngularJS and the creator of Jammy. Megan is an event organizer with White October Events in the UK and has organized the Angular Connect Event. The panel and guest discuss the great environment of the conference and the business and community connections they form during the conference. In particular, we dive pretty deep on: •Angular Connect Conference details and what it is about Who is it for? What is the selling point? Creating contacts and connections Office hours of the conference Informal conference events Meeting new people in the community Closed Captioning Diversity and inclusion of the community Facilities available for gender, religious, physical, and psychological specifics How many attendees and how big is the conference - 1100 attendees/ 60 speakers Big announcements?  Angular Elements  Mobex Chicken Dance and much more! Links:  Megan Kingdom-Davies Peter Bacon Darwin http://www.bacondarwin.com angularconnect.com Picks: Charles Why are you using AngularJS? Email or Tweet ar @cmaxw Joe •NG Conf. Cabin Pressure Joe’s Plural Sight Course on Migration  Ward Burke Holland How to uppercase a stray envious code Peter Video talking about Jenny https://www.youtube.com/watch?v=VkSmaFAuaH4 John Psych Shai Solid Principles of OO  Peter Stack Blitz Soonish     

Panel: Ward Bell Alyssa Nicoll John Papa Joe Eames Charles Max Wood Special Guests: Peter Bacon Darwin and Megan Kingdom-Davies In the episode of Adventures in Angular the panel speaks with Peter Bacon Darwin and Megan Kingdom-Davies. Peter is an Angular Developer, known for maintaining AngularJS and the creator of Jammy. Megan is an event organizer with White October Events in the UK and has organized the Angular Connect Event. The panel and guest discuss the great environment of the conference and the business and community connections they form during the conference. In particular, we dive pretty deep on: •Angular Connect Conference details and what it is about Who is it for? What is the selling point? Creating contacts and connections Office hours of the conference Informal conference events Meeting new people in the community Closed Captioning Diversity and inclusion of the community Facilities available for gender, religious, physical, and psychological specifics How many attendees and how big is the conference - 1100 attendees/ 60 speakers Big announcements?  Angular Elements  Mobex Chicken Dance and much more! Links:  Megan Kingdom-Davies Peter Bacon Darwin http://www.bacondarwin.com angularconnect.com Picks: Charles Why are you using AngularJS? Email or Tweet ar @cmaxw Joe •NG Conf. Cabin Pressure Joe’s Plural Sight Course on Migration  Ward Burke Holland How to uppercase a stray envious code Peter Video talking about Jenny https://www.youtube.com/watch?v=VkSmaFAuaH4 John Psych Shai Solid Principles of OO  Peter Stack Blitz Soonish     

Show notes: Uncle Bob talk on SOLID Principles of Object Oriented and Agile Design (https://www.youtube.com/watch?v=TMuno5RZNeE) Briefs.fm (http://briefs.fm)

How do the SOLID principles apply to .NET? Carl and Richard talk to Chris Klug about his experiences using SOLID to build reliable, maintainable and scalable project. The conversation walks through the five principles of SOLID with an eye to practical applications in .NET - what does a well implemented single responsibility look like? How does it work with patterns like MVVM? Chris shares his thoughts and coding approaches on a great debate about practical vs ideal implementations in SOLID.Support this podcast at — https://redcircle.com/net-rocks/donations

How do the SOLID principles apply to .NET? Carl and Richard talk to Chris Klug about his experiences using SOLID to build reliable, maintainable and scalable project. The conversation walks through the five principles of SOLID with an eye to practical applications in .NET - what does a well implemented single responsibility look like? How does it work with patterns like MVVM? Chris shares his thoughts and coding approaches on a great debate about practical vs ideal implementations in SOLID.Support this podcast at — https://redcircle.com/net-rocks/donations

02:48 - Jim Gay Introduction Twitter GitHub Blog Ruby DSL Handbook 03:43 - Object Design Clean Ruby SOLID Principles 04:39 - DCI (Data, Context, Interaction) Main Resource for DCI (FullOO) 07:20 - What Painpoint DCI Aims to Solve The Gang of Four Book object-composition Mailing List (Google Group) 09:31 - Designing From DCI From the Start (Process) Levels of Use Cases Writing Effective Use Cases by Alistair Cockburn 11:42 - Object Composition Single Responsibility Principle 13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance Class-Based Inheritance vs Prototype-Based Inheritance JavaScript Influence 18:37 - DCI and Service Objects Context 24:36 - Roles and Object Factoring Authentication 28:49 - One Context in a Single File surrounded 30:17 - Coupling and Cohesion 31:37 - Typeclasses 33:09 - DCI Criticism casting 36:51 - The Current State of DCI (Skepticism & Criticism?) Domain-Driven Design 38:56 - Preventing Reuse 41:18 - When should you not use DCI? 43:45 - Transition: Using/Undoing DCI (Experimentation) 45:04 - Resources fulloo.info Marvin object-composition Mailing List (Google Group) Clean Ruby More DCI Blog Posts by Jim Delegation Is Everything And Inheritance Does Not Exist Chubby Models Are Still Fat With Concerns. DCI Focuses On How Things Work Together The Gang Of Four Is Wrong And You Don't Understand Delegation Triggering The DCI Context OOP, DCI And Ruby - What Your System Is Vs. What Your System Does 4 Simple Steps - Extending Ruby Objects - The Tip Of The Iceberg With DCI Picks Richard Hamming: You and Your Research (Jessica) Martin Fowler: Yagni (Coraline) Ruby Monday (Saron) JunkFill (Saron) Wappalyzer (Saron) WhatFont (Saron) Julian Feliciano: What Is Source Control? (Saron) Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi) The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim) request_store_rails (Jim) littleBits (Jim)

02:48 - Jim Gay Introduction Twitter GitHub Blog Ruby DSL Handbook 03:43 - Object Design Clean Ruby SOLID Principles 04:39 - DCI (Data, Context, Interaction) Main Resource for DCI (FullOO) 07:20 - What Painpoint DCI Aims to Solve The Gang of Four Book object-composition Mailing List (Google Group) 09:31 - Designing From DCI From the Start (Process) Levels of Use Cases Writing Effective Use Cases by Alistair Cockburn 11:42 - Object Composition Single Responsibility Principle 13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance Class-Based Inheritance vs Prototype-Based Inheritance JavaScript Influence 18:37 - DCI and Service Objects Context 24:36 - Roles and Object Factoring Authentication 28:49 - One Context in a Single File surrounded 30:17 - Coupling and Cohesion 31:37 - Typeclasses 33:09 - DCI Criticism casting 36:51 - The Current State of DCI (Skepticism & Criticism?) Domain-Driven Design 38:56 - Preventing Reuse 41:18 - When should you not use DCI? 43:45 - Transition: Using/Undoing DCI (Experimentation) 45:04 - Resources fulloo.info Marvin object-composition Mailing List (Google Group) Clean Ruby More DCI Blog Posts by Jim Delegation Is Everything And Inheritance Does Not Exist Chubby Models Are Still Fat With Concerns. DCI Focuses On How Things Work Together The Gang Of Four Is Wrong And You Don't Understand Delegation Triggering The DCI Context OOP, DCI And Ruby - What Your System Is Vs. What Your System Does 4 Simple Steps - Extending Ruby Objects - The Tip Of The Iceberg With DCI Picks Richard Hamming: You and Your Research (Jessica) Martin Fowler: Yagni (Coraline) Ruby Monday (Saron) JunkFill (Saron) Wappalyzer (Saron) WhatFont (Saron) Julian Feliciano: What Is Source Control? (Saron) Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi) The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim) request_store_rails (Jim) littleBits (Jim)

02:48 - Jim Gay Introduction Twitter GitHub Blog Ruby DSL Handbook 03:43 - Object Design Clean Ruby SOLID Principles 04:39 - DCI (Data, Context, Interaction) Main Resource for DCI (FullOO) 07:20 - What Painpoint DCI Aims to Solve The Gang of Four Book object-composition Mailing List (Google Group) 09:31 - Designing From DCI From the Start (Process) Levels of Use Cases Writing Effective Use Cases by Alistair Cockburn 11:42 - Object Composition Single Responsibility Principle 13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance Class-Based Inheritance vs Prototype-Based Inheritance JavaScript Influence 18:37 - DCI and Service Objects Context 24:36 - Roles and Object Factoring Authentication 28:49 - One Context in a Single File surrounded 30:17 - Coupling and Cohesion 31:37 - Typeclasses 33:09 - DCI Criticism casting 36:51 - The Current State of DCI (Skepticism & Criticism?) Domain-Driven Design 38:56 - Preventing Reuse 41:18 - When should you not use DCI? 43:45 - Transition: Using/Undoing DCI (Experimentation) 45:04 - Resources fulloo.info Marvin object-composition Mailing List (Google Group) Clean Ruby More DCI Blog Posts by Jim Delegation Is Everything And Inheritance Does Not Exist Chubby Models Are Still Fat With Concerns. DCI Focuses On How Things Work Together The Gang Of Four Is Wrong And You Don't Understand Delegation Triggering The DCI Context OOP, DCI And Ruby - What Your System Is Vs. What Your System Does 4 Simple Steps - Extending Ruby Objects - The Tip Of The Iceberg With DCI Picks Richard Hamming: You and Your Research (Jessica) Martin Fowler: Yagni (Coraline) Ruby Monday (Saron) JunkFill (Saron) Wappalyzer (Saron) WhatFont (Saron) Julian Feliciano: What Is Source Control? (Saron) Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi) The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim) request_store_rails (Jim) littleBits (Jim)

Welcome to the 4th Episodes of AskDeveloper Podcast, in this episdoes we start our journey talking about design and we start by discussing * Why to Design * Architecture vs Design * Design Principles (SOLID Principles) * Design but not Over engineer

In this episode we present you a recast of Solid Principles' Episode 33, The United States Plus One: The Prospect of Puerto Rico As the 51st State brought to you with kind permission from our friends and producers of the episode Craig Edwards and John Cronin from solidprinciples.com. You can link to their page at www.solidprinciples.com, to listen to this and other Solid Principles podcasts and access their blog. Solid Principles can also be found in Facebook, Twitter, and through their Solid Principles You Tube Channel. Please visit them as they were kind enough to let us recast their episode on Puerto Rico.The following episode will serve as our third and final installment in our series The Haunting of HR 2499. Music by Apollo 440, ''Crazee Horse,'' Arcade Fire, ''Wake Up,'' Dredg, ''Ode to the Sun,'' and Dropkick Murphy's, ''Amazing Grace.''

Scott sits down with Robert C. Martin as Uncle Bob helps Scott understand the SOLID Principles of Object Oriented Design.