Podcasts about dependency inversion

In this episode of the Mob Mentality Show, we are excited to have Dave Copeland share his experiences in the world of agile development, focusing on the critical nuances behind well-known principles such as SRP (Single Responsibility Principle), YAGNI (You Aren't Gonna Need It), DRY (Don't Repeat Yourself), and the often-debated #NoEstimates approach. Drawing from his journey transitioning from government waterfall projects to agile methodologies at a startup, Dave kicks off a discussion with invaluable lessons on how teams can avoid misunderstanding and misapplying agile aphorisms, or avoid the pitfalls of following agile aphorisms too woodenly. ### The Dangers of Following the Literal Words of Agile Aphorisms? Have you ever seen a team stuck arguing over what SRP or SOLID (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) truly means? Dave explains how teams can misinterpret these catchy phrases, leading to confusion, low cohesion, improper coupling, and poor decision-making. We dive into real-world examples from Dave's experience, discussing when it's okay to duplicate code and when it's not, the delicate balance between over-engineering and under-engineering, and the importance of nuance in agile practices. ### "Just Sharing" vs. Universal Recommendations Is it wise to blindly follow every "recommendation" from an agile coach, or is there room for discussion, experimentation, and adaptation? With Dave we tackle the common issue of semantic diffusion. We explore how teams can navigate complex situations and adapt agile and lean principles to their unique contexts. ### Organizational Change and Safe Learning Environments We bring in the “Reading Rainbow” analogy and other examples to illustrate how organizational change needs to be gradual, allowing for nuanced learning. We also emphasize the importance of creating an environment where team members can safely fail while being guided by experienced developers in real-world contexts. Whether you're scaling a team or trying to stack the deck with the right mix of skills, actionable strategies for fostering growth are discussed.  ### Estimates, #NoEstimates, and Dealing with Uncertainty The conversation gets even more interesting as we delve into the jarring #NoEstimates and its sometimes misunderstood implications. Dave brings up valid situations with real deadlines (e.g., seasonal deliveries, regulations) and we weigh-in on ways to handle them with or without estimates that are less likely to lead to self-sabotage. We also discuss the impact of automation on estimates, and what terms like "estimate" really mean. Continuous Delivery (CD) also takes center stage as we discuss examples of how it and the practice of "don't sell what you don't already have built" fosters trust and reduces uncertainty. We touch on the various unknowns that can arise in development, how CD can help mitigate them, and whether teams can benefit from an "#OptionalEstimates" mindset. Throughout, Dave provides practical advice on aligning practices with business goals and managing risks effectively. ### Coaching, Coding, and Higher-Level Roles Finally, we explore Dave's thoughts on balancing hands-on coding with coaching responsibilities, especially in higher-level roles. How do you set expectations for coaches, and how can team composition shape the effectiveness of good practices? Whether you're actively writing code or stepping back to guide others, Dave shares examples for making both approaches work. Don't miss this episode packed with deep dives into agile practices, team dynamics, and nuanced leadership. Be sure to subscribe to the Mob Mentality Show on your favorite platform to catch this episode and others like it! Video and Show Notes: https://youtu.be/IPFYe_oOFtI  

00:00:00 - Вступ, починаємо говорити про DI. Оффтоп про чи настільки різні RxJava і RxJava2 і механіків.00:09:39 - Dependency Inversion. Проблема інтерфейсів.00:23:00 - Офтоп про рефлексію і метапрограмування в цілому. Ще трохи болю про інтерфейси та Retrofit2.00:30:17 - Офтоп про митець чи виконавець. Розуміння концептів. 00:33:48 - Офтоп про MVVM vs MVI. Ще про митців і виконавців.00:43:17 - Офтоп про Go, Python, Rust, C++ та JavaScript.01:02:05 - Нарешті про те, що таке Dependency Injection і навіщо воно потрібне (спойлер: не тільки для тестів).Коментарі та побажання можна залишити в нашому телеграм чаті.Support the show Тут для вас є ще більше нашого контенту Hosted on Acast. See acast.com/privacy for more information.

