Hacker News Reader

Comment by genericuser | Hacker News Reader

My software engineering class spent most of the semester going over design patterns which are in fact quite useful to learn in school. And then maybe 1/4 of the class on going over the various development methodologies. I agree that a class devoted entirely to methodology would be complete over kill. However I think there is room for getting some exposure to it in school. Ideally before taking higher level classes, where having knowledge of a existing ways to structure your group work will be beneficial.

View on HN

The problem is design patterns are subjective, they are craft, not science or engineering.

There hasn't been enough work serious research done on "Software Engineering" to call Engineering with a straight face. You can't point a whole stack of serious research to say the design pattern A is objectively better in situation X because Y and Z.

What you can say is that design pattern A is currently in vogue so you should probably use it, while design pattern B has fallen out of favor in industry, so you should avoid it.

That is something that belongs in a vocational training program or an internship/apprenticeship not in a university Computer Science education.

Design patterns are models, something very much within the wheelhouse of engineering. Engineering doesn't always deal with absolute facts as in science. When an underlying system is too complex to fully describe, simplified modeling can be appropriate.

Models are used to get a better of understanding of a complex system, or to test a complex system when you can't test the real thing. A design pattern could be used to this way but they aren't. They are used as a design methodology that you are encouraged to follow.

They also aren't based on any formal theory. They are based only on the experience of the people who create them. They are almost the definition of a craft (as opposed to engineering).

In an actual Engineering discipline you would need evidence to prove that your model fits reality as opposed to just trusting the experience of a few guys who wrote a book.

From my experience design patterns are both taught and used as a starting place for solving a problem which is recognized as similar to a problem which was previously solved effectively with in the manner of the pattern. Rarely will the design pattern fit perfectly as the solution, but by recognizing and using the correct one as a starting point for many architecture related problems you can greatly reduce the work involved, in creating the solution.

They keep people from re-inventing nearly identical solutions over and over, and allow for a vocabulary which can express rather complex ideas because fellow practitioners of software engineering generally know many of the same design patterns. This saves time and reduces the opportunity for miscommunication when expressing a more complex idea (assuming the person you are talking to doesn't lie and for instance say they are familiar with the facade pattern, when they are not).

To me this is using them to both get and express a better understanding of a complex system. I am also able to understand code for new projects I am to work on much quicker when I understand the underlying design of the elements. When the elements are designed with a structure that resembles things I am familiar with this process becomes fairly easy.

I see them as things like definitions of 'Suspension Bridge', 'Victorian House', 'Tunnel', or 'Dog House'. Sure we might see a book consisting of very rudimentary definitions of structures like these as being absurd, for the corresponding type of engineer, but that is because of our familiarity with the form these structures take. That familiarity with the form is the point of design patterns in my opinion. And I believe their utility is indispensable should we want to continue building more complex structures in code.

I have no problem with design patterns as a concept. And I have no problem with design patterns being taught as the collective folk wisdom of wise sages of industry.

However, design patterns are craft, not engineering, and should be taught as vocational training--not as an academic subject.

Design patterns have no rigorous underpinnings. They have very little academic research to back up their efficacy. The only "proof" we have that the design patterns being taught are beneficial is the word of a few guys who wrote a book and the collective folk wisdom of industry.

There is nothing wrong with this, but it isn't firm foundation for an academic subject.

Again we see another Dijkstra soldier pushing the corrosive "software programming is complex" ideology. Notice how they are the same group as Martin Fowler followers.

> "They keep people from re-inventing nearly identical solutions over and over"

No, they force users to rewrite the patterns over and over again, since a pattern is an idea that a given language is not powerful enough to abstract over. Cf. opinions on the C2 wiki.

Maybe that's why you think what we do is "too complex to fully describe" - you haven't used a language that allows you to abstract at will.

OK, just cool your jets mister, everyone here is having a pretty civil conversation without you attacking people for 'pushing corrosive ideology'.

And in order to formulate that attack you pieced together quotes from two completely differently messages and people to make your 'point'.

I said they keep people from re-inventing solutions, however it was the comment you actually replied to which else claimed they were too complex.

I agree they are patterns which languages do not yet abstract over, but until languages do I think they are very useful patterns for programmers to be able to correctly recognize as they occur frequently enough that knowing the pattern saves a lot of time and work. When languages can successfully abstract over those patterns, then knowing them will be niche knowledge assuming new patterns cease to be detected by humans prior to their ability to be abstracted by a language.

> OK, just cool your jets mister, everyone here is having a pretty civil conversation without you attacking people for 'pushing corrosive ideology'.

Please.

Rhetoric = Ethos + Logos + Pathos

Unless you want to believe I chose my words while extremely angry at you personally, and unless you want everyone to never use pathos and talk like robots in perfect clauses and rebuttals connected in an acyclic directed graph, I suggested you get used to this very common rhetorical necessity.

You're going too far when you dismiss design patterns as being merely fashion. Just because something is not objectively proven doesn't make it false. Things in the real world are not binary, where they are either objectively proven (hard sciences) or completely false ("The earth is flat"). In reality, lot of things are gray. Design patterns fall in that bucket — many of them help, as long as you remember that there are exceptions.

If many people learnt over and over again that global state, for example, leads to more bugs, you'd be wrong in completely dismissing it just because it isn't objectively proven. Because then you'd be arguing that a program that uses only global variables is just as good as one that's properly encapsulated and abstracted. Do you think anyone would take you seriously if said that?

I don't have a problem with design patterns as a concept. But you need to recognize them for what they are--folk wisdom. Some of it is useful, much of it isn't.

If there is no theory we have to fall back to empirical analysis, and unfortunately our industry hasn't done much of that. The only thing we have to go on is the general "consensus" of the industry, which is cyclical, transient and mostly fashion.

Some of the industry folk wisdom if beneficial and withstands the test of time. Most of us agree that encapsulation is nice. However, we don't agree on what form that encapsulation should take.

OO programmers argue that state should hidden away inside objects, functional programmers believe that state should be explicit and we should always try for pure functions and immutable data when possible. There's very little objective data to support either side (except that functional programming languages tend to have more formal underpinnings). Mostly it falls back to personal preference, which programmer sages you trust, and what the current industry fashion is.

Our industry reinvents the wheel time and again because we are slaves to the cyclical nature of the industry fashion.

Relational Algebra/calculus has been formalized for decades, yet people who don't understand relational theory cried out for something "simpler" and thus NoSQL was born. Fast forward 5 years and you'll find many of the people championing NoSQL had to reinvent most of the tough problems that CS had solved decades ago.

Again, there is nothing inherently wrong with craft and folk wisdom--just like there's nothing wrong with learning salary negotiation, but they don't belong in an academic CS environment. These things are best taught in an internship/apprenticeship after you've learned the underlying theory.

Reply on news.ycombinator.com