53
$\begingroup$

I'm at final year of my graduation in Computer Science in Brazil. The university that I study is one of the best in the country and my passion is for Software Engineering. It disappoints me, in Software Engineering classes, that no Design Patterns are taught at all, my professor only commented about their existence. From my point of view, this is terrible for every student, because 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. So I'm thinking, this can reduce the quality of the course?

$\endgroup$
  • 84
    $\begingroup$ Better than average, I would say! $\endgroup$ – hobbs Feb 17 at 1:20
  • 43
    $\begingroup$ In my experience learning design patterns in school was pointless. Worse than pointless actually; some of the students listened to their professors and started using them in their jobs :) Lots of computer scientists in academia have very little "real world" software engineering experience because it's not their job to be software engineers. They construct their theory, build their proof of concept, and publish their work, leaving the work of commercialization to others. Learn the theory in school, learn the engineering on the job. $\endgroup$ – Relish Feb 17 at 3:50
  • 55
    $\begingroup$ "problems in the real world, both in academia and in the industry, can be more easily handled with a good choice of design pattern" - I'd disagree with this way of thinking and recommend reading this for a different view: softwareengineering.stackexchange.com/a/227880 - Overall, learning "patterns" often isn't useful to an undergraduate or junior programmer, and could even be counter-productive if it results in re-enforcing a misguided way of thinking about OO design. It's far better to focus on the underlying software design principles such as 'SOLID' and 'GRASP' instead. $\endgroup$ – Ben Cottrell Feb 17 at 8:21
  • 47
    $\begingroup$ In computer science, as in every other endeavour, snake oil is not a substitute for thought. Design patterns are not necessarily snake oil, but they are often used that way. See many "answers" on the programming forums here for examples of "the best way" to do something by replacing 5 lines of straightforward code with 100 lines that conform "better" to the latest (often half-understood) whims and fancies of the currently fashionable software design gurus. Of course if your productivity is measured by LOC (more snake oil, of course) then "longer" is "better" by definition! $\endgroup$ – alephzero Feb 17 at 13:41
  • 20
    $\begingroup$ @alephzero, I think that "cargo cult" is a better analogy here than snake oil. $\endgroup$ – Peter Taylor Feb 18 at 9:12

11 Answers 11

154
$\begingroup$

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.

$\endgroup$
  • 5
    $\begingroup$ The last paragraph here doesn't seem to make a lot of sense as to its necessity here. The OP is not saying that a good CS program should only include "design patterns", but that for missing that one component, it is worse off (not a failure, but reduced, i.e. incrementally, in quality - in fact the words "reduce the quality" were the exact ones used) than a program that would have included it. Just like one skimping on algorithms, or on any of the other components you mentioned there, would be a worse off program than one that did not skimp. $\endgroup$ – The_Sympathizer Feb 17 at 4:21
  • 6
    $\begingroup$ As a specific example, one of the more famous patterns is a singleton. If you use java or the likes, this requires a particular combination of static pointers and private constructors to do properly. However if you are working with the language Scala, singleton is built in. You make a class as usual but call it an object rather than a class and everything works. This is why it is more important to learn to think about concepts like "I want this exactly once" than the detail in a particular language. Barring experience, a good CS degree would leave you equally prepared to learn any language. $\endgroup$ – Josiah Feb 17 at 8:24
  • 7
    $\begingroup$ It would be amazing if a course taught both the OOP design patterns and the "missing" features that they replace (e.g. visitor pattern <--> double or multiple dispatch, etc). $\endgroup$ – Theodoros Chatzigiannakis Feb 17 at 12:27
  • 10
    $\begingroup$ Not just "primarily" C++. Gang of Four design patterns are inextricably linked to C++. Whilst some of the concepts (e.g. multiple dispatch) are common across OO architectures, the Gang of Four patterns are purely C++ implementations of those higher concepts. It's notable that the patterns only cover features absent from C++, and do not start from the elemental features of OO such as member data and functions. $\endgroup$ – Graham Feb 17 at 21:07
  • 2
    $\begingroup$ @Josiah : True, but to me, in this case, "design patterns" is about concepts. It's not merely about how they can be implemented - and even then, learning how they are gives you an idea of what is going on under the hood even if you're using a language where that you don't have to actually write that implementation yourself as it's provided for you. If you don't know what a singleton is , when it's useful, when it should not be used, why that is, and so forth, then it doesn't matter whether the language has it or not. And that , imo, is what a good DP course should cover. $\endgroup$ – The_Sympathizer Feb 19 at 3:46
