Stitcher for Podcasts

Get the App Open App
Bummer! You're not a
Stitcher Premium subscriber yet.
Learn More
Start Free Trial
$4.99/Month after free trial
HELP

Show Info

Episode Info

Episode Info: 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 ...
Read more »

Discover more stories like this.

Like Stitcher On Facebook

EMBED

Show Info

Episode Options

Listen Whenever

Similar Episodes

Related Episodes