What is a good standard exercise to learn the OO features of a language? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. 开发者_开发技巧 Closed 10 years ago.

When I'm learning a new language, I often program some mathematical functions to get used to the control flow syntax. After that, I like to implement some sorting algorithms to get used to the array/list constructs.

But I don't have a standard exercise for exploring the languages OO features. Does anyone have a stock exercise for this?

A good answer would naturally lend to inheritance, polymorphism, etc., for a programmer already comfortable with these concepts. An ideal answer would be one that could be communicated in a few words, without ambiguity, in the way that "implement mergesort" is completely unambiguous. (As an example, answering "design a game" is so vague as to be useless.)

Any ideas?

EDIT: I have to remark that the results here are somewhat ironic. 10 upvotes and (originally) 5 favorites suggest that this is a question others are interested in. Yet the most upvoted answer is one that says there is no good answer. Oh well. I think I'll look at the textbook below, I've found games useful in the past for OO.

---

I can't imagine there could be a standard set of exercises that would naturally introduce OO features of a programming language to everybody. A lot of the introductory OO tutorials are full of Animals, Cats, and Dogs which does not really cut it for me at least. Find a problem domain in OO you've struggled with a lot, and try to use that as your set of stock exercises for each language you pick up.

The OO constructs that we are used to thinking in terms of may not make sense in a language. Javascript comes to mind which shakes the entire foundation of how we think about objects in general. That said, you shouldn't adapt to a language but rather adapt the language for your purposes. Over time as your knowledge repository grows and improves with experience, you'll naturally want to implement what you think is best in each programming language that you use regardless of what the language offers.

---

Good question... In my opinion the best teacher is just find a simple example of OO features and try to write something alone, creating new examples for Yourself and trying develop simple application in which You can connect all features of OO .

Implementing algorithm like merge sort which don't use OO feature, cause they don't need it is useless. Try real useful programs.

I remember when learning OO i write application with general "Animal" interface with methods and class which inherit it, like "amphibian". it was fanny time ;)

---

Some fun: implement the Shape/Circle/Ellipse hierarchy without falling into the trap (it can be done very nicely in Java, Scala, etc.).

edit implement it before looking at the proposed solutions in the Wikipedia article :)

---

I've used Hunt The Wumpus. The original implementation in BASIC was not at all OO, but if you start fresh it lends itself pretty nicely to this.

---

Here's what I use:

http://homepage.mac.com/s_lott/books/oodesign.html

I've done it enough times that it's "standard" in my opinion.

---

This might be too specific, but it's what I credit for really getting me to understand OOP personally. For my work I had to write code to extract data from a large variety of different sources. It seemed straightforward to me at the time that I should tackle the problem from the perspective of designing various "DataProvider" classes. What only gradually became clear was how much code I could reuse by breaking the different kinds of providers down into hierarchical categories, like this:

• DataProvider
  • TextDataProvider
    • HtmlDataProvider
    • CsvDataProvider
    • XmlDataProvider
  • BinaryDataProvider

...and so on. I would suggest that any problem like this--where you need to accomplish a certain kind of task (in my case, extracting data) in a bunch of different ways (e.g., from multiple sources)--will be a great opportunity to delve into OOP and hopefully learn to appreciate how useful it is.

---

I personally find the best way to learn OO, is to write your own testing framework.

I find a layout of a Test Runner, owning one or more Test Suites, which each have their own Test Cases enough of a starting point, but you can easily grow it from there, and it might even be something you care to use in the future.

Alternatively, if you want something completely throw away, there's always Enterprise FizzBuzz. :)