В цьому випуску 00:00:00 - Вступ, починаємо говорити про DI. Оффтоп про чи настільки різні RxJava і RxJava2 і механіків.00:09:39 - Dependency Inversion. Проблема інтерфейсів.00:23:00 - Офтоп про рефлексію і метапрограмування в цілому. Ще трохи болю про інтерфейси та Retrofit2.00:30:17 - Офтоп про митець чи виконавець. Розуміння концептів. 00:33:48 - Офтоп про MVVM vs MVI. Ще про митців і виконавців.00:43:17 - Офтоп про Go, Python, Rust, C++ та JavaScript.01:02:05 - Нарешті про те, що таке Dependency Injection і навіщо воно потрібне (спойлер: не тільки для тестів).Згадано в випускуПідтримай нас на Patreon

Подивитись відео на YouTube 00:00:00 - Вступ, починаємо говорити про DI. Оффтоп про чи настільки різні RxJava і RxJava2 і механіків.00:09:39 - Dependency Inversion. Проблема інтерфейсів.00:23:00 - Офтоп про рефлексію і метапрограмування в цілому. Ще трохи болю про інтерфейси та Retrofit2.00:30:17 - Офтоп про митець чи виконавець. Розуміння концептів. 00:33:48 - Офтоп про MVVM vs MVI. Ще про митців і виконавців.00:43:17 - Офтоп про Go, Python, Rust, C++ та JavaScript.01:02:05 - Нарешті про те, що таке Dependency Injection і навіщо воно потрібне (спойлер: не тільки для тестів).Коментарі та побажання можна залишити в нашому телеграм чаті.Support the show

This episode features Mitch Goldstein, Enterprise Agile Strategist at Box.com. Mitch shares his technique for identifying and removing dependencies between agile teams at scale. This episode is hosted by Agile Uprising Board Member, Troy Lightfoot Prioritization Podcast Mentioned Support the Agile Uprising If you enjoyed this episode, please give us a review, a rating, or leave comments on iTunes, Stitcher or your podcasting platform of choice. It really helps others find us.  Looking for real-time interaction and conversation with other practitioners?  Jump into the fray at our Discord Server! We at the Agile Uprising are committed to being totally free.  However, if you'd like to contribute and help us defray hosting and production costs we do have a Patreon.  Who knows, you might even get some surprises in the mail!

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.

Today's show marks our reaching of the final letter in our discussion of SOLID, the D, which stands for the Dependency Inversion principle! We kick things off with a bit of research on exactly what the Dependency Inversion principle states, and from there we unpack what implementing it in the real world might look like. Our conversation is all about the idea that pieces of your code should be decoupled and you can do this using interfaces. We discuss how the Dependency Inversion principle might be applied when you are connecting to databases, how it relates to inversion of control and ways of implementing it other than dependency injection.