52
$\begingroup$

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.

$\endgroup$
  • 17
    $\begingroup$ +1 especially for the last sentence. I think programming will change enough to make design patterns obsolete in much less than the 40 to 50 years of a human career. Knowing how to learn and adjust to changes will go on being useful. $\endgroup$ – Patricia Shanahan Feb 17 at 0:41
  • 2
    $\begingroup$ To be fair, there's plenty of university courses that are also evolving very quickly (e.g. chemical engineering) that handle it better. To me, it (sadly) seems that many CS courses are done just for the form, rather than the essence - it's important to have a CS course, so we have a CS course. It doesn't have any real purpose, you see, but... It's also disturbingly common to see people who have no real-world experience teach various aspects of CS. It reminds me of Feynman's famous reflection on the quality of Brazilian university education back in the day :) $\endgroup$ – Luaan Feb 18 at 13:53
  • 2
    $\begingroup$ Even worse, many of the things that are being touted as the best and brightest today are things that were developed decades ago. The good CS courses didn't have to change any of the fundamentals, because the fundamentals didn't change since the first ideas of electronic computers. Only the details change (as important as those details are, mind you). The only courses that need to change much are those that are either actually bleeding edge, or were more concerned with day-to-day practicalities rather than the actual science (for better and worse, mind you). $\endgroup$ – Luaan Feb 18 at 13:55
32
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ I'd argue it was a problem-solving tool - or rather, when you realized "Oh, this looks like a Visitor", you could go to the ready library of visitor-implementations to avoid having to write everything again, with a new set of mistakes in the implementation. $\endgroup$ – Luaan Feb 18 at 14:05
  • $\begingroup$ @Luaan Well, that may be true, at the implementation layer. I'm talking about the design layer :) $\endgroup$ – Lightness Races with Monica Feb 18 at 14:25
  • 2
    $\begingroup$ I came to say this, and you saved me typing. As for "ready library of visitor implementations"; in my experience, only if you are already committed to some "framework". I mean, imagine importing Qt just to add signals and slots to your application. Possibly this is different in "framework languages" like Java/C#. $\endgroup$ – Yakk Feb 18 at 21:21
  • 7
    $\begingroup$ @Lusan Nonsense. There is no 'ready library of visitor-implementations'. Every one has its own purpose. That is the whole idea. Design patterns is not a library, it is a technique. $\endgroup$ – user207421 Feb 23 at 3:05
  • $\begingroup$ @user207421 Can't state that any stronger. And if someone writes code in Swift, the whole "visitor pattern" disappears, because instead of creating some "Visitor" class you just pass a closure as a function argument. $\endgroup$ – gnasher729 Feb 24 at 10:58
14
$\begingroup$

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.

$\endgroup$
  • 3
    $\begingroup$ "It teaches you to look at the problem in terms of a predefined set of solutions" - ohh, this reminds me of applicants I interviewed who could easily put together a Java application which skimmed some famous website for data, presented it in a nice UI, and did other interesting things, by combining the perfect free libraries for the task, but utterly failed fizzbuzz-style tasks. I've even seen one who couldn't write a code to determine which one of 3 integers is the largest. He couldn't find the library which would do it for him. $\endgroup$ – vsz Feb 18 at 7:13
  • 3
    $\begingroup$ @vsz To be fair, it's not like there isn't a market for those kinds of guys :) In the end, you've got a job to do - and if you can do it better, good for you. Some jobs require you to be good at analytical thinking and comparing integers; for some, the issues are purely academic. Hey, it's not like any other engineering discipline has it any different - it's just that software engineering just isn't quite mature in that way yet, and we still expect every software engineer to be able to (with some training and experience) replace any other software engineer. $\endgroup$ – Luaan Feb 18 at 14:00
  • 2
    $\begingroup$ Mostly agreed, except for IDEF0, SSADM. They should definitely be there as an option but definitely not a requirement. They're more SoftEng than CS (unless your University merges those... then I guess they should be there). $\endgroup$ – Steven Armstrong Feb 20 at 16:02
  • $\begingroup$ "Brazil is actually less damaged than many Western countries". Why is that so? I'm curious about it. $\endgroup$ – taavs Feb 22 at 13:18
  • $\begingroup$ There are a few truths buried in here, but most of the answer reads as a pompous rant, pushing a very narrow view of the "correct" university course. Apparently, I was taught wrong, because I've never heard of SSADM or IDEF0; maybe they're "some irrelevant thing from last year that everyone has forgotten about this year because there is a new fad and terminology". $\endgroup$ – IMSoP Feb 23 at 20:47
