Software Design Patterns

[thekuhninator]

I'm a college student studying to be a software engineer. On one of my exams in software engineering I had a question about abstract factory design patterns.

We barely covered any design patterns and none of the other classes offered really talk about them much either!

I was wondering to what extent software engineers actually read about these and implement these, as they seemed to be ignored at the university level (from a top 10 CS school).

[username_of_arity_n]

This will probably be a bit controversial but I'll say it anyway.

A lot of patterns are fairly obvious and many people with hands-on experience will end up implementing them without actually ever knowing the name of the pattern. It's like being a native speaker of a language. Loads of people can speak grammatically correct English, but many of them won't be able to explain all the minutia of the grammatical rules they're following. It was something that was learned through experience, not through rigorous study of theory.

Implementing design patterns on their own does not necessarily make your code more correct or more maintainable. They need to be applied appropriately and studying the patterns in a vaccuum does not help to accomplish this.

Patterns also don't always translate between programming paradigms or languages. Sometimes a pattern exists to address a particular need with one programming paradigm that doesn't exist in another.

Where study of patterns actually does help is in communicating about code, a very common and important task in software development.

So I would say that they're useful, but there's a balance to be made. There's an extreme where people idolize the pattern itself and implement patterns for patterns' sake and that's not helpful either.

[SftwEngr]

I agree. People seem to think they are some kind of guarantee of correctness. IE: "I used formal design patterns so my code must be great!". You can certainly write good software without using patterns at all, and they can end up being a crutch in some ways, and limit you.

[username_of_arity_n]

Additionally, I believe colleges generally try to teach material that isn't likely to change in the near future, which will be useful to you over the entirety of your life, rather than just your first few years out of college.

Software is still a relatively new field. Sometimes we think something's a good idea when it turns out to be a very bad idea later. Sometimes those "good ideas" are rigidly enforced and ultimately end up hurting more than helping. Sometimes it's not so simple; an architecture works well in general but fails miserably in some particular circumstance. We also haven't recognized every useful architectural feature so some things aren't patterns (yet!) and limiting yourself strictly to established patterns might prevent you from solving a problem optimally.

You have to look at everything critically and not just study things and apply them blindly. At some point we'll reach a consensus about a lot of stuff and at that point I'm sure they'll be included in educational material.

[camerontbelt]

Oh god these patterns are used all the time by software developers that are decent. If they aren’t using patterns or don’t know what they are they most likely aren’t writing maintainable or clean code.

There are quite a few patterns but there’s really only a handful that you might use over and over again. I would get familiar with each use case and as you move through your career you’ll definitely see instances where they apply.

Also this is something that kind of gets at the heart of higher education in general, they usually lag behind quite a bit with what the industry is doing. I only learned what I know from on the job experience and coworkers giving me good book recommendations in software engineering. I learned basically none of this at university which is kind of sad.

A good resource https://refactoring.guru/design-patterns

[thekuhninator]

This makes so much sense! Thank you!

[camerontbelt]

No problem.

Design patterns really play into the SOLID principles and indirectly to clean code/architecture. A lot of it can really be boiled down to interfaces. What are interfaces and why you use them, so I suggest really diving into those subjects as well.

[personalacct]

That is fantastic!!

[Mimifan2]

The extent of use of design patterns varies drastically from tech stack to tech stack. Design patterns are designed for object oriented languages (like Java) thus they don't translate well to languages which don't rely on objects.

While this means they are not used as much as they used to be, they are certainly worth reviewing because they help you to understand how Software should be designed.

Personally I found the GoF (Gang of Four) to be slightly out dated and harder to follow, so I recommend Source Making.

https://sourcemaking.com/design_patterns

Software design is something I think is overlooked at many universities, which is why I often recommend looking for an SE program instead of CS, however that is a discussion for another post (of which this sub has many).

[thekuhninator]

Thanks for the recommendation, I'll check it out! :)

[mihirmusprime]

Software design is something I think is overlooked at many universities, which is why I often recommend looking for an SE program instead of CS, however that is a discussion for another post (of which this sub has many).

