How often do you use Design Patterns in OOP?

How often do you use Design Patterns in OOP?
I'm learning about them and I'm struggling to see real life cases in which they may be useful

Beware Cat Shirt $21.68

Rise, Grind, Banana Find Shirt $21.68

Beware Cat Shirt $21.68

  1. 4 weeks ago
    Anonymous

    every technical interview ever. and then never again

    • 4 weeks ago
      Anonymous

      really?

      i only use them because oop is standard in college sadly

      but do you find them useful and how? i really wanna understand and stop being a brainlet!

      • 4 weeks ago
        Anonymous

        They are useful if you apply them in the correct situation. Then they're the most "optimal" way to having solved that problem. But you can solve a problem using different patterns, but it will just be a bit harder to maintain.
        In many cases in the real world you don't even know the name of what design pattern you're using. If they're common enough like factory or singleton or adapter, you do, but otherwise you might or might not. It's useful to learn them and about them, but it's more of a theory. You also need practice. It's actually easier to understand theory if you've already done it in practice without having understood.

  2. 4 weeks ago
    Anonymous

    i only use them because oop is standard in college sadly

  3. 4 weeks ago
    Anonymous

    if your language has good support for higher order functions then design patterns are not really needed.
    I'm glad every language is moving away from OOP brainrot and filtering out the morons in the process

    • 4 weeks ago
      Anonymous

      There was no need to use the r-word

      • 4 weeks ago
        Anonymous

        he used "really" just to give emphasis

      • 4 weeks ago
        Anonymous

        moron you are

        1. stop writing Black personlicious code
        2. use an IDE, which aids in not writing Black personlicious code

        this. a true white man only needs nano.

  4. 4 weeks ago
    Anonymous

    You use them when you have a real job.

    • 4 weeks ago
      Anonymous

      Sir, implement the abstractFactoryStrategyManagerDelegate

  5. 4 weeks ago
    Anonymous

    Theres no good usecases for them. they are fricking moronic.it exists solely to make bob martin rich

  6. 4 weeks ago
    Anonymous

    I hate OOP so much it's unreal

    • 4 weeks ago
      Anonymous

      Theres no good usecases for them. they are fricking moronic.it exists solely to make bob martin rich

      How is anyone supposed to see this and think it's okay?

  7. 4 weeks ago
    Anonymous

    Stop taking university education seriously before it's too late. Just regurgitate that shit by heart to get a decent grade and never bother with it again.

  8. 4 weeks ago
    Anonymous

    Most "design patterns" are shitty solutions to language restrictions that have not exited for decades.
    Some design patterns are useful but you're not going to learn them from a university course. The correct way to teach a design pattern is to give a programming task which the pattern solves neatly but without telling the student about the design pattern so he comes up with a shitty solution himself. Then you reveal the design pattern and have the student solve the task again by using it. Unfortunately that requires an immense amount of effort on the teacher's side and it also requires the design pattern to be actually useful, so all you're getting is regurgitated definitions for 20 year old Java code.

    • 4 weeks ago
      Anonymous

      >but without telling the student about the design pattern so he comes up with a shitty solution himself.
      What if he comes up with a good solution after all?

    • 4 weeks ago
      Anonymous

      you got it the wrong way around
      design patterns are solutions that emerged after people kept having to implement the same shit over and over again. that's why it's a PATTERN
      some patterns are so popular and universal that in newer languages they eventually got added as language features/syntax sugar, but the pattern is still there

      you're right that universities are absolutely wrong in how they teach design patterns, though. i don't agree with your approach to teaching them but it definitely should not be the current way of first dumping all patterns' definitions and then telling people to forcefully apply that pattern to a non-fitting problem.

  9. 4 weeks ago
    Anonymous

    A design pattern is a learning tool to help you recognise concepts in the wild.
    When you write software you break a problem down into parts recursively until you can implement them in code.
    Design patterns are just giving names to concepts that are seen repeatedly in software.
    The implementation will never be exactly like you are taught or a textbook example.
    But when you explain it to someone you can say oh it's a producer consumer model and everyone knows that roughly this is how it works, but it's not going to look exactly like they were taught.
    You should never actually implement a 'design pattern' but inevitably you will see 'design patterns' in your code.

    • 4 weeks ago
      Anonymous

      I kinda get what you mean but without an example not really

  10. 4 weeks ago
    Anonymous

    If you want practical uses, don't think of them as "memorizing the formula" without udnerstanding what it does, but simply try to use some in a project and see how it works out.

    The whole idea is 'somebody has already come up with a pretty good way to do things in this specific case, so you don't have to bother figuring out how to do this exact thing'

    If you can't find a practical use for a pattern, you probably don't need it.

    • 4 weeks ago
      Anonymous

      also, in planning otu any system, you could call 'the plan of how different components interact' a pattern. It's just, they don't bother makign a big deal out of say - "when you want to display a popup when you click on a website, you put an event listener", but in some way, this is a pattern.

  11. 4 weeks ago
    Anonymous

    Singletons are useful. Everything else is a meme.

    • 4 weeks ago
      Anonymous

      Global variables are not allowed in Java so the javajeets """""invented a pattern""""" that does the same thing.
      99% of these """"patterns"""" come from some jeet reinventing things that always existed in non-shit languages.

      • 4 weeks ago
        Anonymous

        global variables are bad, but singletons are good

  12. 4 weeks ago
    Anonymous

    >How often do you use Design Patterns in OOP?
    Builder - frequently; others, not so much

    >I'm learning about them and I'm struggling to see real life cases in which they may be useful
    it's not something you apply in advance unless you really have enough experience to recognize when a pattern fits. and if it doesn't fit, it'll only shit up your codebase.
    some patterns won't even make sense at all unless you're interfacing with something very non-OOP and need a compromise

    if you're just learning about them, you should just implement stuff without patterns. when you notice your code seems like it could be tidied up, then read up on what patterns might fit your use case and see if they fit (if not, discard/undo)

    • 4 weeks ago
      Anonymous

      I hate that builder garbage. Just let me declare the damn struct.

      • 4 weeks ago
        Anonymous

        don't blame the pattern being bad when you're the one using it wrong

        • 4 weeks ago
          Anonymous

          >struct()
          >.attribute_1(value1)
          >.attribute_2(value2)
          >.attribute_3(value3)
          >.attribute_4(value4)
          >.attribute_5(value5)
          vs
          >struct{value1,value2,value3,value4,value5}
          Yeah you're moronic.

          • 4 weeks ago
            Anonymous

            builders are not for structs, you absolute shitter
            read

            don't blame the pattern being bad when you're the one using it wrong

            100 times again

  13. 4 weeks ago
    Anonymous

    Remember that 'design patterns' were introduced BEFORE most OOP languages got lambdas.
    Most design patterns are useless now because they're basically just crutches for lambda-less OOP languages.
    But now even C++ has its own crippled form of lambdas.

    • 4 weeks ago
      Anonymous

      how would lambda help you with an observer pattern for example?

  14. 4 weeks ago
    Anonymous

    I have a job that uses OOP and I have never thought of design patterns although its probably because I don't create, only fix.

    All I do is add stuff into the constructor and its hope the dependency has been injected somewhere else

  15. 4 weeks ago
    Anonymous

    Going through 20 different files that use methods of classes of classes of classes is a good thing Chud!

    • 4 weeks ago
      Anonymous

      1. stop writing Black personlicious code
      2. use an IDE, which aids in not writing Black personlicious code

  16. 4 weeks ago
    Anonymous

    Most of them are long incorporated in any modern lang that is worth a shit. So yeah, the absolute bulk of them is useless. It's not useless to be aware about them though simply to broaden your historical understanding of what came out from what.

  17. 4 weeks ago
    Anonymous

    Are you in college or do you have a job? If you are still in college, you do not have real life cases in front of you.

    I studied CS in the 90s and people thought OOP was stupid.

  18. 4 weeks ago
    Anonymous

    man i always wanted to ravage hee butthole

    • 4 weeks ago
      Anonymous
  19. 4 weeks ago
    Anonymous

    for serious projects they're critical.
    for shitcoding they're not.

  20. 4 weeks ago
    Anonymous

    Useful patterns:
    >visitor
    >factory
    >subscriber
    >chain of command
    Sometimes necessary:
    >adapter
    >abstract factory
    >command
    Shit:
    >the rest

    • 4 weeks ago
      Anonymous

      Someone mentioned builder and I agree, it should be placed under useful patterns.

    • 4 weeks ago
      Anonymous

      >visitor
      for loop
      >factory
      struct
      >subscriber
      for loop
      >chain of command
      slow and prone to bugs

      frick off shit coder, everybody hates you and your shit code

      • 4 weeks ago
        Anonymous

        >for loop
        Yes you could push each item onto a stack to get the same behaviour as recursion

        >struct
        Struct of what? You know a "factory" doesn't have to actually construct new objects every time you call it right? It's allowed to preconstruct and reuse them provided it implements its declared/documented contract.

        >for loop
        Yes that's how you'd notify the subscribers.

        of command
        >slow and prone to bugs
        It could have gone into sometimes necessary I suppose...

        You use these patterns in non-OO languages you know. These are both subscriber pattern:
        class ThingNotifier {
        // ...
        private:
        std::vector<ThingSubscriber> _subs;

        void notify(Thing thing)
        {
        for (auto &sub : _subs)
        sub.notify(thing);
        }
        };

        // ---

        typedef void( *ThingSubscriber)(struct Thing *);

        struct ThingNotifier {
        struct SubscriberList {
        ThingSubscriber cb;
        struct SubscriberList *next;
        } subs;
        };

        static void notify(struct ThingNotifier *inst, struct Thing *thing)
        {
        struct SubscriberList *curr = inst->subs;
        while (curr) {
        curr->cb(thing);
        curr = curr->next;
        }
        }

        Their performance will be about the same but one has better syntax.

  21. 4 weeks ago
    Anonymous

    Whyte zoomers are scared of OOP and the design first, program later style. They just want type some sphagetti algoritms instead. You Are Obsolete

    • 4 weeks ago
      Anonymous

      >design first, program later style.
      Code is design.

  22. 4 weeks ago
    Anonymous

    design patterns are a good idea with a bad execution. it's a good idea to categorize and name problems in code but a bad idea to try to solve them using objects only

  23. 4 weeks ago
    Anonymous

    >nocoder never seen a problem more complex than fizzbuzz
    >calls other shit coders
    lmao keep being filtered i guess

Your email address will not be published. Required fields are marked *