Having trouble understanding patterns
Hello, I`m a second year student and I'm reading about patterns like a factory pattern. I have trouble understanding why I should use patterns and when to use which pattern.
MPatterns usage is learned by example. For example, Singletons. The purpose of Singletons is to have one instance of an object. The reason to use Singletons comes from the explicit choice to disallow other parts of the program tracking their own version of the object. For example, you want one single place for your theme configuration, instead of loading it from disk throughout the program.
MMost of the ones you hear about originally come from a classic software engineering book called Design Patterns. If you really want the background on those, read that book.
I personally think design patterns are over-used as a fancy way of saying what should generally be simple concepts.
I personally think design patterns are over-used as a fancy way of saying what should generally be simple concepts.
MThe whole point of patterns is that the same recurring patterns keep coming up in software design and it's an attempt to formalize and name what those patterns are.
MFactories are a bit more complex where the object creation is abstracted away. The purpose of doing so is sometimes because people want a
Example ex = new ExampleBuilder().SetFieldA(1).SetFieldB(2).Build(); type of architecture. Which is bad design cuz we have Example ex = new Example { A = 1, B = 2 } syntax. The true purpose of the Factory pattern is to alleviate downstream changes, in which if you change something it should be ABI compliant unless its a function sig change.MI would focus on terminology and implementation over the need to actually use these patterns, as mtreit is right in that patterns are overused for a mispurpose like corporate buzzwords.
MI would assume modix has a
M$factory
MNope?
MWould at least having a basic understanding of those patterns make me a better programmer because then I know how I should/could write code in a more "consistent" way?
M$patterns
MThat's the general idea behind formalizing design patterns, yes.
MDo you recommend reading the book in that case?
MThat said, I never read the design patterns book.
MDesign patterns come after learning algorithms tbh
MAnd I don't generally think in terms of design patterns when I write software.
MAlthough I probably use those patterns organically.
MDoes it come naturally then or is it not really something to keep in mind when programming?
MAh okay
MIt's like anything, some people find it really helpful to try and study the patterns in a formal way, other people don't.
MNaturally most of the time. Like my themes example is an actual deployment of singleton I used.
MThat said, without things like the factory pattern we would not have the absolutely priceless work of art known as FizzBuzz Enterprise Edition...
Mbrooo what
Mlmfao
MOkok
M
MWtf
MReee line breaks
MIn case it's not obvious, that's a parody of how programming in the enterprise world works.
MGoing from reading C# to reading Java is so jarring
Myeye i know
MDid you ever look into them or did you just learn what is "wrong" and "right" after years of experience?
MI've leafed through a colleagues copy of the book and if you work in software long enough you'll just see plenty of explanations of different patterns. But I couldn't tell you what most of the formal design patterns actually are.
I use singletons a lot. I know that's a design pattern.
Factory pattern, I use that sometimes.
Observer, Adapater, Bridge, Mediator, Decorator, Facade, Visitor <- I see these terms regularly and have no real idea what they are.
I use singletons a lot. I know that's a design pattern.
Factory pattern, I use that sometimes.
Observer, Adapater, Bridge, Mediator, Decorator, Facade, Visitor <- I see these terms regularly and have no real idea what they are.
MA lot of the classic design patterns are very much associated with "object oriented programming" and some programmers (myself, for instance) are not a fan of object oriented programming and thus don't really feel like these classic design patterns are all that important.
Mbut you should read up on them and decide for yourself.
MReading the classic book certainly wouldn't hurt. It's a classic for a reason 
MOkay okay
MThanks for the advice
Minb4 mtreit loses his job
MYou're more likely to get a job knowing OOP and Algorithms than Design patterns
MYeah I figured but I was just wondering if design patterns are like a golden standard
MDefinitely not, and if you see people pushing them they're often a corporate shill
MWhat about principles? Does your code need to follow like every SOLID principle or is it the same story as design patterns?
MSame thing
MThat's another thing that people who are way into OOP get all excited about.
MWhat is the alternative to OOP then?
MProcedural and functional approaches mostly
MComposition using interfaces
MInstead of inheritance
MProcedural is usually for scripting purposes, functional is more for math and data science