In this episode of Adventures in .NET the panel interviews Patrick Smacchia who is known for his static analyzer, NDepend. The panel discusses NDepend, Patrick explains a bit about what is and how it works along with his history in .NET. Patrick is here to explains SOLID, an acronym introduced by Robert C. Martin outlining principles for object-oriented programming.  These principles teach programmers to use object-oriented programming correctly. The panel considers what can go wrong when object-oriented programming is misused. They also explain that the most important thing when it comes to SOLID is to try your best, it is impossible to be perfect in anything. Patrick explains that when your code is SOLID is will be easily testable and maintainable.  The five principles are Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. Of all the principles, Single Responsibility is unique. Patrick explains that this principle is all about organization and advises developers to be very careful when using this principle in your domain. The domain is where it is most important to have SOLID code and it needs to be 100% covered by testing. The panel shares that this is the principle that they try the hardest to follow.   The definition given by Patrick for Single Responsibility is that a class should have a single responsibility or a class should have only one reason to change. Patrick warns the listeners that this is a very complex concept that is difficult to explain. The panel explains that Single Responsibility is a way to accomplish a separation of concern. The panel outlines the benefits of following this principle while Patrick shares some examples and walk the listeners implementing this principle.  The next principle is Open-Closed. Patrick’s definition of this principle is modules should be open for extension but closed for modification. He and the panel dive deeper into what this means. He advises developers when designing a class to be very careful when choosing the point of variation and make sure you don’t change the code in your base class. Caleb shares the problems they experienced in one of his recent projects when this principle was not followed. Patrick explains why the solution is more often the interface rather than the base class.  Moving on to the next principle, the Liskov substitution. Patrick explains how this principle using the example of the ibird. The Liskov substitution principle is that objects in a program should be replaceable so that you can’t tell the difference. In the ibird example, you can not replace the ibird with any bird because if the ibird can fly but the replacement bird is an ostrich it cannot perform the necessary functions. Patrick explains how ilists are in opposition to the Liskov principle.   Next is the Interface Segregation Principle. Patrick explains how this relates to the Single Responsibility Principle. He also discusses how the Liskov Substitution and the Interface Segregation are two sides of the same coin when it comes to designing interfaces. The Interface Segregation explains that many smaller client-specific interfaces are better that one large interface with everything on it.  The final principle is Dependency Inversion. Patrick explains that this principle does not help you design your interface, it helps you organize dependencies into your code structure.   This principle advises developers to depend on abstractions. He explains how this principle relates to dependency injection. The panel considers the damage dependencies can cause in a codebase if improperly used. Patrick explains when a developer will want to use abstractions and when to use classes. He explains that these 5 principles will become natural and feel like common sense as developers gain experience. Switching gears, the panel moves on to discuss a blogpost Patrick wrote explaining 4 predictions he had for the future of .NET. He wrote the article because of the announcement that .NET core will become .NET 5. The future of .NET has a great impact on NDepend and Patrick wanted to give some perspective to the changes and how they might affect his company.   His first prediction is that .NET standards won’t evolve much. Patrick explains that the purpose of .NET Standards was to support all the .NET flavors and with only .NET to support that job will become much simpler. He also speculates on the reasons for Microsoft wanting only one .NET. Some of the reasons he lists are that Microsoft does not have an endless workforce and .NET core is open source and multiplatform.  Patrick’s second prediction greatly impacts NDepend. His prediction is that Visual Studios will run on .NET 5, explaining why he is so sure that they will switch Visual Studios over to .NET 5. Patrick believes that it may take a while for the switch to happen. The panel considers the future of Windows.  The third prediction Patrick makes is that .NET will propose a cross-platform UI framework. Microsoft did a poll asking developers about the need for a cross-platform UI framework. The panel speculates how this framework will happen. Patrick wonders at the possibility of WPF. The panel brings up the final prediction, that Blazor has a bright future, and wonder if Blazor could become that cross-platform UI framework.   Panelists Shawn Clabough Caleb Wells Guest Patrick Smacchia Sponsors My Ruby Story React Native Radio Adventures in Angular CacheFly Links www.ndepend.com  SOLID  4 Predictions for the Future of .NET   Satya Nadella reveals why Windows may not be the future of Microsoft’s business .NET 003: Blazor with Daniel Roth https://www.facebook.com/Adventures-in-NET-373059030062837/ https://twitter.com/dotNET_Podcast Picks Caleb Wells: https://www.packtpub.com/free-learning  Shawn Clabough: https://conemu.github.io/ 