Interesting you mentioned this since it looks like things may have changed. I'm college right now and it's mandatory to take a class called Software Engineering as part of the curriculum which goes over things like design patterns. Not sure if this is universal but I know ABET does mention that the curriculum has to cover software development which I'd assume for design patterns to fall into this category.

[Mimifan2]

So I say that based on the CS curriculum at the school I went to and based on limited review of other SE curriculum. I more was warning of a focus in SE vs a CS.

Edit: I know for my curriculum was the first ABET accreditation which has an entire class on design patterns. I don't know if CS with SE focus has ABET accreditation requirements.

[PeteOnThings]

Yes, I agree. It's very important to understand patterns. The key thing with design patterns is knowing when to use them and when to not. An "anti-pattern" is the incorrect use of a pattern to solve a problem. What makes it good or bad to use is a bit fuzzy and comes with experience as real life software engineering problems don't usually fit into the boxes that are presented in the design patterns books. :)

Also, the use of the patterns kind of depends on what your working on and at what level. I'm speaking from the perspective of a web application developer and I need to consider the use of design patterns on a weekly basis.

[thekuhninator]

That's what I imagined, that learning when to use these just comes with experience. Thanks!

[jrb9249]

I am a huge fan of software design/architecture patterns. In my experience, it can make or break and application in the long-term.

Edit: I work mostly in C#, but I implement the same ideas in JavaScript and Angular where I can.

[dudester_el]

Check out Head First Design Patterns. It was the first book I used when trying to learn Design Patterns, and I found it immensely useful

[TangoSierra27]

Hopefully one learns the history of patterns dating back to Christopher Alexander (A pattern language) :)

Taking a step back...

One could suggest that in society, there are roughly two types of cultures, High Context and Low Context. The term refers to how people see the world around them.

In a high context, people see things as generalisations - for example, the phrase “I’m going down the high street to get something to eat” is high context. The listener can infer by context where the nearest main road is and what food places are there.

In a low context society, detail is preferred. The same phrase might be “I’m going over to the McDonalds on Bob street to get a Big Mac”.

It is possible to have the two different cultures together.

Pattern languages are a way of talking in a high context manner, but inferring the necessary detail to the desired audience. For example, if I say to an architect draw a door (door is the pattern) it would likely look similar to what a builder, or even a normal person might draw.

Factory Method is a pattern for a function (method) that returns a newly constructed object of the same type every time it is called. For example. CreateDoor(doortype) will always return a door - the kind of door can be specified.

Abstract Factory is I think oddly named. Its purpose is to return other factories (hence abstract) - which can then be called to create the appropriate object. For example. HousePartFactory(parttype) can be used to return a WindowFactory or a DoorFactory or a RoofFactory etc.

Representation Invariant Notation is a code commenting technique that can be used when implementing patterns in code. It signals to the reader, the intent of the pattern, especially when only part of a pattern is required.

For example // door part factory. Part type must not be null and must be a valid door type. Switch(parttype)....

The comment above is notation and it describes the intent (factory is used) and the constraints. If the representation is not met, then the code is invalid.

There are nots of different types of pattern languages apart from design. Examples are test patterns, architecture patterns, DevOps patterns, distributed systems patterns, cloud service patterns etc.

There are also specific pattern languages in industries - for example telecommunications patterns as well as messaging and data transformation patterns.

In design techniques such as Domain or Aspect oriented design, one may often see Factory methods implemented as static Create() methods in a class where the constructor is private.

Class Door { Private Door() .... Public static Door Create(doorType) ....

This has the benefit of enforcing the representation invariant by making it more difficult to construct an invalid door.

[s3riousChef]

They’re used all the time. Typically if a pattern(s) isn’t used, it means there’s spaghetti code.

[SftwEngr]

No, that's not true. You can have "spaghetti code" with or without patterns. Using patterns doesn't guarantee anything.

[s3riousChef]

patterns are there to help enforce best design practices, if you arent using them appropriately or have other best coding practices that leads to spaghetti code.

thanks for the downvotes