Sfdwhf

There is more to a CS degree than programming and more to programming than Design Patterns. I'm actually an expert in such things and have designed and published a few as a committed member of the patterns community. If I were teaching you programming in some object-oriented language you would certainly learn about and use many such patterns, but you might never hear the names, just the usage as good ways to write programs in a certain set of languages.

However, I have a friend, also in the community, who is well known and has designed many things fundamental to areas of programming languages who doesn't use the standard design patterns you are probably thinking of at all. The reason is that he programs in LISP and CLOS, not Java and C++. His informed opinion about the design patterns is that they are merely corrections for flaws in certain languages, primarily C++. Many of the kinds of things that design patterns accomplish in C++ are done in more natural ways within Common Lisp itself without needing any such mental tricks.

So, it may well be that your curriculum is flawed, but not teaching the patters in the Gang of Four book is not the only indicator. (Some of those authors are friends of mine, in fact).

Moreover, there is more (much more) to CS than programming. Have you learned data structures and algorithms? Have you learned architecture and databases? Have you learned data communications and concurrency? Have you learned to work in teams on large projects? Have you learned to think abstractly and to decompose problems and compose solutions? Those are vitally important too.

Buffy's answer perfectly addresses your question about design patterns. I would just like to add a bit of perspective about CS curricula in general.

Computer Science (CS) is very young compared to other scientific disciplines. For example maths or biology are strongly structured disciplines which rely on a quite well defined corpus of must-know basics. Of course these fields evolve, but the standard undergrad curriculum is not very different from what it was 20 years ago. On the contrary, CS is a fast evolving discipline and it is very different from what it was 20 years ago. Of course there are some broadly accepted topics, but there is no clear consensus about what a CS curriculum should contain. This is why different institutions might provide students with a significantly different background, but that doesn't necessarily mean that one is better than the other. It's important to keep in mind that a good CS curriculum is not one which provides students with the knowledge of their time, but one which prepares them to adapt and acquire new knowledge all along their professional career.

It has been well known for decades by anyone coming out of University that, as you say, "the problems in the real world, both in academia and in the industry, can be more easily handled with a good choice of design pattern". And it has been well known for almost as long that this claim is wrong.

When you have a problem, you come up with a way to solve it that suits that problem and also the surrounding context. Then, if you want to describe your solution, you can find some terms/names for it — sometimes, there is already a name for the solution, so you can just use that name.

What you don't do is look at a problem and say "I know, I'll use the visitor pattern" just because it's a thing that has a name. That is an arse-backwards way to approach problem solving. You might utter that phrase out loud if you've concluded that the appropriate solution indeed does look like the visitor pattern, quite by chance.

Design patterns are a descriptive tool, not a problem-solving tool.

It is unusual for a University to not make this error, and you've mistaken it for an omission. It is possible that it is an omission. If so, I'd say it's a fortunate one.

I would have hoped, however, that your professor would at least pay lip service to design patterns because — rightly or wrongly — you will encounter loads of people in industry who treat design patterns as god, and you will need to know when to recognise this, and you will need to come up with your own opinion on whether/when they are applicable. To simply not mention them at all in a course also seems unfortunate.

In conclusion, it's not necessarily "bad" that your course doesn't teach patterns. It's either an omission, or it's "good". There's not really much way to know without having a productive, educational discussion with your course convener.

Also, do bear in mind that "computer science" and "software development" are completely different things; though many Universities mistakenly call software development courses "computer science" out of habit, it's possible that your course is an honest-to-god CS course, in which the whole discussion of design patterns isn't particularly relevant anyway.

Buffy has stated much of what I would have, so I won't repeat. But do read that answer carefully.

The first point is, university is for proper formal education, which means heavy theory and less practicals. University is not for job training (there are lesser schools for that). That is what makes a university education better than a job training school, and what makes the starting income higher.

The second point is this. Education is deteriorating badly, CS in particular. In all countries (Brazil is actually less damaged than many Western countries). The basics are not being taught properly, or not being taught at all. Any of the CS graduates that we hire are clueless about basic logic, but they are expert is some irrelevant thing from last year that everyone has forgotten about this year because there is a new fad and terminology. They lack logic in their speech; their thinking; and of course their programs.

