SOLID Design Patterns

The Discussion

• 

  This discussion/topic is extremely important. There is not enough time in this video to approach it with the proper depth.

  It is very nice that Channel 9 is opening some space for the principles and practices preached by Robert Martin.

  Code quality and being a better coder is in the very heart and soul of this channel, I think Channel 9 should dedicate more time to that subject. Good tools helps, but does not make you a good or better developer. Those principles do.

  Maybe start a series to discuss those topics, one by one, with the proper importance and depth.

• 

  @Andre Vianna: That is an excellent idea. Would love to hear more about what you think this series should be. You can reply here or email me. My alias is rogreen.

  Robert

• 

  Agree with Andre. Maybe a series where you develop a practical application from start to finish. Thanks!

• 

  @rogreen: Excellent idea. I will spread the series in our local community. There are tons of resources that talks about the principles in general, but I would love to see it as close as possible to C#, .NET (Core), ASP.NET MVC or UWP.

• 

  @rogreen, it could be very useful series. I like your idea to talk about refactoring next time. Keep going and thanks!

• 

  I agree with the others that a dedicated series on patterns and practices would be valuable especially one targeted at .NET (Core) and ASP.NET. I'm particularly fond of juxtaposing a kind of before and after that highlights how following a particular principle makes the code cleaner, clearer, more testable and ultimately easier to maintain.
  
  Too many sample applications are done in a way that would not be acceptable in normal practice, a comprehensive end to end example with refactorings as it progresses would make for an excellent resource for novices and students.

• 

  Yeah this stuff is brilliant. So good to see Uncle Bob's actually being given the proper respect he deserves.

• 

  Should start a series to discuss the topics like design patterns and refactoring technique (book from Martin Fowler)

• 

  Nice job, I found it very useful.

• 

  Nice episode ..

  @rogreen is the demo will be shared on GitHub?!!

• 

  Totally agree with Andre. It will be nice to have one by one episode with some app example. Thank you for this!

• 

  Robert and I are in discussions about more episodes. Thank you everyone for your kind words. The code for this presentation is on github in the https://github.com/skimedic/presentations repo.

• 

  Thanks @japikse

• 

  I gave this a shot with some videos. Please see below for a link to my humble attempts. I *really* like this idea and I hope to see it take off on Channel9 as your production quality is much higher than mine. ;)

  I can tell you from my experience that there are plenty of hungry developers out there that want to know more about the craftsmanship side of things. For example - the cookie cutter entity framework examples you find are great but it's something special when you mix EF with yield and an iterator pattern. Then you naturally find yourself thinking about how that might work when async/await is involved. Great conversation topics even for experienced developers.

  There's so much in .NET/C# that allows you to write really good code quickly that few people know how to take advantage of!

  https://www.youtube.com/user/DRYByDesign/videos?view=0&shelf_id=0&sort=dd

• 

  LOVE IT!

• 

  Excellent video. It could be expanded so more details are discussed. Overall very helpful as an inroduction or a refresher.

• 

  Very good topic and would love to see more like this on patterns and practices.  Thanks Phil

• 

  Terrific video. A lot of information covered for someone like me who is new to these concepts. Phil's explanations were good - I need to review parts of the video and look elsewhere for more detail, but I understand this was only a whistle-stop tour in the time available.

  Robert's questions were very valuable and often exactly what I was thinking - why do it this way rather than the "old" way. The questioning about a service class versus an interface was particularly intriguing and not sure we got an answer in the end why interface is better.

  Thanks to both Robert and Phil for this video. A followup video (with examples of refactoring old code as suggested) with more details and showing why these approaches are beneficial would be most welcome.

• 

  What has changed in c#6 that you don't need double lock in singleton implementation? 

• 

  @rogreen: I was wondering about the question you asked right before the 16 minute mark of this video.  I am new to programming so this may be a dumb reasoning.  I was thinking that the moose interface in the adapter pattern is necessary for the inversion of control within a domain (business logic) layer.  If we have defined our moose in the domain layer of our application, and we want to retrieve an instance of that moose from another layer, we want the other layers to depend on the definition of moose that we have created in our domain layer.  Why? If the adapter directly maps a stored character to an instance of moose that I have created in the data layer of my application (by placing a dependency from the domain layer to the data layer of my application), and someone decides to swap out the data storage technologies, I will have broken my application, since the adapter that my domain layer is depending on to provide it with an instance of a moose is no longer present. However, if I still have a moose interface, and I inject an instance of IMoose into my domain layer moose class, if someone decides to swap out data access technologies, as long as the adapter that they create uses the moose interface, my application will still function as if I they had never changed out the data access layer technology. 

• 

  sorry around the 30min mark

   

• 

  The adapter is all about fitting a square peg in a round hole, and making the app think that it is using a square hole. Switching out a data access layer is an example where the adapter pattern can help greatly. If I have hard coded all of my calls for CRUD operations using nHibernate, and I want to change it to Entity Framework, I have essentially two options. I can rewrite all of my code that touches the data access layer, or I can create an adapter that looks like nHibernate, but is mapping all of the calls to EF.

  I'm not really following how your question applies to the adapter pattern. The adapter pattern doesn't apply to passing domain objects between layers, but creating an intermediate interface that looks like something else to prevent a change from having a major cascading effect on my application code.