53

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?

Buffy
  • 35,808
  • 10
  • 62
  • 115
olegario
  • 643
  • 1
  • 5
  • 7
  • 13
    Are they teaching the data structure and code organization concepts behind design patterns? –  Feb 16 '19 at 19:47
  • @Patricia they teach Data Structures and the only Code organization concept is MVC – olegario Feb 16 '19 at 19:54
  • 85
    Better than average, I would say! – hobbs Feb 17 '19 at 01:20
  • 45
    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. –  Feb 17 '19 at 03:50
  • 57
    *"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: https://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. – Ben Cottrell Feb 17 '19 at 08:21
  • 48
    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! – alephzero Feb 17 '19 at 13:41
  • 3
    Note: The original design patterns boot has about 20 patterns, and states that this is all there are. It also discusses MVC, but does not list this as a pattern. The book that inspired this one “A Pattern Language” — Christopher Alexander, has about 250 patterns, and states that this is not them all, there are many others. This book is worth a read (When you have some experience). As are the other 2 in the series (“The Timeless Way of Building”, and “the Oregon Experiment”) You should also read his later works, “The Nature of Order” – ctrl-alt-delor Feb 17 '19 at 23:33
  • 21
    @alephzero, I think that "*cargo cult*" is a better analogy here than snake oil. – Peter Taylor Feb 18 '19 at 09:12
  • 2
    As a senior programmer with 17 years of experience I can already tell that you're expecting way too much from your CS course. University programming education is more of a hobby, with very little relevance to industry. Programming for style is not at all what programming for money is. Sit back and enjoy the course while it lasts, but your actual education will start with your first job - and will never end since then. – Agent_L Feb 18 '19 at 11:07
  • 11
    Speaking as a programmer with 40 years of experience, what's a "design pattern"? – Hot Licks Feb 18 '19 at 13:12
  • 5
    @PeterTaylor It's "cargo cult" for the honest folk, and "snake oil" for the shifty guys :P – Luaan Feb 18 '19 at 13:46
  • 6
    Honestly, I would say that design patterns warrant at most one optional course in a CS degree, and at that, it would be *theory* of design patterns, rather than any concrete example. Most design patterns are heavily linked to a particular language, and some languages flat out don't have any design patterns, or have at most one that covers everything. It after all a CS degree and not a programming certification. – Steven Armstrong Feb 18 '19 at 17:59
  • 3
    @alephzero I think that design patterns have their place, but their real purpose is unfortunately frequently misunderstood and their importance often exaggerated, see also [this discussion on softwareengineering.se](https://softwareengineering.stackexchange.com/questions/9219/). – Discrete lizard Feb 18 '19 at 19:01
  • 3
    The advice in the Jargon File for new hackers to learn a LISP (for "the profound enlightenment experience you will have when you finally get it") is relevant here. What a C++ developer needs to codify as "design patterns" are merely macros in a LISP, and can be thus used as library functions with no need to reimplement them over and over. – Charles Duffy Feb 18 '19 at 20:51
  • 5
    @BenCottrell SOLID and GRASP are just as harmful as any design pattern. They result in the same sort of dogmatism that leads to nightmare code. The only valid metric of code quality is what-the-hecks per minute. – jpmc26 Feb 19 '19 at 01:25
  • 3
    @jpmc26 I think you may misunderstand SOLID and GRASP - they are merely sets of principles (i.e. guidelines), and not rules to be followed dogmatically as you suggest -- quite the opposite in fact, they aren't measurable nor can they be defined in any objective terms, if someone happens to treat them this way then they've completely missed the point of those principles, which I can well believe would lead to nightmare code, but only as a result of plainly misunderstanding what those principles are and why they exist, rather than as a consequence of following their advice. – Ben Cottrell Feb 19 '19 at 12:52
  • 2
    Reading [The Perils of Java Schools](https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/) by Joel Spolsky (one of the cofounders of Stack Exchange) leads me to believe that it is potentially a sign of *quality* to not have such a class. Outside of the over-engineered Java (or C++) world, such things don't play such a prominent role (which isn't to say that they play no role). – John Coleman Feb 19 '19 at 13:24
  • 5
    FWIW: I took my SE class in 1988, before "Design Patterns" were A Thing, and people still seem to accept that my degree is a valid CS degree. – T.E.D. Feb 19 '19 at 15:10
  • 2
    Remember what happened when Robert Pirsig tried to teach 'quality' in college... – Scott Rowe Feb 20 '19 at 00:34
  • 1
    @BenCottrell I don't. The easiest example is that I've seen pervasive dependency inversion regularly lead to incredibly weird and difficult to follow object trees, even *encouraging* shared stateful objects (database connections) that are quietly injected into the lowest level of dependencies. It was difficult to follow what actually happened to a connection in a given code path. As for "not rules to be followed dogmatically," the same could be said for design patterns. The problem is precisely that people take them too far, replacing understanding and wisdom with pervasive blind application. – jpmc26 Feb 20 '19 at 00:55
  • @ScottRowe - Yeah, he went crazy. – Hot Licks Feb 20 '19 at 01:27
  • @HotLicks: Design Patterns are observations about the horrible things OOP programmers do, presented as something to mimic... – R.. GitHub STOP HELPING ICE Feb 20 '19 at 03:23
  • 1
    @R.. I try not to mimic programmers who go OOPS! – Hot Licks Feb 20 '19 at 03:33
  • @jpmc26 *"The problem is precisely that people take them too far, replacing understanding and wisdom with pervasive blind application"* - surely that's all the more reason to have proper teaching of those principles? The example you mention with dependency inversion sounds like it actually violates the principle ('Details should depend upon abstractions'). – Ben Cottrell Feb 20 '19 at 07:17
  • 2
    @BenCottrell They're too subjective for them to be taught "properly." They're not tied to anything concrete. Having them taught "properly" would be even harder than doing so with design patterns. If we can't get that right, there's no way we could with something as subjective as SOLID and GRASP. Your response to my example demonstrates this subjectivity and lack of clarity. FYI, they did "depend on abstractions;" the system pervasively used interfaces for everything. This could even be turned into an argument *for* the design: callers did not need to reference a connection. – jpmc26 Feb 20 '19 at 08:18
  • Your headline is another question than your question itself. Are you talking about a computer science course (headline) or a software engineering course (question text)? A SE course probably should include patters, almost every other course probaly does not have to and probably should not. computer science courses should teach principles, programming courses should teach programming without such overhead. But software engineering courses of course probably should teach such things. Please clarify if we're talking about a software engineering course or not. – allo Feb 20 '19 at 09:07
  • Title is "begging the question" - a better form would be eg. "Should a good CS course always teach Design Patterns". IMHO, no - but it should be in the Programming modules. – MikeW Feb 20 '19 at 09:55
  • @jpmc26 How could a topic be 'too subjective' to be taught properly? Many academic courses require students to think and understand subjective material, otherwise if CompSci were only to include objective topics then that leads to precisely the problem you mention of students mindlessly sticking to dogma because they haven't had the opportunity to learn to understand the rationale behind these principles nor judge these things for themselves. – Ben Cottrell Feb 20 '19 at 16:33
  • 2
    Are you using "course" to mean "degree program"? In the US, standard use of "course" is to mean "class". – Acccumulation Feb 20 '19 at 17:55
  • @BenCottrell By being "counter-productive if it results in re-enforcing a misguided way of thinking about OO design." This is exactly what I see happens with SOLID. SOLID is *not* practical advice that can be applied to the process of writing code. It's a list of abstract, easily misapplied, hard to understand criteria that purport to describe a high quality end result (though whether it even necessarily identifies qualities that are actually important is up for debate). And it is the subjectivity of its ideas that lead to such diverse ideas about what in the heck it's even supposed to mean. – jpmc26 Feb 21 '19 at 05:08
  • @jpmc26 It's not about teaching practical advice, and it's not specifically about teaching SOLID either (GRASP and SOLID are only part of the picture) - it's about getting students to think for themselves by challenging them to grapple with the issues around software design so that they understand it's not a prescriptive process. If students are never asked to think about concepts such as cohesion, coupling, separation of concerns, abstraction, dependencies, etc then they will enter the job market in a weak position, and more likely to misapply SOLID or even just create a Big Ball Of Mud. – Ben Cottrell Feb 22 '19 at 00:59
  • 1
    @BenCottrell On the contrary, I find people who are intent on following SOLID at least as likely (if not more so) to create Big Balls of Mud. All of the principles and concepts you have mentioned are at best unhelpful in avoiding that. Our "theories" about how to build good code do not work. Even *having* these poor acronyms and overhyped terms invites people to misapply them in ways that are harmful to a code base. If we want to teach something, then practical ways of evaluating code quality is what we need to be focusing on, not these useless buzzwords. – jpmc26 Feb 22 '19 at 03:20
  • 1
    @BenCottrell I don't agree with *everything* in this talk and I understand that languages don't always have the features to make all the particular simplifications possible, but it still describes a better philosophy toward writing code than SOLID or GRASP or any of that stuff: https://youtu.be/o9pEzgHorH0. To sum it up, it basically says not to make anything more complicated than it has to be. The fact we don't spend enough time teaching people to be this practical is a major, major problem. – jpmc26 Feb 22 '19 at 03:55
  • 1
    @jpmc26 You don't seem to be reading what I've said -- it's **not** about getting students to *follow* anything, it's about teaching them to *think*. At this point we seem to be talking past each other, and you seem to be hung up on issues you've had with programmers who clearly didn't bother to think. Just to repeat once again, the purpose of teaching software design is all about challenging students to think about software design, and not about "following" rules. If students aren't encouraged to think at university, then they're more likely not to think at all when they're in a job – Ben Cottrell Feb 22 '19 at 12:53
  • @BenCottrell I read what you said. You don't seem to be grasping that whatever your intention is, that *isn't* the result you actually get. The programmers I worked with thought *a lot*, but buying into the popular OO ideas clouded their judgement. As I often see it do here on SE. Have [an example](https://codereview.stackexchange.com/questions/212381/versatile-string-validation/212432#comment410907_212432). – jpmc26 Feb 22 '19 at 13:05
  • 1
    @jpmc26 So when do students learn about software design then? Because they *will* be required to learn one way or another as soon as they enter the workplace and are asked to join a team working on any reasonably large, non-trivial project with other software engineers. They can either learn it at university when they've got the time to research the topic properly, or they can be forced to learn it under far less than ideal conditions when there are deadlines and stakeholders. – Ben Cottrell Feb 22 '19 at 13:15
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/90084/discussion-between-jpmc26-and-ben-cottrell). – jpmc26 Feb 22 '19 at 13:15
  • 1
    I'm confused by the question; here's a way you could clarify it. Is a course in *astronomy* that does not teach *how to build a telescope* a bad course or a good course? Is a course in *physics of structural engineering for buildings* that does not teach *how to design an elegant courtyard* a bad course or a good course? You're asking a question about two things that have almost nothing to do with each other but your question indicates that there is some connection in your mind; can you explain what it is? – Eric Lippert Feb 22 '19 at 19:26
  • @EricLipper Agree entirely. In the design patterns epidemic of the late 1990s there seemed be a sustained attempt to reduce all of CS to design patterns. It failed miserably, like all other attempts to impose magic on science. Even back in the 'top-down' days I remember thinking that this approach would never tell you how to write a compiler. Curiously enough Wirth, a compiler writer, was a proponent. Knuth said mildly that he preferred to think bottom-up ... – user207421 Feb 23 '19 at 02:59
  • Imho the only benefit in learning design patterns is that you can quickly speak about implementations in a team without having to verbosely explain your solution since the pattern has a name. Much more important than knowing design patterns is knowing anti-patterns to avoid running in non-obvious issues which others already did frequently before you. – Pinke Helga Feb 23 '19 at 14:46
  • For the majority of the history of CS, design patterns hadn't been "discovered". At least, the term. "Algorithms + Data Structures = Programs" was the closest I remember from college. – Rob Crawford May 10 '19 at 14:29
  • I love design patterns. However, it is more a "how do we work together in a big programming team" than a CS issue. – Sascha Dec 16 '21 at 14:20