• Half the time, in order to cut through the argument, I have to draw an SSADM diagram, or an IDEF0 model, or a flowchart, or code the important part for them in awk, which scares the bejeezus out of them. Then the lights go on in their heads, and they can code. The problem is they can code, but they cannot think.

Instead, many unnecessary, current-fad things are being taught. Design patterns is one of them. Without the underlying foundation, it is quite meaningless. Sure, the marketing is good, just as it is for chaos theory and other forms of insanity. The problem with it is:

• it approaches the target bottom-up (thinking, and good systems design, is top-down)




• it has patterns in mind. Not design patterns (design is not a pattern), but implementation patterns.




• it promotes a single tool mentality (Maslow's Hammer: if all you have is a hammer, every problem looks like a nail).

It teaches you to look at the problem in terms of a predefined set of solutions (all bad, and very limited), and just match one to the other. Good for simple robots (without AI). Not good for humans, or AI-capable robots. It is like when learning to be a barista, learning 100 ways to froth the milk, and to make pretty pictures in the foam, but not learning what coffee is, or where it comes from. On the other hand, if you learn the basics, you can make any type of coffee, and anoint it with an infinite number of pictures.

You need to learn:

• to understand and analyse problems


• know design and methods, and apply them


• methodologies and standards (unless you work in China)


• SSADM and IDEF0, not UML (it is not a standard, and it has no facility for analysis or for design)
  
  
  
  
  • problem decomposition, and then solution composition
  
  
  • architecture (literally, the way to ensure that each code segment is deployed in the right location)
  
  
  
  


• come up with a complete system (good case studies)


• for programming, you need:
  
  
  
  
  • Logic, formal logic, and even more logic
  
  
  • proper diagramming
  
  
  • ability to program in any language (not stuck to Java or C++ or OO/ORM ... it is quite useless to be able to code objects without understanding deeply what the heck the object is)
  
  
  
  


• for everything, you need to understand normalisation properly (it is pretty limited to know only the NFs, or to apply them only to data).

the problems in the real world, both in academia and in the industry, can be more easily handled with a good choice of design pattern

No. If you said that in an interview, I wouldn't hire you, because it indicates a very narrow mindset, and a lack of understanding that problem solving, not pattern matching, is the CS skill that I am hiring you for. In the real world, we need what I have explained above.

Trust your university, and your teachers, not the latest faddy books.

In general, a good education is one that teaches you to think. A good computer science education isn’t one that teaches you any specific language or technique but one that exposes you to many different concepts such as algorithms and data stuctures, as well as theories such as functional, logical programming, and objected-oriented programming, and relational database theory. At the end of it, you should be able to teach yourself new languages and tools, and pick up new paradigms.

There are some basics that I would expect every computer science education to include, such as at least one assembly language, an understanding of Turing machines, algorithmic complexity, but design patterns isn’t one of those.

I do see it as a missed opportunity though: design patterns could be covered in one lesson as part of a course on object-oriented design.

Since Buffy already gave such a good answer, I will post here my experience with an advanced course that focused on OOP and Design Patterns taken at a very prestigious Brazilian university.

The thing is, teaching Design Patterns is not easy. Remember that the GoF book was written as a compilation of the author's many years of experience in complex projects. Each pattern is proposed as an answer to problems that arise on certain situations. However, most students have negligible experience during college and have never experienced the difficulties described in the book. So you end up with a course that answers a lot of questions that were never asked in situations that are new to most students. In my case this took form of long expositions of patterns, their motivations and shallow examples of use. Many students slept during class, memorized the patterns for the exam, got reasonably good grades and surely forgot everything afterwards. After an entire course of OOP and Patterns, most students were far from experts in patterns and I suspect they would remember very few patterns, if any at all, a month after the course.

I came out of college with a fresh CS degree in 1989, to find that my colleagues were on average very much older than me (obviously), had by-and-large never heard any of the fancy "structured programming" lingo that was taught in my Software Engineering course at the time, and in fact mostly didn't even have CS degrees themselves.

3 decades later, the shoe's on the other foot. Our fresh out of school new hires like to talk a lot in pattern lingo that didn't exist in the 80's, and most of which honestly doesn't need to exist today. 20 years from now it will be a new fad, with new lingo.

So no, I wouldn't worry about it too much. Other than your younger co-workers, not having memorized the pattern lingo isn't going to hamstring you in the field a whole lot.

But are there fundamental things that come along with Design Patterns that you really need to know as a professional? I'd say the results there are mixed. Let's look at the tables from the WP page on patterns.

In the "Concurrency Patterns" table, pretty much everything in there is standard concurrency programming, that I learned in school 30 years about without benefit of the GOF lingo. Outside of that, I see about 6 things in all the other tables that I can say I've used over the years, when needed, but its all just pedestrian stuff. If you have half a brain, you'd figure that out yourself if you ever need to. However, there are two exceptions: RAII and Singletons.

RAII is such a powerful concept and central concept, that it really should be taught. The peace of mind from not having to worry about dynamic resource lifetimes is one of the real game-changers that happened during my career. However, I'm not sure I'd call it a "pattern". Design Patterns and Code Complete seem to agree, because they don't include it. This should definitely be taught, but I don't think you need the overall "pattern" structure around it.

Singletons are just an object-oriented hack to get yourself globals, and should almost never be used. If they are taught at all in school, it should be as an anti-pattern to avoid, along with gotos. Yet both Design Patterns and Code Complete positively teach them.

So no, I wouldn't worry about your SE class not being pattern-focused. You can get by just fine without them.

There isn't that much to "Teach" about design patterns. You should be able to skim one of the books in a few hours and possibly try to implement a few yourself if they confuse you.

For the most part design patterns make up for deficiencies in languages or patterns. For instance, in OO it is pretty much impossible to connect from two different "Entry Point" objects to a shared object, so we use the singleton pattern. A better solution is to use Spring (Which is more like enhancing your language to solve the problem) and then we no longer need a Singleton "Design Pattern".

If you were using a perfect programming language you shouldn't honestly NEED any patterns (Any pattern in your code is, in essence, not DRY). Design patterns are used for something that cannot be directly expressed in your language and is either too simple or too messy to put into a library.

We don't have a perfect language so we still make use of patterns. Reading about patterns isn't difficult and will give you a common language to use with your team.

I suppose if I were teaching computer science I'd require a pattern book and suggest it be read, maybe test on it, but I don't think I'd waste much class time on it.

The vocabulary of computer science is not as well established as the vocabulary of mathematics. Many words have different and contradictory meanings in different contexts, and it would thus be common for different people to describe some particular concept using seemingly-unrelated words, or use the same words to describe unrelated concepts.

Certain books have become sufficiently popular that many people have adopted the vocabulary used thereby. The notion that code to accomplish similar tasks would often be written in similar fashion precedes by decades any attempt to formally recognize any particular set of Design Patterns.

Although it's useful for people to have a consistent vocabulary that can concisely describe certain common patterns, there's nothing particularly "magic" about it. Being able to recognize why it is useful for certain kinds of code to accommodate certain combinations of actions is more important than knowing that a popular book refers to some combination of abilities as the "Woozle Pattern".

Computer Science and Software Engineering are very related but also different disciplines. When I went through my degree (ABET accredited program, US) Software Engineering was an elective (as it is absolutely not necessary to be a good computer scientist - though some may disagree), and in that class you learned design patterns. We would joke these were the "trade school" electives for CS graduates because if you took them you were probably going straight to industry. I took them, I went straight into industry. I took 4 programming-oriented classes in total. Two in the beginning to get your familar with the common language, and two at the end (the SE classes). Everything in the middle was pen and paper mathematics, algorithms, data structures, and compilers. Yes, many things were implemented in software. But it was not the central theme of the class. To me, design patterns are trivia that you can pick up on the job. A class is just a nice way to get started. I learned everything being a professional software engineer. In hindsight, the classes were outdated.

You are also vastly overestimating the complexity of academic code. Yes, sometimes it can get very hairy but take a stroll around arxiv. Can you name 10 papers that would be improved by knowing the Gang of Four book cover to cover? Doubtful. Proof of concept code is exactly that - it's a proof of concept. It's up to software engineers to grok it and make it beautiful.

There is so much more to Computer Science than software engineering. There are so many sub fields and software engineering is just one very very tiny one. Equating software engineering with the entire field of Computer Science is more-or-less the result of code schools being so prevalent (in my opinion). We (as a field) should really work to dispel this myth.

I wouldn't worry to much about it. My CS program at Arizona State University (circa 2010) only had Design Patters as an elective class. I knew plenty of people who never took it.

I think this comes down to the difference between "Computer Science" and "Software Engineering".

Computer Science focuses more on the theoretical side of things (algorithms, mathematical models of computing, how operating systems and compilers work, etc). It's stuff you don't directly use very often, but gives you the foundation to do any type computer work you want to do.

Software Engineering, on the other hand, is "how to make stuff". It answers questions of "How do I design the software I'm creating?", "How can teams of programmers best work together?", "How can engineering teams best work with non-engineers?", etc. It's more about the big picture view of how to make software.

CS programs generally don't spend much time on all the engineering stuff. There are so many things to learn about programming and software engineering that there is no way any university program could cover a sizable fraction of it. So they focus on the theory that will help you learn the rest on your own or as you work in industry.

I'll say this much about my experience: Even though I did take the design patterns elective at my school, it was only quick intro. It took years working before I felt like I started to get a handle of why, when, and how to use them well. And I still feel like I have a long way to go.

So as I said, don't worry to much about it. Get yourself a decent reference book, skim through it just to get a feel for what patterns are out there, and then be mindful of them as you go to work as an engineer. You'll figure it out as you go along.

Your question is one of the "Do you still beat your wife?" ilk, as it is based on false assumptions that you assert by emotional writ.

Being that Design Patterns, and Object Orientation itself, is one gigantic farce that was concocted by idiots, brainwashed the masses, and has crippled the advancement of actual computer science, which is mathematics and logic, data structures, and algorithms, as solved using a computer, I would say you should be eternally thankful for such a rare professor. It's like these ridiculous frameworks that Lerdorf is on video saying, "They all suck", and he actually means it.

The so-called Object Oriented programming hoax been debunked ad nausea, and disavowed by all the greatest algorithm icons, such as Djisktha. But the cult, like all cults, lives on. I was amazed to watch this transition unfold, dumbfounded that people would rationalize this snake oil. I literally quit the industry because of this hoax. And that was in fact the point, to get rid of costly ping-pong playing cool engineers who earned more money and had more control of the company then the jealous managers and executives.

We used to call the executives white collar workers, and the software engineers gold-collar workers. Like the car replaced the horse, this happened too fast for the executive class, which is why they so easily embraced this Object garbage. Also, sales people could sell to executives by answering any question by saying "you can do that by just creating a [insert buzzword] object", and they could both agree while neither had to admit they had no clue what they were talking about. I have sat in on more than enough of these meetings.

A computer only manifests real world problems in electronic form. Since there's no such thing as an object oriented problem, or design patterns, and since there is no such thing as object oriented electrical engineering, or object oriented [insert engineering problem here], this entire cult is a farce, which was embraced by managers, in the real world, because managers were seething at software engineers earning two, three, and four, and up to ten times their salary.

That's because software engineers were worth it. Now that programmers do nothing more than destroy their own software by using "Objects" (which is, by definition, meaningless), programmers' salaries are once again down to salaries below their managers. A manager, in the real world, would rather hire eight Object programmers who write Object Gordian knots of useless, unmaintainable, literally untraceable, band-aid upon band-aid of fake methods and inheritance and objects and patters and all those other fake concepts, than to hire one actual software engineer at eight times his salary.