Archived

This topic is now archived and is closed to further replies.

Craving for OO knowledge

This topic is 5381 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there, I have a favor ask from the ppl who are really into C++. I have a problem. I don''t know how to structure a program. All I know about programming I taught me myself and to get to the point, I have the confidence to practically do everything that I can imagine if I get myself into it and given a certain amount of time BUT, I fail at structuring my ideas into a good design. The OO view easily lets me create my classes I need, their hierarchy and their interfaces. But compile time design doesn''t have anything in common with runtime design. To specifiy my problems more clearer I''ll give you some thoughts: 1. When will objects be created ? (When is it fitting, stack ?) 2. By whom ? (objects and especially threads) 3. Who takes care of them ? (Getting rid of them and such) All of these very abstract question can be answered quite easily with ''The way I want it''. Yes, my program will of course work but I never have the feeling that I did a good job. Maybe because it is total crap or just that I don''t have any reassurance of what I''m doing. It''s killing me. Do you have any advice for me like a page that explaines patterns like MVC and such or any other hint, for example joining some project ? Any comment would be appreciated big time( even if you want me to go to a psycho doc ) Lorenz

Share this post


Link to post
Share on other sites
quote:
Original post by sprinter_trueno
All of these very abstract question can be answered quite easily with 'The way I want it'. Yes, my program will of course work but I never have the feeling that I did a good job. Maybe because it is total crap or just that I don't have any reassurance of what I'm doing. It's killing me.


Most software stinks!

[edit]
To answer your question, maybe this online book helps a little:
Bringing Design to Software
[/edit]


