What book/resource would you recommend for learning non-OOP design?

Question

I realized that OOP is the only area where I can produce results I'm satisfied with. To be more specific - mainstream static-typed OOP like C++,C# or Java. May be it is so because I've read enough books and articles on it and because most of my programming experience is in OOP. And may be because OOP is just really good :)

Each time I have to do something complex in not-so-OOP language, I feel like I've lost a hand. May be it is so because my tasks naturally require OOP. But I can assume that I'm such a numb guy who knows only one way to do things. Usually it is easy for me to find OOP solution for a problem, and I tend to think these solutions are good enough, but lately I've been reading some articles and discussion on this topic 1 2 3 and now I'm thinking how natural those solutions are.

Last time I had to build rather complex system in javascript I was feeling rather frustrated before I found joose which gave me my old OOP confidence again. Simulating OOP in other languages may work for a while, but I'd like to know more different ways to do things.

So what would you recommend for learning non-OOP design skills? What kinds of tasks have natural non-OOP solutions?

Answer 1

The Art of Unix Programming might help.

NOTE: Despite the title its content could be useful for programmer on any OS.

Answer 2

I'd say learn F# it's a functional/imperative/object oriented programming language for the .NET, it might just help you understand how to work without Object orientation everywhere.

Hope this helped.

Answer 3

I have to say that Concepts, Techniques, and Models of Computer Programming is an excellent book for people interested in learning differents paradigms. It's based on Oz, a multi-paradigm language, but most of the concepts are easily adaptable to the other languages.

Answer 4

It's hard to know exactly what you're looking for because object-orientation is just one of many programming paradigms, and there are many others you might want to explore.

But if you want to try something completely different, then a pure functional language like Haskell will force you to think about things in a totally different way, because it has no imperative or object-oriented constructs to fall back on. I'd highly recommend having a look at the (very well written) free online book Real World Haskell which takes you from the basics onto some fairly advanced topics in a progressive way. It also includes (as the title suggests) some real-world scenarios for pure functional languages.

Answer 5

Pure algorithms tend to be less OO and more procedural in my experience. If you use a language which lends itself to structs you can often write much more elegant algorithm code procedurally.

I think the factory pattern owes quite a lot to procedural coding as does the use of static classes. I have found that a balance between the two often works quite well.

It is certainly worth a careful thought about your problem before you decide to go OO. I learnt programming in the days before OO, it was all 'C' in those days. Maybe that's a good place to start; go and pick up a book on 'C'.

HTH

Answer 6

"What kinds of tasks have natural non-OOP solutions?"

Ummm.... None. There are no "naturally" non-OOP problems any more than there are "naturally" OOP problems.

For my first 20 years in this business, I created non-OO solutions because... well... the OO stuff wasn't mainstream enough for me to get at it.

For the last 10 years, I've been creating OO solutions because it's easier.

Programming is hard. It's a knowledge capture exercise. You're encoding knowledge in a programming language. The presence of OO languages, non-OO languages, functional languages, procedural languages, declarative languages says that no single language is ideal across all problem domains.

Sometimes you find yourself doing something complex in a not-so-OOP language and it's hard. Perhaps because non-OO languages actually are harder to work with. OO is just common sense encapsulated.

If you read enough non-OO code, you can learn enough non-OO design patterns that will allow you to work around the limitations of non-OO languages. Most good non-OO designers tend to use a lot of OO features but they're forced implement them in a non-OO language. And some of them gripe that they're not doing OO. Actually, they are, they just aren't using an OO language to implement their OO design.

Folks gripe about OO. Here's the standard litany.

1. It didn't/doesn't deliver on the "promise". Often they cite reuse as the promise of OO. The issue is that "reuse" isn't clearly-enough defined. Inheritance is the primary method of reuse in OO programming. Write it once and all subclasses reuse it. Other reuse may or may not happen and OO has little to do with that.

2. They have an example of egregiously bad OO design. Yep. And there are egregiously bad non-OO designs, too. Bummer on the "some people can't code" thing. I'm not sure I'd indict the approach because of someone abusing it.

3. They cite historical precedent: "Lots of good code was once written without OO". Yep. Lots of good code was written prior to compiled languages. Indeed, lots of good code was toggled in on the front panels of computers that didn't boot from disk drives. And, lots of good mathematical procedures were done with slide rules. And lots of good stuff was done with paper and pencil.

4. They find flaws in the single-inheritance model of Java. Yep. The real world seems to be multidimensional. Which means we either need multiple inheritance, or we need slightly smarter design patterns (like Strategy or Composite) to cope with the complexity of the real world.

5. They find examples of OO practice in a non-OO context and say "see, OO didn't help here." For example, the C libraries often encapsulate opaque data structures behind a well-designed set of method functions, very much like C++, but without the formalisms. This isn't an indictment of OO -- indeed, the encapsulation and library structure is OO, it just happens to be done "the hard way" without inheritance or language support. That doesn't detract from OO, it only says that there are multiple ways to implement an OO design, including non-OO programming languages.

6. They deprecate OO languages as syntactic sugar. This is point 2 -- you can find shoddy OO design. You also find shoddy non-OO design. Any tool can be abused. Abuse isn't inherent in OO.

Some folks claim OOP is all fluff without substance. Then, they design a clever library of related functions that encapsulate a data structure and use function pointers to allow someone else to extend the library by adding new features. OO done the hard way, gotta love folks who like to make a hard job harder.

Answer 7

I suggest checking out books about functional programming languages. Maybe it's worth having a look at Prolog also.

One "classic" I'd like to name is "Structure and Interpretation of computer programs" from Abelson, Sussmann. I found the books "Exploring computer science with Scheme well written and interesting.

Regards Friedrich

Answer 8

Code Complete by Steve McConnell

Programming Pearls

Answer 9

You should read about generic programming (aka "stuff with templates"). It is non-OO in the sense that it doesn't enforce any hierarchy of objects, in fact it doesn't require the concept of an object.

Functional programming, I believe, is something which can live on top of OO, not something you'd use instead of OO.

Answer 10

I'm sorry for digging out this question, but you might want to read Chapter 6 ("A Programming Episode") from "Agile Principles, Patterns, and Practices in C#" by Martin C. Robert and Martin Micah. It show an example in which the solution is not quite object oriented (although it's written in C#). The analysis and design process is done using TDD. Here is an excerpt from the conclusion:

After writing this chapter, I published it on the Object Mentor Web site. Many people read it and gave their comments. Some folks were disturbed that there was almost no object-oriented design involved. I find this response interesting. Must we have object-oriented design in every application and every program? In this case, the program simply didn't need much of it. The Scorer class was really the only concession to OO, and even that was more simple partitioning than true OOD.

The online version is here.