11 Answers11

159

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
  • 35,808
  • 10
  • 62
  • 115
  • 5
    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. – The_Sympathizer Feb 17 '19 at 04:21
  • 1
    Or in simple terms, a CS program must include much more than _just_ design patterns, but if you take a program that is '_just_' that "much more", and compare it to another program that is 'just' that "much more" _plus_ design patterns, it would seem the latter would be a better/more comprehensive program than the former. Moreover, especially if the latter program teaches you the _thinking_ behind the patterns, which I'd think more important than the specifics themselves, as that is how you will truly understand _why_ they are used and _when_ to use them. – The_Sympathizer Feb 17 '19 at 04:24
  • 6
    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. – Josiah Feb 17 '19 at 08:24
  • 7
    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). – Theodoros Chatzigiannakis Feb 17 '19 at 12:27
  • 1
    There are lots of things that could be taught in addition to the existing curriculum, but at some point we'd have to acknowledge that we need more time to do so. University gives you the theoretical background to read up on the things that didn't fit. – Simon Richter Feb 17 '19 at 16:34
  • 10
    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. – Graham Feb 17 '19 at 21:07
  • 2
    @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. – The_Sympathizer Feb 19 '19 at 03:46
  • @The_Sympathizer I feel like that would be more of a "Design" class rather than a "Design Patterns" and said "Design Patterns" class would be more applicable to software engineering than computer science. – Jake Feb 19 '19 at 20:47
  • 1
    Re:"...Corrections for flaws....Many of the kinds of things that design patterns accomplish...in more natural ways within Common Lisp...". Those are such pointless comments. Many kinds of things can be accomplished more naturally in C++ than Lisp because of flaws in Lisp. However, Lisp programmer's learn tricks to work around and implement those things. IOW, they use design patterns whether they want to call them that or not. At the time the Design Patterns book came out, C++ was the overwhelming OO'ish language of choice. Thus, they are obviously more applicable to the C-family of languages. – Dunk Feb 20 '19 at 20:14
  • Yes, as I have told some students who complained about abstract concepts in their degree, "If you just wanted to learn to code you could have gone to a training course." – Artelius Feb 22 '19 at 22:22
  • At my university I learned that the advantage of knowing the names of the design patterns is that you can communicate them easily to fellow team members. This wouldn't be possible if you don't know their names. – Sandro Feb 23 '19 at 14:07