In this episode of Adventures in .NET the panel interviews Patrick Smacchia who is known for his static analyzer, NDepend. The panel discusses NDepend, Patrick explains a bit about what is and how it works along with his history in .NET. Patrick is here to explains SOLID, an acronym introduced by Robert C. Martin outlining principles for object-oriented programming.  These principles teach programmers to use object-oriented programming correctly. The panel considers what can go wrong when object-oriented programming is misused. They also explain that the most important thing when it comes to SOLID is to try your best, it is impossible to be perfect in anything. Patrick explains that when your code is SOLID is will be easily testable and maintainable.  The five principles are Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. Of all the principles, Single Responsibility is unique. Patrick explains that this principle is all about organization and advises developers to be very careful when using this principle in your domain. The domain is where it is most important to have SOLID code and it needs to be 100% covered by testing. The panel shares that this is the principle that they try the hardest to follow.   The definition given by Patrick for Single Responsibility is that a class should have a single responsibility or a class should have only one reason to change. Patrick warns the listeners that this is a very complex concept that is difficult to explain. The panel explains that Single Responsibility is a way to accomplish a separation of concern. The panel outlines the benefits of following this principle while Patrick shares some examples and walk the listeners implementing this principle.  The next principle is Open-Closed. Patrick’s definition of this principle is modules should be open for extension but closed for modification. He and the panel dive deeper into what this means. He advises developers when designing a class to be very careful when choosing the point of variation and make sure you don’t change the code in your base class. Caleb shares the problems they experienced in one of his recent projects when this principle was not followed. Patrick explains why the solution is more often the interface rather than the base class.  Moving on to the next principle, the Liskov substitution. Patrick explains how this principle using the example of the ibird. The Liskov substitution principle is that objects in a program should be replaceable so that you can’t tell the difference. In the ibird example, you can not replace the ibird with any bird because if the ibird can fly but the replacement bird is an ostrich it cannot perform the necessary functions. Patrick explains how ilists are in opposition to the Liskov principle.   Next is the Interface Segregation Principle. Patrick explains how this relates to the Single Responsibility Principle. He also discusses how the Liskov Substitution and the Interface Segregation are two sides of the same coin when it comes to designing interfaces. The Interface Segregation explains that many smaller client-specific interfaces are better that one large interface with everything on it.  The final principle is Dependency Inversion. Patrick explains that this principle does not help you design your interface, it helps you organize dependencies into your code structure.   This principle advises developers to depend on abstractions. He explains how this principle relates to dependency injection. The panel considers the damage dependencies can cause in a codebase if improperly used. Patrick explains when a developer will want to use abstractions and when to use classes. He explains that these 5 principles will become natural and feel like common sense as developers gain experience. Switching gears, the panel moves on to discuss a blogpost Patrick wrote explaining 4 predictions he had for the future of .NET. He wrote the article because of the announcement that .NET core will become .NET 5. The future of .NET has a great impact on NDepend and Patrick wanted to give some perspective to the changes and how they might affect his company.   His first prediction is that .NET standards won’t evolve much. Patrick explains that the purpose of .NET Standards was to support all the .NET flavors and with only .NET to support that job will become much simpler. He also speculates on the reasons for Microsoft wanting only one .NET. Some of the reasons he lists are that Microsoft does not have an endless workforce and .NET core is open source and multiplatform.  Patrick’s second prediction greatly impacts NDepend. His prediction is that Visual Studios will run on .NET 5, explaining why he is so sure that they will switch Visual Studios over to .NET 5. Patrick believes that it may take a while for the switch to happen. The panel considers the future of Windows.  The third prediction Patrick makes is that .NET will propose a cross-platform UI framework. Microsoft did a poll asking developers about the need for a cross-platform UI framework. The panel speculates how this framework will happen. Patrick wonders at the possibility of WPF. The panel brings up the final prediction, that Blazor has a bright future, and wonder if Blazor could become that cross-platform UI framework.   Panelists Shawn Clabough Caleb Wells Guest Patrick Smacchia Sponsors My Ruby Story React Native Radio Adventures in Angular CacheFly Links www.ndepend.com  SOLID  4 Predictions for the Future of .NET   Satya Nadella reveals why Windows may not be the future of Microsoft’s business .NET 003: Blazor with Daniel Roth https://www.facebook.com/Adventures-in-NET-373059030062837/ https://twitter.com/dotNET_Podcast Picks Caleb Wells: https://www.packtpub.com/free-learning  Shawn Clabough: https://conemu.github.io/ 

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.This is episode 57, on the Dependency Inversion principle.Dependency Inversion PrincipleThis week's tip is brought to you by devBetter.com.Sponsor - devBetter Group Career Coaching for DevelopersNeed 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 / TranscriptOk, now we've reached the last and in my opinion the most important of the SOLID principles, D for Dependency Inversion. The Dependency Inversion Principle, or DIP for short, has a longer definition that most of the other principles and is often conflated with the related coding technique, dependency inversion, or DI. The principle states that High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces or abstract types). and further, Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.Let's look quickly at each of these two parts. The first part talks about high level and low level modules. The "level" of a module has to do with how near or far it is from some kind of I/O device. That could be the user interface or it could be a local file or a database server. Low level modules deal directly with these kinds of I/O devices or destinations. High level modules do not know about or deal with specific kinds of I/O. These are things like business logic classes and behavior that model how a system works. In many systems that don't use abstractions, high level modules depend on low level modules, or the high level logic is mixed in with low level concerns in the same modules. Both of these approaches violate the Dependency Inversion Principle. Instead, these modules should communicate with one another using abstractions like C# or Java interfaces. Both kinds of modules would depend on a common interface, typically with the low level module implementing the interface and the high level module calling it.The second part suggests that abstractions - interfaces typically - should not depend on details. So an example of this would be if you had an interface for fetching information about a customer. One approach would be to write the interface so that it returned a SqlDataReader as its return type, where the data reader had the customer info. This exposes the details of how the data is stored, since you would only use a SqlDataReader to fetch the data from a SQL database. One benefit of following the Dependency Inversion principle is modularity. You could change that interface to return a simple List type and that List could come from any number of storage locations, from databases, to files to in-memory stores or web APIs. So, that covers how abstractions should not depend on details - what about the last bit that says details should depend on abstractions? That's talking about your low-level modules that actually communicate with I/O. These should depend on your interfaces by implementing them.If you're build a system composed of multiple projects it can be extremely difficult to follow the Dependency Inversion principle if you don't structure your project dependencies appropriately. This means ensuring that your abstractions - your interfaces - live in a project alongside your business model entities and that your implementation details live in another project that references this one. I have a GitHub repository and solution template called Clean Architecture that you can use as a starting point for new ASP.NET Core applications that need to follow SOLID principles and use clean architecture. You'll find a link to it in the show notes or just google ardalis clean architecture.A key benefit of Clean Architecture that is enabled by following the Dependency Inversion Principle is that your business model has no dependencies on external infrastructure concerns. These dependencies are a huge part of why legacy codebases are often difficult or impossible to write unit tests for. By keeping these dependencies separate and in their own project that other projects do not depend upon, it makes it much easier to unit test the most important part of your application: its business domain model. I talk more about this in my DDD Fundamentals course with Julie Lerman on Pluralsight if you want to see this in action. You can also check out the eShopOnWeb reference application that I built for Microsoft and its companion book, Architecting Modern Web Applications with ASP.NET Core and Microsoft Azure.Show Resources and LinksdevBetterClean Architecture on GitHubSOLID Principles for C# DevelopersSOLID Principles of Object Oriented Design -and the DRY PrincipleDDD FundamentalseShopOnWeb Reference ApplicationThat’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.

