Comments by "Slipoch" (@slipoch6635) on "Solid Programming - No Thanks" video.

  1. The examples on this site are not brilliant. Your code examples are a bit fraught because you use the same examples where your code breaks the guidelines already and then you use it not working with that to strawman the guideline argument. SOLID only really works if you actually follow all the principles as each relies on the others in part. Single responsibility - your render_into may be quicker to script as it is, but if the window object changes then it's screwed and you have to modify this along with your window object changes. If you returned the relevant information and your window object could take it and render the data independently then you would be ok, as any large window changes would be self-contained and the output from the other object would be self-contained. As long as your output is normalised you are fine. Every legacy project i have worked on that has not followed this guideline has all kinds of bugs occurring because they are sharing the load between different objects and classes (and sometimes between projects) and at points in the past they have modified one but not the other and no error was thrown so the issue was missed until multiple successive changes later there were discrepancies shown. EG: totals in a sidebar and on the main part of a checkout page not being the same. Doom source really does follow single responsibility well, each function and object has it's own scope that it sticks to. The locality of behaviour comes with good function naming (something I think ID could do better) so you know exactly what is happening at each stage of the locality. For example your render_into function is probably running from a locality where you are doing rendering. So why not return the data from the function and do the rendering in the rendering locality instead of calling it from a rendering-unreleated object? In this case it also means your stack would be a bit better because if there is an internal object error it occurs on the object, if there is an error with the window, it occurs in the relevant area to doing the rendering for the window. Open-closed limits bugs to the new changes, I see this is mostly for finished libraries/sections of code, the library does it's one thing and works. So for example I have a library that allows reading from a file and finding data within it efficiently (reading 6gb zipped xml). This is finished code and is in use in multiple projects, so if for example I wanted to update it to read data into JSON or create inserts for SQL from the data being read, instead of modifying the library as it stands to do so, I could simply extend it in the one project or within the library project if more need it without touching the existing codebase. Same as if I wanted it to read json as well, then I would extend the existing project to allow another config option and add the code that reads the JSON file ionto my existing objects and pass it to the existing output functions. The function of the library is not changing fundamentally, so why would we touch that part of it and risk breaking it for every project using it currently? This will not work all the time if you are not using the S in SOLID because you have that overflow of responsibility and by design you will have to modify the original code as you showed in your example. Liskov - You don't HAVE to write child-parent classes, but if you do, don't screw it up. If your child cannot be used in a function where the parent is expected, then you have screwed it up. Most IDEs and languages follow this principle inherently. So if you need child class x in a function, then ask for that, not the parent. If you have a function that needs to determine what child class is in use and do different things, then either overloading or a switch hashtable lookup can work. Interface segregation - keep it simple, keep it stupid. Dependency Inversion - Keeps the code self-contained - Your example on the interface was a good one. If you do the S and this then this means you can extend the interface with custom code, but you never touch the classes themselves meaning you can achieve the O. I think it is down to the programming team to come up with the code rules they want to follow, but one of the biggest problems I have ever seen is exactly your example of doing an unrelated task inside an object.
    1