52

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.

Erwan
  • 621
  • 4
  • 4
  • 17
    +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. – Patricia Shanahan Feb 17 '19 at 00:41
  • 2
    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 :) – Luaan Feb 18 '19 at 13:53
  • 2
    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). – Luaan Feb 18 '19 at 13:55
33

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.

Lightness Races in Orbit
  • 431
  • 3
  • 5
  • 1
    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. – Luaan Feb 18 '19 at 14:05
  • @Luaan Well, that may be true, at the implementation layer. I'm talking about the design layer :) – Lightness Races in Orbit Feb 18 '19 at 14:25
  • 2
    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#. – Yakk Feb 18 '19 at 21:21
  • 7
    @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. – user207421 Feb 23 '19 at 03:05
  • @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. – gnasher729 Feb 24 '19 at 10:58
15

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.

Peter Mortensen
  • 139
  • 4
PerformanceDBA
  • 259
  • 1
  • 4
  • 3
    *"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. – vsz Feb 18 '19 at 07:13
  • 3
    @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. – Luaan Feb 18 '19 at 14:00
  • 2
    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). – Steven Armstrong Feb 20 '19 at 16:02
  • "Brazil is actually less damaged than many Western countries". Why is that so? I'm curious about it. – taavs Feb 22 '19 at 13:18
  • 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". – IMSoP Feb 23 '19 at 20:47
  • “methodologies and standards (unless you work in China)” why ? I am not offended but curious. – Qiulang 邱朗 Jan 01 '21 at 15:22
