SOLID Design Patterns

Sign in to queue

Description

In this episode, Robert is joined by Phil Japikse for a chat about design patterns. Software design patterns have been around long before the MVC Framework gained momentum. Phil starts with a review of Robert C. Martin's (Uncle Bob) SOLID macronym. After building the proper foundation,he reviews several design patterns, their C# implementation and when and how they should be used in modern software development.

Get the code samples here.

Embed

Download

The Discussion

  • User profile image
    Andre Vianna

    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.

  • User profile image
    rogreen

    @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

  • User profile image
    David Rimshnick

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

  • User profile image
    Liero

    @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.

  • User profile image
    resnyanskiy

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

  • User profile image
    AndreArtus

    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.

  • User profile image
    Chris R

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

  • User profile image
    Dev_Raj

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

  • User profile image
    majidrafigh

    Nice job, I found it very useful and pragmatic.

  • User profile image
    Hishamco

    Nice episode ..

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

  • User profile image
    AlmirVuk

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

  • User profile image
    japikse

    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.

  • User profile image
    Hishamco

    Thanks @japikse

  • User profile image
    AriUgwu

    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

  • User profile image
    Xterminator

    LOVE IT!

  • User profile image
    pquintero

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

  • User profile image
    dyardy

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

  • User profile image
    JamesA99

    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.

  • User profile image
    Hennadii_​Omelchenko

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

  • User profile image
    pdoyle500

    @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. 

  • User profile image
    pdoyle500

    sorry around the 30min mark

     

  • User profile image
    japikse

    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.

Add Your 2 Cents