12
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ Your last statement is problematic. I could certainly "mention" them in one lesson, and I might be able to "cover" them. But I wouldn't be able to actually teach them. Maybe that is the level of discussion that the OP is complaining about. $\endgroup$ – Buffy Feb 17 at 13:40
10
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ The GoF book is also more a "catalogue" of patterns, whereas correctly organized, patterns should come in the form of a pattern language. A lot of people seem to use the GoF book as a recipe for designing systems, which it is not. It is a catalogue of patterns where you can look up a pattern when you already know you need it. For discovering which patterns you need, you need a pattern language. $\endgroup$ – Jörg W Mittag Feb 24 at 22:36
  • $\begingroup$ @JörgWMittag makes a good point. The GoF book is not a textbook and it is by no means didactic. Pretending it is written for beginners and using it in undergraduate-level courses is not very good teaching, IMHO. $\endgroup$ – igordsm Feb 26 at 11:58
8
$\begingroup$

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.

Three 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 1980s, 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 Wikipedia 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 six things in all the other tables that I can say I've used over the years, when needed, but it's 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 software engineering class not being pattern-focused. You can get by just fine without them.

$\endgroup$
  • 2
    $\begingroup$ Your general advice (don't worry about it) is sound. But the specifics are deeply flawed. Don't criticize patterns because they don't do anything new. That is an intended characteristic of patterns. Capture good practice in an easily transferrable way. They are explicitly NOT about invention. You are wrong specifically about singleton (as is much of the linked post). There are applications in which singletons are required. Don't criticize them just because some people misuse them badly. The are not a hack to get globals. They are needed when logically there is only one instance. $\endgroup$ – Buffy Feb 19 at 15:54
  • 3
    $\begingroup$ On the other hand, I've been a member of the patterns community since GOF was issued. I'm also one of the few to know that GOF wasn't actually the first patterns book, though it was the first to use the name in such a public way. The "wisdom of crowds" sometimes isn't, of course. $\endgroup$ – Buffy Feb 19 at 16:32
  • 2
    $\begingroup$ Patterns capture design decisions for the future as well as the present. Yes, I only create one. Some future maintainer might not remember all of the design decisions previously made. So, in good software, we try to capture those decisions so that they aren't easy to subvert - especially by accident. Enums do a similar sort of thing. Build your software do that you don't need to keep every decision in your head perpetually and expect that others will have the same understanding. $\endgroup$ – Buffy Feb 19 at 16:52
  • 3
    $\begingroup$ @BillK The bulk of the last comment is worthy. The closer, however, is not. I was a "professional" long before GoF 'Patterns' ( or C++) existed. I have still not read that book, or any related material. I also do not believe I need to because I do not need to reduce my conversations to cliches or shared inaccurate nomenclature. Don't tell me which 'pattern' you code almost implements, explain what it does and how you can prove it does it correctly. $\endgroup$ – Gypsy Spellweaver Feb 20 at 1:01
  • 2
    $\begingroup$ @GypsySpellweaver I suggest you at least skim it. It's asked in enough interview questions today that you are severely restricting your job search if you don't. I've also coded since the 80's, before patterns existed and when I read the book I recognized nearly all the patterns as ones I've created at one point or another in my career. It's not going to teach you how to code, just how to communicate more efficiently. My point above was that resisting knowledge like this is not professional. A professional programmer is constantly improving himself with all the tools he can find. $\endgroup$ – Bill K Feb 20 at 1:44
4
$\begingroup$

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.

$\endgroup$
3
$\begingroup$

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".

$\endgroup$
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ "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." If only I could convince our R&D department of that! $\endgroup$ – Rob Crawford May 10 at 14:56
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ It's just possible that I know the person who taught your course. A friend taught there about then and was influential in the patterns community. But today, I wouldn't make it a separate course. You would just learn the techniques in CS1 CS2 while learning to program, assuming it was in an OO language. A real OO design course would normally be at a higher level than the GOF patterns. There are real architectural patterns of course. $\endgroup$ – Buffy Feb 19 at 21:39
  • $\begingroup$ @Buffy - Our design patterns elective was a 400 level coarse. Our professor was actually a software architect at Disney who flew down once a week just to teach the one class. $\endgroup$ – Miles B. Feb 19 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.