12

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.

Colin 't Hart
  • 241
  • 1
  • 4
  • 1
    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. – Buffy Feb 17 '19 at 13:40
10

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.

igordsm
  • 680
  • 3
  • 6
  • 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. – Jörg W Mittag Feb 24 '19 at 22:36
  • @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. – igordsm Feb 26 '19 at 11:58
8

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.

Peter Mortensen
  • 139
  • 4
T.E.D.
  • 357
  • 1
  • 5
  • 2
    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. – Buffy Feb 19 '19 at 15:54
  • 1
    @Buffy - Heh. Disagreeing with an accepted SO post that has over a **thousand** upvotes (and only 25 down). Ballsy that. You're horribly wrong, but I give you points for taking a stand. I'll tell you that we found out how right that post was the hard way. But some of us only learn that way. – T.E.D. Feb 19 '19 at 16:25
  • 3
    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. – Buffy Feb 19 '19 at 16:32
  • @Buffy - However, in this case the crowd is spot on. Singletons destroy testability and make future design tweaks really problematic for no good reason. If you only want one in your current design, [only make one](https://codeahoy.com/2016/05/27/avoid-singletons-to-write-testable-code/). Problem solved. And now when you need to write unit tests, or discover three years from now that you need two copies of the entire application running at once, its not a gigantic self-inflicted redesign problem. – T.E.D. Feb 19 '19 at 16:43
  • 2
    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. – Buffy Feb 19 '19 at 16:52
  • Design Patterns are simply a common set of names for practices we all figured out ourselves at some point (or would figure out once we needed them). If I called my thing a singleton and you called it a controlled-instance we wouldn't make much headway in conversation. They also tend to show implementation details you may not have thought of. You can design without them, but if you are working on a team you will have difficulty communicating. If you haven't at least skimmed the design patterns, don't call yourself a professional--same if you rely on them exclusively. – Bill K Feb 19 '19 at 22:31
  • 3
    @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. – Gypsy Spellweaver Feb 20 '19 at 01:01
  • 2
    @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. – Bill K Feb 20 '19 at 01:44
  • In @Buffy's defence, he's not being so "ballsy". The post you linked to supports his position more than yours once you delve into the comments. Even the author of said post asserts that they are needed from time to time: https://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons#comment2667126_138012. – Ben I. Mar 14 '19 at 10:51
  • @BenI. - No, he said he *uses* them from time to time, not that they are needed. Being a purely a defensive measure (over simply only creating one of the object in question), they are never *needed*. – T.E.D. Mar 14 '19 at 12:58
  • Fair enough. And, in your defense, you also didn't say to never use them, you said "almost never". Everything has its time and place. :) – Ben I. Mar 14 '19 at 16:22
4

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.

Bill K
  • 209
  • 1
  • 4
3

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

supercat
  • 189
  • 4
3

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.

CL40
  • 131
  • 2
  • "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! – Rob Crawford May 10 '19 at 14:56
2

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.

Miles B.
  • 136
  • 1
  • 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. – Buffy Feb 19 '19 at 21:39
  • @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. – Miles B. Feb 19 '19 at 22:20