Im siebten Wissenshäppchen geht es um das Dependency Inversion Principle. Inhalt Das DIP ist das letzte der fünf SOLID-Prinzipien. High level modules should not depend upon low level modules. Both should depend upon abstractions. Oder: Abstractions should not depend upon details. Details should depend upon abstractions. Welche Abhängigkeiten werden hier „umgedreht“? Komponenten, die andere Komponenten... Der Beitrag Dependency Inversion Principle (DIP) – Wissenshäppchen #7 erschien zuerst auf IT-Berufe-Podcast.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 43, with a quick story about dependency injection. A Dependency Injection Story 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 A few years and several businesses ago, my wife and I ran an online ad business, Lake Quincy Media, that served banner ads on software developer web sites like W3Schools, www.asp.net, and ASPAlliance.com. I wrote the original ad serving software for the company, and over the years as we grew we built a team and rewrote it a couple of times. We were using ASP.NET, what would now be called web forms, at the time I first really understood how to use dependency injection. I still remember exactly how it happened, and it dramatically changed how I looked at structuring my object-oriented applications from that point forward. Backing up a bit, I'd learned about and bought into practices like automated testing and continuous integration some years earlier. These practices were not as widespread as they are today, especially in the Microsoft development space, but we were using them at Lake Quincy Media to good effect on our ad server software (which also included publisher and advertiser portals, etc.). We were using a CI server called Cruise Control which included a nice system tray tool called CCTray that would pop up a notification and play a sound any time the build failed or was fixed. It worked great and problems that broke the build were quickly addressed by our small team. However, the application was architected using a traditional N-Tier architecture that was the recommended approach at that time. This meant that the ASP.NET application depended on the business logic application which in turn depended on the data access layer that called the database. Tests of the business logic required a test database, and so our tests ran SQL scripts that reset the database to a known good state before every test. Running several hundred of these tests took about 5-10 minutes on the build server as a result, which wasn't ideal. The point is, we were using automated tests, but our architecture was forcing us to rely more on integration tests rather than unit tests. This background leads to the next part of the story. I remember distinctly trying to write a test for a method that dealt with saving new banner ad media files once they were uploaded to the server. The method in question needed to save the file, perform some work on the file, and then based on some other factors, call some other methods. I was trying to write tests for this, but I was forced to write tests that actually dealt with the file system, and these were very painful. A configuration file was required to specify the upload path, this path wasn't the same between servers and developer machines. Sometimes the file would be locked and tests would fail, or someone would check in a different version of the config file with the path set wrong, and the tests would fail. It was quite brittle, and the files access really wasn't what was being tested - the conditional logic of the method was. By chance I was chatting with my friend and fellow MVP and Iraq war veteran, Jeffrey Palermo as I was struggling with this. He hopped on a screenshare with me and showed me how to change my business-level class so it wasn't working directly with the file system. Instead, he created an interface that included the required file operations like save and rename file, and moved the actual logic for working with the file system into a new class that implemented this interface. Then he created an instance of the interface in the business-level class, which was set by the constructor. However, in our test code, he showed me how to create a fake implementation of the file interface, which we could have the tests configure to return whatever kind of result we needed for the test case we were validating. This was huge! It literally blew my mind and changed how I thought about and wrote code from that day forward. Aaron B., who recently joined my tips mailing list, prompted this tip with his question, "What is one thing you wish you knew when you first started your development career?" and this is what I thought of. Thanks, Aaron, and thanks again, Jeffrey, for showing me this awesome technique for reducing painful coupling in software applications. Needless to say, armed with this technique and a desire to learn more about the related SOLID principles, my tests quickly started to emphasize unit tests wherever possible instead of intregration tests for everything. Our builds started to get faster, and we found tests were quicker and easier to write as well. This was over ten years ago now, but I wish I'd learned it much sooner in my career, and I hope sharing it here will help some of you. If you have a story you'd like to share about something you learned later in your career that you wish you'd learned sooner, go to weeklydevtips.com/043 and leave it as a comment. Thanks! Show Resources and Links devBetter 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.

What is Dependency Injection? Why is it useful? How can we use it? Wanna chat with other smart iOS developers? Sign up for our free forum: https://forum.insideiosdev.com Studying for an iOS Interview? https://iosinterviewguide.com/?promo=inside-ios-dev-ref