[edited by - darookie on March 5, 2003 7:10:36 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by sprinter_trueno
I have a favor ask from the ppl who are really into C++. I have a problem. I don''t know how to structure a program.


I am following three principles:

1. Start small
2. Move in small steps
3. Keep it simple

As a result, I start with code that already is structured, (anyone can structure 100 lines of code). And as I keep adding code, I only have to ensure that I don''t ruin the current structure, which also is simple, since I add only small amounts of code. When things start look really ugly, I stop coding and do a little cleanup.

Share this post


Link to post
Share on other sites
Thanks for the advice but that is actually the path I do not want to walk anymore.

See, if I do some coding even if it is in small steps i end up mopping the floor with what i''ve written. If I want to write an algorithm for whatever I totally agree with you. I''m not that kind of person that sits down over a math book and works out every detail. Won''t work in the beginning but a little bit of ''cleaning up'' will do the job after a while. Fine.

But now imagine just a small program (GUI, File I/O, some algorithms) and you start to have 15 or 20 classes, a little
''CleanUp'' now and then will lead to compromises and each compromise you accept will make you accept another one later on.
Until you get so stuck with recoding the damned thing 24/7.

Don''t get me wrong, coding in small steps is a must for everybody but coding without a design is suicide.
When I started programming i was so fascinated that what i coded really came to life and made me go on learning more. With time you understand how the software works that we use so casually everyday and you start to aim for that. But since this is a little bit more complicated than just hacking in a few lines you wind up having written more than a hundred pages of code and not knowing anymore why it really works. And the ''WHY'' is what I cannot stand anymore. That''s why I liked programming so much in the beginning. I was able to grasp it in whole.

Relying on a design, that I didn''t need back then, would provide me with the understanding I lack so much. Learning how to structure my personal requirements towards the piece of art I wanna create is the only way that I would be able to write good software.

Share this post


Link to post
Share on other sites
quote:
Original post by sprinter_trueno
When I started programming i was so fascinated that what i coded really came to life and made me go on learning more. With time you understand how the software works that we use so casually everyday and you start to aim for that. But since this is a little bit more complicated than just hacking in a few lines you wind up having written more than a hundred pages of code and not knowing anymore why it really works. And the ''WHY'' is what I cannot stand anymore. That''s why I liked programming so much in the beginning. I was able to grasp it in whole.


You are exactly describing my own experience. I also remeber how fascinated I was about my first programs doing trivial things like displaying a single character in the right place or something like that. And then (actually there was a lot of time between) I learned all those modern programming methods, and as a result I also was unable to understand my own code .

Then I thought - WTF, how come everything was so simple back in the good old days, and now everything''s so complex. So I returned to my original coding style with no OOP, no design, no planning, AND EVERYTHING IS SIMPLE AGAIN!!!1!!1!!

Share this post


Link to post
Share on other sites
quote:
Original post by Advanced Bug
And then (actually there was a lot of time between) I learned all those modern programming methods, and as a result I also was unable to understand my own code .


Which implies that you actually didn't 'learn' them
quote:

So I returned to my original coding style with no OOP, no design, no planning, AND EVERYTHING IS SIMPLE AGAIN!!!1!!1!!



At least for you, but remember that this only works if you and
only you write and need to understand the code.
Try to maintain some 5 year old piece of software, that you wrote
this way and never touched since. If you still understand everything (after some hours of looking through it that is),
then this 'non-style' of programming might be alright for you.

Just out of curiosity:
May I ask how big your current project is (e.g. how many lines of code) and how many time you usually spend on it?


[edited by - darookie on March 5, 2003 9:27:22 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by darookie
Just out of curiosity:
May I ask how big your current project is (e.g. how many lines of code) and how many time you usually spend on it?



Current project: 500 lines (I started it in Monday)
Biggest non-OOP project: 6000 lines (fully functional space shooter)
Biggest OOP project: 30000 lines (simple IDE for GCC compiler, most code was OO wrappers for Windows)

On the other hand, there are examples of big programs written in similar style - like DOOM or QUAKE.

Share this post


Link to post
Share on other sites
quote:
Original post by Advanced Bug
On the other hand, there are examples of big programs written in similar style - like DOOM or QUAKE.

Quake is a bad example - it makes use of OOP, it's
just written in C so you won't find the 'class' keyword anywhere
Inheritance and other features are implemented using function pointers and structs, but I agree that these are rather big
pieces of software written in an awful style.
However, those are again written by only one programmer for the most part.

I asked you about the code size, because I started with 'planning', 'designing' and 'OOP' after my first big projects hit an overall size of about 200.000 lines of code
(it was a DOS SciFi tycoon-style game) and I wasn't able to figure out how the damn thing worked after a 'creative pause' of about three months.

Since it ran very unstable and couldn't find out why, I decided
to rewrite it from scratch applying OOD.
I successfully finished it (it ended up being about 300K lines of code (excluding comments!) and worked like charm.
I spend almost three years on it, spending about 10 hours a week
coding on average (so I had to look up my docs every few weeks
when I touched some older parts).

I wouldn't have managed it without switching from my chaotic
'let's try it this way - wow, it works'-style to a more
formal and goal oriented approach, so I was wondering how you
manage to create and maintain large programs whithout any
design...

Cheers,
Pat





[edited by - darookie on March 5, 2003 10:53:01 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by sprinter_trueno
Hi there,

I have a favor ask from the ppl who are really into C++. I have a problem. I don't know how to structure a program. All I know about programming I taught me myself and to get to the point, I have the confidence to practically do everything that I can imagine if I get myself into it and given a certain amount of time BUT, I fail at structuring my ideas into a good design. The OO view easily lets me create my classes I need, their hierarchy and their interfaces. But compile time design doesn't have anything in common with runtime design.

To specifiy my problems more clearer I'll give you some thoughts:

1. When will objects be created ? (When is it fitting, stack ?)
2. By whom ? (objects and especially threads)
3. Who takes care of them ? (Getting rid of them and such)

All of these very abstract question can be answered quite easily with 'The way I want it'. Yes, my program will of course work but I never have the feeling that I did a good job. Maybe because it is total crap or just that I don't have any reassurance of what I'm doing. It's killing me.

Do you have any advice for me like a page that explaines patterns like MVC and such or any other hint, for example joining some project ?

Any comment would be appreciated big time( even if you want me to go to a psycho doc )

Lorenz


I'm all too familiar with that what I call Object-Oriented Paralysis: the sheer number of possibilities afforded by OO overwhelm you. It is also known as Analysis Paralysis.

Here's part of your problem. The OO gods, as brilliant as they are, do not help things when they say "OO is hard." It makes relative newbies like us think we cannot *possibly* design good software in our infancy and makes us doubt our own designs.

OO is just a methodology, and there are going to be extremists, so you have to take some advice with a grain of salt. The language you use imposes a serious restriction - in C++ I'm not sure you can EVER expect to get a 100% elegant design out of solutions.

Another note: patterns are great but cannot substitute for a coherent design, they're meant to be used within it. That being said there are supposedly only a few 'application' patterns used nowadays.

Look up Extreme Programming and look at some of those principles. The core value of XP is "courage," which is very important for people just starting out. It is only through experience that you can be a better designer. XP recognizes that it is VERY hard to get the design exactly right the first time and that you will refine it as you go. This is normal. One good site is at www.xprogramming.com . XP also encourages constant refinement and experimentation. Read their "Adventures in C#" series to see how it works. In that series the authors did not even know how to use C# and now have a cool XML Notepad application.

[edited by - antareus on March 5, 2003 12:27:48 PM]

Share this post


Link to post
Share on other sites
quote:

It is also known as Analysis Paralysis.



Wow ! There is even a word for it . It really hits the spot.

Thanks alot for the advice (to all people who commented). I will look up everything and try to keep on going.

C ya

Share this post


Link to post
Share on other sites
I also experienced analysis paralysis Basically, it''s a mental juggling of all possible cases and what effects are caused to the design when you change something. The reason this doesn''t work is because it breaks the fundamental human concept of learning from your mistakes. You''re basically trying to create a perfect system the first time out which is impossible for us humans. You learn by dealing with problems as they come up. I have a large program and there is a lot of interaction in it, trying to write this down on a blackboard is completely nuts. You would need several miles of blackboard and a chalk the size of eifel tower.

What you can do however is describe concepts that you can then make objects from. However, due to the nature of our windowing apis and other ones as well they will restrain you in unexpected ways. This won''t be evident to you at design stage because you lack the api specifics. Even worse, the api changes under your feet invalidating your original design. Completely outside your control in today''s age unless you make everything yourself.

So what you do is describe the few important objects you need and hope that the rest will be discovered at later time when your initial codebase is complete. That is why you need a code design that can grow with you and can adapt w/o you having to recode stuff all the time. Hierarchial design is not good for this because it needs to be well defined upstairs and like I''ve said you won''t discover all your concepts ahead of time and most likely you''ll change your mind along the way thru the years that you''re coding it. Major changes like xforming your first person shooter engine into a vastly outdoors terrain role playing engine and such things. Our taste changes with time because we''re growing mentally.

Share this post


Link to post
Share on other sites
Object-Oriented Design Heuristics by Arthur J. Riel is an excellent book that really help me with some of the issues you are grappling with. I highly reccomend this book.

"Discipline is never an end itself, only a means to an end." - Robert Fripp

Share this post


Link to post
Share on other sites
quote:
Original post by Magmai Kai Holmlor
I think the more general term is "analysis paralysis", which applies to other fields of engineering as well.


The nice thing in physical fields of engineering is that we run several different analysis proceedures, get a spread of results that includes just about everything under the sun and end up relying on a calc done on the back of an envelope based on intuition and done whilst standing in the middle of a rainy field! (in my experience anyway)

Share this post


Link to post
Share on other sites
quote:
Original post by sprinter_trueno
To specifiy my problems more clearer I'll give you some thoughts:
1. When will objects be created ? (When is it fitting, stack ?)
2. By whom ? (objects and especially threads)
3. Who takes care of them ? (Getting rid of them and such)
All of these very abstract question can be answered quite easily with 'The way I want it'. Yes, my program will of course work but I never have the feeling that I did a good job. Maybe because it is total crap or just that I don't have any reassurance of what I'm doing. It's killing me.


One thing you'll begin to notice while doing OOP is that it is an iterative process. You're not going to come up with the BEST design the first time around (unless you're super cool). What you need to strive to do (and I'll agree, it's tough to tell if you're doing it right) is make is so that the changes you do make don't reverberate through the rest of the code.
I'll start by addressing your questions first.

1.) What I like to do is create the objects themselves on the "stack", but allow them to use an alloc() method that creates all of their memory on the heap (using "new"). How would you go about this? The following is the abstract class that just about every object I create derives from:

class CBaseObject
{
public:
CBaseObject(){}
virtual ~CBaseObject(){}

virtual bool Init() = 0;
virtual bool Alloc() = 0;
virtual bool Destroy() = 0;
};
This allows me to follow some rules for how I'm going to do my work. Init() initializes my object (so I can re-use the stack based data), Alloc() allocates any memory I need to use (beyond basic data-types), and Destroy() de-allocates all that memory.

This is by no means the "right" answer, just how I tend to do things, and have been very happy with it. I also place calls to Init() and Destroy() in my constructors and destructors.

2.) If you are creating data to be accessed by multiple threads, just make sure you have some sort of locking mechanism built in. Generally, if I'm making a new thread, I try to have that thread started from the thread that "owns" it. Some people will have all threads spawned at the base application level, and although that works, I think it is less intuitive.

3.) Assume that you must take care of everything. If you only need a variable for 5 lines of code, and especially if it uses a lot of memory, scope it so that it's only around while you need it.

As for "writing crap", the fact that you're worried about design places you in a "better" category, at least you care. Sit down and draw some pictures before you start coding. Well designed code can feel/look like artwork, because of how well it can work. Try to map out where things get used, how you intend to use them, where things overlap, etc. Try to find out early on how flexible you want something to be...the more you can plan for ahead of time, the better you'll be.

Another hint that I'd give is that coding style and methods are important too. So many "samples" out there have classes/implementations spread all over the place. Unless the classes are very similar, or utility classes, just have one class per header and implementation file. Try to choose a coding style, and stick to it.

Honestly though, you'll never feel like you've got the "best" solution, because really, you probably don't. I bet you've got a good one though...
Good luck.

- sighuh?

[edited by - redragon on March 17, 2003 3:20:02 PM]

[edited by - redragon on March 17, 2003 3:20:26 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by redragon
I also place calls to Init() and Destroy() in my constructors and destructors.

You are calling virtual methods from ctors and dtors?




"If there is a God, he is a malign thug."
-- Mark Twain

Share this post


Link to post
Share on other sites
quote:
Original post by Arild Fines
You are calling virtual methods from ctors and dtors?


I only call them in the classes that implement them...can't do it in the base level, as they may not be implemented.

- sighuh?

[edited by - redragon on March 17, 2003 10:43:13 PM]

Share this post


Link to post
Share on other sites
quote:

1. When will objects be created ? (When is it fitting, stack ?)
2. By whom ? (objects and especially threads)
3. Who takes care of them ? (Getting rid of them and such)


I suggest the book "Applying UML and Patterns, An Introduction to Object-Oriented Analysis and Design" from Craig Larman. It will help you make a good OO design. Try looking for the GRASP patterns on the web. GRASP stands for Genernal Responsibility Assignment Software Patterns. These patterns will help you assign responsibilities to your classes. It will help you in your design.

[edited by - kelendil on March 20, 2003 11:20:37 PM]

Share this post


Link to post
Share on other sites