Object Oriented Design

[abcdefghijklmnopqrstuvwxy]

Hi, I'm self taught and I want to learn how to design with UML. I picked up a proggy called Dia and I've been playing around with it. I'm curious if anyone knows a great way to learn OOD + UML. It doesn't have to be with Dia but I'd like some tutorials to be based on a modeler program of some sort. Thanks.

[wtd]

UML is not necessary for learning how to write object-oriented code. Many, in fact, find it to be an impediment.

Just write code. That is the only way you'll figure it out.

[abcdefghijklmnopqrstuvwxy]

I don't think that is good advice to be giving wtd. UML can be very helpful which is why it is used in industry. Most self-taught people wouldn't bother learning UML and practicing designing before writing code, but in my opinion that is because they lack discipline. In all aspects of life it is good to plan ahead. UML has the advantage of being able to plan ahead in a manner other programmers can understand as well.

[ericfourfour]

You just asked how to use UML with OO and now you are acting like an expert. Why did you ask the question if you already knew what you were doing?

[haskell]

Actually, programming is not meant to be 100% planned out ahead of time. There should be a general idea of the objective, and of different paths to get there, but developing is a dynamic process. It is a living, breathing entity.

UML should be seen as it was meant to be; a tool. Not all tools are good for everything, even in the field they were designed for.

I would never recommend using UML for everything. It means that you havethe problem figured out in a theoretical state of mind, not the practical state of mind.

To balance out these two states, people design as they go. UML is great for designing as you go, though most people prefer the old pencil and paper for planning.

To put it in short, UML is one of those academia tools. Good in theory, but as useless as tits on a bull. A pencil and paper is better than UML will ever be, and design is not static, and cannot be 100% determined at the start.

[abcdefghijklmnopqrstuvwxy]

Those are all valid points haskell, but I knew all of them. I was not asking people's opinion on the usefulness and uses of UML.

Let me ask you this, are you fluent in UML? How many projects have you designed with UML?

Lastly, and I'll say this once and for all, UML can be useful, not to mention it's industry standard.

[wtd]

I think what we're trying to get across is that there are no good tutorials when it comes to designing applications using object-oriented programming and UML.

There cannot be, as UML is not a good way to go about creating an application.

Oh, and I enjoy being undisciplined. It gives me the freedom to learn the truth, rather than the corporate-sponsored Truth(tm).

[Skynet]

haskell @ Mon Feb 05, 2007 5:48 pm wrote:

I would never recommend using UML for everything. It means that you havethe problem figured out in a theoretical state of mind, not the practical state of mind.

To balance out these two states, people design as they go. UML is great for designing as you go, though most people prefer the old pencil and paper for planning.

Whenever I've seen UML used, it was for establishing an overall design framework, not for "designing as you go." Trying to force people to keep arbitrary flowcharts updated as programs evolve is just needless amounts of red tape, but it's very handy in the initial concepts. You can replace "UML" with "standardized charts" if you like, but the point remains that it's a very good series of symbols for describing a large program to a large amount of stakeholders.

wtd" @ Mon Feb 05, 2007 7:09 pm wrote:

There cannot be, as UML is not a good way to go about creating an application.

I agree with wtd here on the small scale, but disagree strongly on the large scale. The UML diagrams I saw were helping three different departments at the company I worked for at the time work together - Quality Control, IT and Manufacturing Engineering. Quality needed data, Manufacturing provided data, and IT organized and maintained the data. The UML diagrams made it clear what everyone's responsibilities were ahead of time as well as which form the data was to be transferred in. With a dozen people working in different areas, there needed to be some clear way of laying out what we were doing.

In regards to the initial question: When I needed to learn a bit of the symbols, I remember starting from Wikipedia. I can't remember where I went from there. The modelling program I used was Microsoft Visio, which still remains my favorite flowchart program. Yes, it's not free, but that wasn't an issue at work, heh.

[haskell]

I've used UML quite a bit when I was bored I thought that I might as well try it out. StarUML was what I played with. Its not really being fluent, its just organizing your ideas without using paper, and using a standard set of symbols.

That being said, there are many ways people make sure people know what they are doing. UML diagrams are one way to show how everything must mesh together.

The problem is that outside of the skeleton framework and selling your idea, it is kind of impractical. As a tool it has its niche, but that niche is not everywhere.

[wtd]

The problem, succinctly summed up:

The best laid plans...

Grandiose designs are almost universally a waste of time, as very rarely can any team actually stick to the plan without ignoring issues that crop up along the way.

And since this would be an unfair attack without suggesting a practical alternative, I suggest trying to use an approach where you build the language up to meet your problem halfway.

If you find yourself thinking, "this would be a lot easier if we had a generic foo_bar datatype, but alas C++ does not have one in its standard libraries," then simply create that datatype. Or use an implementation language that does have such a datatype already.

In most cases I have encountered, elaborate plans are only made necessary because of deficiencies in the implementation language. Typically the language is not lightweight enough to allow developers to pop out quick prototypes, so there's incredible pressure to get it right the first time, despite that being an utterly unrealistic expectation.

[Skynet]

haskell @ Mon Feb 05, 2007 8:22 pm wrote:

The problem is that outside of the skeleton framework and selling your idea, it is kind of impractical.

Yeah, I think this is the best way to look at it. Like wtd says in the post below yours, planning every data type and method you're going to use is inane. Still, sometimes the "skeleton framework" takes a while to hash out if you're working in a large group, and UML diagrams are a clean way to lay said "grandiose designs" out.

[wtd]

Additionally, it is worth noting that C++ forums are likely a bad place to be discussing "Object-Oriented Design."

Hordes of classes and objects are only one way to write code in C++, and not always the best. Ignoring the diverse nature of C++ in the name of "purity" or some such is ridiculous.

[abcdefghijklmnopqrstuvwxy]

Quote:

In regards to the initial question: When I needed to learn a bit of the symbols, I remember starting from Wikipedia. I can't remember where I went from there. The modelling program I used was Microsoft Visio, which still remains my favorite flowchart program. Yes, it's not free, but that wasn't an issue at work, heh.

I think that's the best I'm going to get here. lol... Thanks.

Quote:

Additionally, it is worth noting that C++ forums are likely a bad place to be discussing "Object-Oriented Design."

Sorry, I didn't realize...

[wtd]

It's just that OOP concepts are kind of awkward to express in C++, and C++ offers a lot of tools other than OOP to solve problems.

[deville75]

I haven't really been paying attention to the conversation, but personally I learned OOP with Java. I know OOP very well now, but it's also mostly due to an amazing teacher. Shout out to Mr. McKenzie!