7 ms·

"Software Design Patterns Are Not Goals, They Are Tools" - I do not understand why this needs to be said in the first place.

by MoD411 10y ago

UK-AL 10y ago
I agree. It should be obvious. I don't know anyone who believes design patterns are the goals.
- ifeanyiisitor 10y ago
  Umm... he believed it, hence why he wrote about the insight he gained regarding this belief. And if he believed it, then there will no doubt be others like himself that believed it as well, and will benefit from this insight he has shared. Any insight like this that is shared with an intent to help others is valuable. It doesn't matter how simplistic or obvious we may think it is as there will be others out there that will learn from it. When we make statements like this, we discourage others from sharing things they have learn't in fear of being judged as not knowing something that should 'supposedly' be obvious.
  - MyNameIsFred 10y ago
    Well, the author says that he had been an advocate and even educator on design patterns, yet also admitted that he has never read the definitive (GoF) work on the subject. IIRC, the book's preface declares the very thing the author "discovered" for himself and thought to share. If you started reading the book, and gave up after 2 minutes, you would still have learned this lesson. So, yes, it shouldn't have to be said.
    - ifeanyiisitor 10y ago
      I'm inclined to believe that there are many that have not read the book and yet have tried to use the patterns mentioned in them. They would benefit from hearing what he has to say and why shouldn't they? Should they be punished for not reading the book by having all insights from one like them silenced? Have you also read every book that defines your craft? I don't think so. So wouldn't you then benefit from insight being shared that you missed because you did not read the book yourself? If the rule for sharing content was that you had to read every book on the matter first, then no one would be able to share anything. The point I'm simply making is that as long as there are those that will benefit from what you have to share, then its beneficial for you to share it regardless of how supposedly 'simplistic' or 'obvious' it is and mocking others for sharing things that we deem as obvious doesn't help anyone. Rather, it prevents others from learning. On the other hand, sharing something that is obvious to some but not to others, at least helps those that it wasn't obvious to. The guy did a good think by taking his time to collect his learnings and share it with others in the hope of helping someone else out there, only to be told that what he shared was obvious and so he shouldn't have said it. The price you pay for trying to help.
userbinator 10y ago
I suppose you haven't seen much of the world of Enterprise Java Applications? https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr... Many years ago, I briefly worked in that industry and thoroughly hated the rigid, dogmatic, extreme overengineering culture and the resulting code it produced. I'm glad to be away from it all.
- UK-AL 10y ago
  They still believe that they are tools. The goal is working software, they're just overusing design patterns.
  - JustSomeNobody 10y ago
    The goal is "the one true architecture" that can handle any future change. It's BS and soooo many self proclaimed "architects" fall into it's trap.
    - arethuza 10y ago
      Except that people (and I have done this earlier in my career) make a lot of uninformed assumptions about what future changes might actually be and then when an actual future change comes along it often turns out to be different from what was expected and everyone gets a deeply unpleasant surprise.
- arethuza 10y ago
  A few years back I worked on a project (by myself!) where I inherited an epic codebase that was basically the Enterprise Fizzbuzz application scaled up to ~30 person years of effort - it had tens of thousands of classes and a seeming desire to use every known feature of Enterprise Java and every Design Pattern - actually finding where stuff actually happened in the haystack of abstractions was quite entertaining. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... NB I have a strange definition of "entertaining" in a work context - I was contracting at the time.

"Software Design Patterns Are Not Goals, They Are Tools" - I do not understand why this needs to be said in the first place.

by MoD411 10y ago

"Software Design Patterns Are Not Goals, They Are Tools" - I do not understand why this needs to be said in the first place.

UK-AL 10y ago

I agree. It should be obvious. I don't know anyone who believes design patterns are the goals.

ifeanyiisitor 10y ago
Umm... he believed it, hence why he wrote about the insight he gained regarding this belief. And if he believed it, then there will no doubt be others like himself that believed it as well, and will benefit from this insight he has shared. Any insight like this that is shared with an intent to help others is valuable. It doesn't matter how simplistic or obvious we may think it is as there will be others out there that will learn from it. When we make statements like this, we discourage others from sharing things they have learn't in fear of being judged as not knowing something that should 'supposedly' be obvious.
- MyNameIsFred 10y ago
  Well, the author says that he had been an advocate and even educator on design patterns, yet also admitted that he has never read the definitive (GoF) work on the subject. IIRC, the book's preface declares the very thing the author "discovered" for himself and thought to share. If you started reading the book, and gave up after 2 minutes, you would still have learned this lesson. So, yes, it shouldn't have to be said.
  - ifeanyiisitor 10y ago
    I'm inclined to believe that there are many that have not read the book and yet have tried to use the patterns mentioned in them. They would benefit from hearing what he has to say and why shouldn't they? Should they be punished for not reading the book by having all insights from one like them silenced? Have you also read every book that defines your craft? I don't think so. So wouldn't you then benefit from insight being shared that you missed because you did not read the book yourself? If the rule for sharing content was that you had to read every book on the matter first, then no one would be able to share anything. The point I'm simply making is that as long as there are those that will benefit from what you have to share, then its beneficial for you to share it regardless of how supposedly 'simplistic' or 'obvious' it is and mocking others for sharing things that we deem as obvious doesn't help anyone. Rather, it prevents others from learning. On the other hand, sharing something that is obvious to some but not to others, at least helps those that it wasn't obvious to. The guy did a good think by taking his time to collect his learnings and share it with others in the hope of helping someone else out there, only to be told that what he shared was obvious and so he shouldn't have said it. The price you pay for trying to help.

userbinator 10y ago

I suppose you haven't seen much of the world of Enterprise Java Applications? https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr... Many years ago, I briefly worked in that industry and thoroughly hated the rigid, dogmatic, extreme overengineering culture and the resulting code it produced. I'm glad to be away from it all.

UK-AL 10y ago
They still believe that they are tools. The goal is working software, they're just overusing design patterns.
- JustSomeNobody 10y ago
  The goal is "the one true architecture" that can handle any future change. It's BS and soooo many self proclaimed "architects" fall into it's trap.
  - arethuza 10y ago
    Except that people (and I have done this earlier in my career) make a lot of uninformed assumptions about what future changes might actually be and then when an actual future change comes along it often turns out to be different from what was expected and everyone gets a deeply unpleasant surprise.
arethuza 10y ago
A few years back I worked on a project (by myself!) where I inherited an epic codebase that was basically the Enterprise Fizzbuzz application scaled up to ~30 person years of effort - it had tens of thousands of classes and a seeming desire to use every known feature of Enterprise Java and every Design Pattern - actually finding where stuff actually happened in the haystack of abstractions was quite entertaining. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... NB I have a strange definition of "entertaining" in a work context - I was contracting at the time.