Are there any good resources on real world practical uses of programming theory?

Can anyone recommend any good material that seeks to provide a real world perspective on programming theories? I'm speaking from my perspective as a long time professional software engineer slash ex-cs student. When I say real world, I mean stuff like "Why should I use interfaces? Doesn't that go against DRY principles? It just seems like extra needless meta code." (which was the implication of another question that came up today.) It seems that the professor of this student's class hadn't given the obvious business reason for using them as "You use this so the main part of your application isn't dependent upon a specific implementation one or more of your components - for instance, a data store which may be replaced or upgraded without affecting the rest of your application or a plugin to an external device which may be replaced when a better one comes along."

I've noticed a tendency for students to reach key points of their CS courses and start asking questions on various Q&A sites about why they should use a certain paradigm, they understand the what and the how, but they're clueless as to why it's actually useful and go through the rest of their course thinking "okay, so what?" All too often class开发者_StackOverflow中文版es are very academic and don't have any real world context. Having been there myself, I wish I'd had a resource like StackOverflow when I was at school.

I'm hoping that this question will provide students with a list of useful reading material that will help provide real world context to various programming paradigms and patterns they're learning in class [or otherwise] and helps them to grasp when and why certain patterns should be looked to in real world situations.

http://www.cs.bell-labs.com/cm/cs/pearls/

The Pragmatic Programmers are, well, pragmatic, but they are well versed in CS theory and they know when and how to apply it.

OK speaking of myself as a CS student :)

I find Stroustrup's papers very enjoying and practical without going into useless details. Take for example his paper about Object Oriented Programming, one of the best readings I've ever read. It goes from the most basic idea of programming, to modular programming passing through the idea of OOP. He shows, why do we need those programming paradigms in short-snippet examples. These are the paradigms he goes through sequentially:

• Procedural Programming Data Hiding
• Data Abstraction ObjectOriented
• Programming (Most of the paper is about OOP)
• Parameterized Types

Another fantastic reading is Sixteen Ways to Stack a Cat. A 16 different way to write a stack in C++(the language doesn't matter actually). Take those, and compare the advantages/disadvantages of most of the paradigms I know/heard of.

Unfortunately, inexperienced programmers often don't realise they have a problem until they run in to it for themselves. I think the best way to see problems in the real world is for students to have 'real world' problems which are probably best found outside of a classroom thats teaching CS principals. (I guess SoftEng would be taught a little differently in this regard)

Code Complete + Head First Design Patterns are the two books I'd recommend every undergrad read before graduating.

Oh, and they should have at least one finished (or mostly finished) extra-cirricular project. A website, game, utility-app whatever.

Code Complete. http://cc2e.com/

One of the most popular questions on this site is, What is the single most influential book every programmer should read?

I'll get the ball rolling with:

• Design patterns, by "the four wise men".
• Code Complete, does a good job of making the problems real.

Generally, these patterns developed because of problems of maintaining and developing large code. Programmers are always strapped for time, and none of them decided that we needed more fluff. Most programmers won't work on the same code throughout the software life-cycle, so there needs to a way for programmers to understand each other's code without having to read a couple million lines of code.

The real world building analogy: You do not make a building without joints. Otherwise it cracks and breaks as it heaves with cold/heat. Interfaces are your joints between two possibly rigid entities.
You make it modular so renovation is possible. You don't make it all of the same material. (plumbing is not made out of wood) You design it so that multiple contractors can work on the building at the same time. The person who uses the building just wants to use it and doesn't care about how you built it. The person(s) who inspect the building are the same people who build the building.

Uncle Bob's The Apprentice series on software craftsmanship. Has a nice narrative style in which I think students can relate to the protaganist, as he/she starts from a lowly apprentice.