How do you design object oriented projects? [close

Question

I'm working on a large project (for me) which will have many classes and will need to be extensible, but I'm not sure how to plan out my program and how the classes need to interact.

I took an OOD course a few semesters back and learned a lot from it; like writing UML, and translating requirements documents into objects and classes. We learned sequence diagrams too but somehow I missed the lecture or something, they didn't really stick with me.

With previous projects I've tried using methods I learned from the course but usually end up with code that as soon as I can say "yeah that looks something like what I had in mind" i have no desire to dig through the muck to add new features.

I've got a copy of Steve McConnell's Code Complete which I continually hear is amazing, here and elsewhere. I read the chapter on design and didn't seem to come out with the information I'm looking for. I know he says that it's not a cut and dried process, that it's mostly based on heuristics, but I can't seem to take all his information and apply it to my projects.

So what are things you do during the high level design phase (before you begin programming) to determine what are the classes you need (especially ones not based on any 'real world objects') and how will they interact with each other?

Specifically I'm interested in what are the methods you use? What is the process you follow that usually yeilds a good, clean design that will closely represent the final product?

Answer 1

I would recommend to you to use BlueJ and also ActiveWriter to learn and also to develop a good understanding on objects. The book recommended is also a nice resource.

From Wikipedia:

BlueJ is an Integrated Development Environment for the Java programming language, developed mainly for educational purposes, but also suitable for small-scale software development.

Additionally it uses UML and for me it was a good resource to comprehend several things about modeling objects.

alt text http://www.ryanknu.com/ryan/bluej.png

ActiveWriter is a tool to model entities and relations, it also generates code and is easy to make changes. It will save you time and for agile development is very suitable.

alt text http://altinoren.com/activewriter/Images/Introduction_1.png

Answer 2

You asked question that lots of authors use to write a book. There is number of methodologies and you should pick one that seems "prettiest" to you.
I can recommend book "Domain Driven Design" by Eric Evans. Also, check site ffffdcommunity.org.

Answer 3

I think the answer here should be very different depending on the real world experience of the guy asking.

If you have just one or two years work experience then you must go to the point that is: how do you get to the point you really know your data and understand exactly what you're trying to do?

Yeah, if you have been working in the real world 5+ years then you would choose between any of the many software development processes models or techniques.

But you don't get experience by reading books only. You should learn by working in a good group under a good leadership.

If that's not possible then you should just do by yourself. Begin iterating by coding a probably very nasty piece of code, learning your errors, dumping it all, coding a better one and so on.

You'll learn a lot about your codebase. The tools are tools, they will teach you nothing.

Answer 4

If you have domain expertise on the project you are going to work on like say banking. It's easy to structure your objects and you know how those enhancements come every other day.

If you don't have that expertise work with someone who has that expertise and convert those ideas into technical details.

If you are confused about how to structure your project design. BLINDLY follow "pragmatic programmer" book. I was in same situation before, try reading a chapter from that book. you will see the difference, It will change the way you think as a software developer.

Answer 5

Just quoting http://www.fysh.org/~katie/computing/methodologies.txt

And at the core of RUP is a small area where you have to use OO design talents.... if you don't have them, it's like having a methodology for running the 100m.

"Step 1: write about running really fast. Step 2: Go and draw a plan of the racetrack. Step 3: go and buy really tight lycra shorts. Step 4: run really, really, really fast. Step 5: cross line first"

It's that step 4 that's the tough one. But if you put lots of emphasis on 1,2,3 and 5 it's possible no-one will notice and then you could probably make a lot of money selling the methodology to would be athletes who think there's some "secret" to being a 100m runner over

Answer 6

I am afraid that this is not an answer people like to hear. Anyway, let me state my opinion.

OOP should be viewed as one of the paradigms, not as the superior paradigm. OOP is good for solving certain kind of problems, like developing a GUI library. It also fits into the style of software development usually followed by large software companies - an elite team of designers or architects lays down the software design in UML diagrams or some other similar medium and a less enlightened team of developers translate that design into source code. OOP offer little benefit if you are working alone or with a small team of highly talented programmers. Then, it is better to use a language that supports multiple paradigms and will help you to come up with a prototype fast. Python, Ruby, Lisp/Scheme etc are good choices. The prototype is your design. Then you improve on that. Use the paradigm that is best to solve the problem at hand. If needed, optimize hot spots with extensions written in C or some other systems language. By using one of these languages, you also get extensibility for free, not just at the programmer level but also at the user level. Languages like Lisp can dynamically generate and execute code, which means your users can extend the application by writing small code snippets, in the language that the software itself is coded! Or if you choose to write the program in C or C++, consider embedding an interpreter for a small language like Lua. Expose functionalities as plugins written in that language.

I think that, most of the time OOP and OOD create software that are victims of over design.

To summarize, my preferred way to write software is:

1. Use a dynamic language.
2. Write the design (prototype) in that language itself.
3. If necessary, optimize certain areas using C/C++.
4. Provide extensibility by way of the interpreter of the implementation language itself.

The last feature enables the software to easily adapt to specific user (including myself!) requirements.