• ### Announcements

#### Archived

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

# encap/OO use question

## Recommended Posts

First off, don''t misunderstand me, I use C++ and OOP. My pet peeve is, and I''m sorry I don''t remember who said it cause it was on a forum here, it has become ''over-engineered'', too many terms, was made more difficult than necessary. In that vein, how odd it is that you can encapsulate data by using different namespaces and files in C, while even with OO the coding practice is still to use many .cpp files, really what''s the point of double encapsulation or that C++ while being a superset as far as I know still uses the old C standard or that, again, as far as I know all class data is stored on the heap just as is all global data. Finally, the real problem is the OO programmers who are snotty for all the wrong reasons. I''ve read enough flame wars to understand that both sides have strong proponents. Fine, let them, but just understand that C as I see it is procedural, it is not like some old version of basic that was interpreted and had GOTO statements everywhere that wound up being spaghetti code if you tried to write a large program. OO is like an extension of procedural. You could say that procedural programming encapsulates code the way OO encapsulates data, it''s much easier to manage what time something is used. It''s kind of poetic I think. Back to the subject of the post... I always thought encapsulation and OO were good for team projects and if a programmer released source or a library, but from what I''ve read recently in the forums is that this is also used on your own code to prevent access that should not occur(and get rid of globals). Is this true? I first learned a little basic, got introduced to asm, and started C. I have since finished C++ and the magic of OO. (So I am familiar with both styles.) Now, when I first saw that I no longer had to pay attention to formatting my printf''s and could just use cout, I thought to myself, "It''s about time they created a language for lazy people cause let''s face it, we programmers are by default lazy." If all these design considerations are to be used this way it seems that C++ was developed for both stupid and lazy people. Even if I don''t shield my attributes, how could I possibly be stupid enough to allow say, my graphics code to corrupt some ai data. So was C++ designed for stupid lazy people?

##### Share on other sites
Promag    132
Thats a big post!!

Anyway, c++ isnt for dummies... Its stupid to think like that.
Whats the idea, ie, for writing allways that stupid formatting string in printf? boring...

We, programmers, need to avoid writing repeated code and also need simplest and readeable code.

In these days, processors are very fast and they can execute milions instructions per second, and because of that we can write code in a much higher layer.

This doesn''t make us stupid and lazy!!

Supose this:

C:
struct vector
{
... data
};
vector soma(vector a, vector b);

vector a = {10,0,3}, b;
vector c = soma(a,b);

C++:
class vector
{
... operators etc
};

vector a(10,0,3), b;
vector c = a + b;

witch code is more elegant? and more simple?

BTW, if you think so, then write your code in asm...

PROgrammer

##### Share on other sites
SabreMan    504
Yawn! This is a rather lame attempt at trolling. You''ll have to try harder next time...

##### Share on other sites
Cyberdrek    100
quote:
So was C++ designed for stupid lazy people?

The fact is, the tools are made that way, to use them or not is your choice, if you feel that it is stupid, then don't use them...

Not all basic code is speghetti code. I remember when I wrote my game in Quick Basic Xtended, there weren't any goto, gosub of any type for that matter. It was stricly functional code.

You say you learned ASM, well then why don't you write your code in ASM?

One last thing, a bit more respect for fellow programmers would be a good thing. Before calling others stupid, why don't you look at yourself and see who's the stupid one....

"And that's the bottom line cause I said so!"

Cyberdrek
cyberdrek@gdnmail.net
Founder Laval Linux

/(bb|[^b]{2})/ that is the Question -- ThinkGeek.com
Hash Bang Slash bin Slash Bash -- #!/bin/bash

[edited by - cyberdrek on March 18, 2002 8:52:41 AM]

##### Share on other sites
WildWest    184
quote:
I always thought encapsulation and OO were good for team
projects and if a programmer released source or a library,
but from what I''ve read recently in the forums is that this
is also used on your own code to prevent access that should
not occur(and get rid of globals). Is this true?

Yes, it is!
By hiding methods or variables as private or protected you prevent YOURSELF from calling them directly.

The Wild Wild West - Desperado!

##### Share on other sites
siaspete    208
Must ... resist ... flamebait ... gnah!

##### Share on other sites
Promag    132
Private and protected variables makes your program more stable and secure.

If you want to access them then you might want to make methods like GetVariable() and SetVariable(newvalue) and the last one checks if newvalue is secure and valid.

In c++ you got also virtual methods wich are good for making interfaces and get more flexbility. Static methods and variables are great too.

Supose:

class Logger
{
static std::map files;
...
public:
static void Log(std::string file, std::string text);
};

then anywere in your code you can do
...
...
Logger::Log("main", "any log message");
...
Logger::Log("netclient", "connected");

at the end, the code is very simple, and nobody can mess with the files(map).

The idea here is to make all module. Then anyone can download your Logger class and use it or expand it.

PROgrammer

##### Share on other sites
quote:
So was C++ designed for stupid lazy people?

Maybe smart lazy people. Less work for the same results, and you get the compiler to do some of your error checking!

Lazy is good! :D

(oh yeah, modular code tends to be easier to... well, mod, or something. I dunno)

"Eagles may soar, but weasels don''t get sucked into jet engines."

##### Share on other sites
supergeek2k    122
I used to actually think the same thing. Coming from a C background, reading about C++ when it was first introduced I was like "Well this is for C programmers that make alot of mistakes..."

But it is alot more than that. The OOP paradigm is more than just the black-box theory. It is a mindset of programming practices that allows you to more easily model real world objects with code. When used properly, OOP reduces development time by defining data, behavior, and dependencies for each element of your problem at hand. It provides a more intuitive means of documenting your large projects and a cleaner way of extending functionality into new objects.

Let''s see you emulate complex polymorphism and multiple inheritance in C while maintaining a reasonable level of work efficiency and readability.

Peace,
Geek

##### Share on other sites
I never said the programmers were stupid and lazy,
only that we are by default lazy.

siaspete and Sabreman: so could you give me some pointers?

the Speed Bump: Your answer makes sense, I agree, thanks for the
insight.

##### Share on other sites
Guest Anonymous Poster
OO is better for maintaining things. It is far easier to picture things as objects. As well, once you have created and tested a class, you can reuse it over and over again.

##### Share on other sites
I certainly agree that visualizing the objects helps, but
exactly what prevents me from re-using C functions and data.

##### Share on other sites
Guest Anonymous Poster
nothing

##### Share on other sites
Tron3k    660
Classes and OOP are great! Have you ever seen some programs where everything is organized into classes? You would really think, "That''s some nice code!" When you see a bunch of functions, it''s a lot more difficult to understand what''s going on.

Tron3k

##### Share on other sites
siaspete    208
Yep. The very act of having your program in objects, helps people understand how the objects are to be used together.

##### Share on other sites
SabreMan    504
quote:
siaspete and Sabreman: so could you give me some pointers?

Pointers to what exactly? You seem to be whingeing about C++ and OO, so I guess I could respond to your OP...

First off, don''t misunderstand me, I use C++ and OOP.
My pet peeve is, and I''m sorry I don''t remember who said it
cause it was on a forum here, it has become ''over-engineered'',
too many terms, was made more difficult than necessary.

What has become over-engineered? Do you mean C++ or OOP? In some respects, its true about C++. The main issues revolve around the C compatibility which has resulted in all sorts of silly language issues which we shouldn''t have. Arrays, for instance. However, C compatibility is also the reason that C++ became so popular in the first place. The bigger issue, as I see it, is the awful quality of education for newcomers to C++. There are very few good tutors and very few good books. I''ve seen people recommend Schildt and Liberty books on this site many times, yet those authors are not held in high regard by the C++ community at large.

In that vein, how odd it is that you can
encapsulate data by using different namespaces and files in C,
while even with OO the coding practice is still to use many
.cpp files,

This is a very naive view of what encapsulation means in practice. You are merely talking about physical isolation of code, which is common to many programming languages. Encapsulation is also about insulation from change and locality of concept. Breaking up files does not guarantee either of those. Oh, and C doesn''t have namespaces.

really what''s the point of double encapsulation
or that C++ while being a superset as far as I know still uses
the old C standard or that, again, as far as I know all class
data is stored on the heap just as is all global data.

You''ve made 3 unrelated points in one sentence here. Firstly, what the hell is "double encapsulation"? In fact, what''s your point at all here?

Finally, the real problem is the OO programmers who are snotty
for all the wrong reasons.

Whereas you are being snotty for all the right reasons, presumably?

You could say that procedural
programming encapsulates code the way OO encapsulates data,
it''s much easier to manage what time something is used.

You could say that, but you wouldn''t be terribly accurate. Both procedural and OO incorporate constructs which allows encapsulation of both code and data.

I always thought encapsulation and OO were good for team
projects and if a programmer released source or a library,
but from what I''ve read recently in the forums is that this
is also used on your own code to prevent access that should
not occur(and get rid of globals). Is this true?

Good encapsulation should provide modularity of concept and the side-effect of greater intentionality in client code. A team of any size can benefit from that.

Now, when I first saw that I no longer had to pay attention to
formatting my printf''s and could just use cout, I thought to
myself, "It''s about time they created a language for lazy people
cause let''s face it, we programmers are by default lazy."

You are missing the point. Modern programs are far larger and more complicated than ever before. Modern programmers require the language abstractions to allow them to express these structures in a manageable way. Increased type-safety is one of those features that helps protect a programmer from making all-too-human mistakes. When you write a program larger than a few lines, you might begin to realise.

If all these design considerations are to be used this way it
seems that C++ was developed for both stupid and lazy people.

That''s the most idiotic statement I''ve heard since, ooh... yesterday.

Even if I don''t shield my attributes, how could I possibly be stupid enough to allow say, my graphics code to corrupt some
ai data.

Again, you are being very naive.

So was C++ designed for stupid lazy people?

This is quite obviously outright flamebait. The ignorance and stupidity you''ve demonstrated in your post makes it quite obvious you are unable to sensibly discuss the design criteria of C++, so I suggest you don''t.

##### Share on other sites
SabreMan    504
quote:
Original post by Anonymous Poster
OO is better for maintaining things. It is far easier to picture things as objects.

It''s not necessarily easier to picture things as objects. In some cases, it''s wholly undesirable. This idea that "everyting is an object" is quite ridiculous.

quote:

As well, once you have created and tested a class, you can reuse it over and over again.

This is complete fallacy. It is barely possible to predict future requirements, so it is not really feasible to design for reusability. If you use a class for a second time, you are probably using it for the purpose originally intended. That would constitute use , not reuse . Reuse is one of the items on the OO propaganda list, a bit like "everything is an object", and I find it rather unconvincing. In fact, I''d say that the obsession with "reuse" is one of the factors that causes s/w projects to lose their way.

##### Share on other sites
siaspete    208
I have to agree with SabreMan here. I''ve found that small classes (logging, maths etc) can be reused easily, but larger classes like a renderer tend to get rewritten per project.

##### Share on other sites
SabreMan    504
quote:
Original post by siaspete
I have to agree with SabreMan here. I''ve found that small classes (logging, maths etc) can be reused easily, but larger classes like a renderer tend to get rewritten per project.

My experiences have led me to believe that when classes do get reused, it''s more by accident than anything else. I''ve worked on some very large projects where management have tried to instigate reuse programmes and I''ve never seen it succeed. So, I believe attempting to achieve reuse is folly.

##### Share on other sites
Guest Anonymous Poster
The whole purpose of having a class, is that it describes one object. If it does that correctly, then you won''t have to rewrite it in your next project( hence you can reuse it!). It''s my experience that if you can''t reuse it, then your class is doing more than it should.

##### Share on other sites
Guest Anonymous Poster
quote:
Original post by Anonymous Poster
The whole purpose of having a class, is that it describes one object. If it does that correctly, then you won''t have to rewrite it in your next project( hence you can reuse it!). It''s my experience that if you can''t reuse it, then your class is doing more than it should.

For an example, look at STL classes, or MFC classes, you guys don''t rewrite them over and over again for each project you do.

##### Share on other sites
supergeek2k    122
If you are having problems reusing classes that you create, then either you are writing classes solely for a specific application, which suggests that you are NOT putting much effort into designing for reusability, or you are just designing them poorly.

I have class libraries that I wrote 5 years ago which I am still reusing for different applications. Not EVERY class can be reused of course, but many general purpose utility classes can. Encryption objects, networking objects, math objects, database objects, logging and error handling objects are all easily reusable and will save you an insane amount of time if they are designed for this purpose and you have a high project turnaround. Granted it is a little more difficult to design graphics classes that are reusable, but if you put a little more effort into the big picture, and don''t design for a specific case the first time around, they can be written that way.

One of the encryption classes that I wrote has been used in over 200 applications and considering the complexity of the algorithms has saved on average about 40 man-hours per project over rewriting them. That is a total of 8,000 man-hours. At about $40 per man-hour on average. Thats over$300,000 saved as a result of about an extra 10 man-hours spent designing the module to fit multiple contexts. Fallacy? I don''t think so!

That being said... You have to be wise about what you design for reuse and what you design for specific applications. In a gaming context, if you were going to write some AI code that your unique characters were going to follow in a specific game, and the AI has to be lean and mean, designing for reuse in this case is probably counterproductive. But if you are working for a game company that plans on developing many different 3D games, you certainly would want to design for reusability in the graphics engine. Why would you want to spend 5000 man-hours perfecting a graphics engine for each game that you produce when you can spend 8000 man-hours the first time around for an engine that needs minimal modifications for subsequent games?

No, reusability is not a fallacy and it is a very important aspect of development economics. It is not pertinent to OOD only, but OOD/OOP has more advanced facilities and standards to promote code-reuse. Which is why it is such a popular paradigm in todays world. When it comes down to it, it''s all about the dollars. OOD/OOP saves alot of dollars over procedural programming methodologies. The reason is first of all reusability, second of all is code-to-error ratio which is generally quite a bit lower on AVERAGE (this meaning with your mediocre programmers as well as your elite programmers... obviously there are some procedural programmers that dont make very many errors...) with OOD/OOP projects.

Peace,
Geek

##### Share on other sites
merlin9x9    174
C++ is not an OO language. It''s a multi-paradigm language that supports aspects of the OO paradigm, but it''s not a terribly great example of OO features. But just because one claims to know C++ and classes, that doesn''t necessarily mean that he or she knows a single thing about OO. And, of course, OO can be applied in any structured language (though it helps proportionally if the language has OO features).

Often, with large projects, OO must be combined with other models (such as the Model-View-Controller model) to be effective and not cumbersome.

##### Share on other sites
SabreMan    504
quote:
Original post by supergeek2k
If you are having problems reusing classes that you create, then either you are writing classes solely for a specific application, which suggests that you are NOT putting much effort into designing for reusability, or you are just designing them poorly.

You appear to have been taken by the reuse fallacy! The point I''m making is that you can''t really design for reusability, so you should not put much effort into it. If you design your class to be used in 2 or 3 different applications, then using it in the 2nd and 3rd application does not constitute reuse, as you are putting it to it''s intended use.

quote:

Encryption objects, networking objects, math objects, database objects, logging and error handling objects are all easily reusable

I disagree with the terminology. I suspect they are being used for their originally intended purpose. How is that reuse?

quote:

One of the encryption classes that I wrote has been used in over 200 applications and considering the complexity of the algorithms has saved on average about 40 man-hours per project over rewriting them. That is a total of 8,000 man-hours. At about $40 per man-hour on average. Thats over$300,000 saved as a result of about an extra 10 man-hours spent designing the module to fit multiple contexts. Fallacy? I don''t think so!

So, if you designed it to fit multiple contexts, how is using it in alternative contexts reuse?

quote:

No, reusability is not a fallacy and it is a very important aspect of development economics.

It is a fallacy, and I believe the s/w world is starting to wake up to it. XP, Refactoring, and the principle of minimalism, for instance, recommend that you build what you need for today, and don''t guess what you might need tomorrow. With the correct architecture it should not cost any more to change your s/w as new requirements become apparent. OTOH, guessing what those requirements might be inevitably leads to wasted effort. It''s not that I''m saying reuse doesn''t exist (apologies if I gave that impression), it''s that I don''t believe it''s a worthwhile pursuit.

quote:

OOD/OOP saves alot of dollars over procedural programming methodologies.

Is there any proof of this?

quote:

The reason is first of all reusability, second of all is code-to-error ratio which is generally quite a bit lower on AVERAGE (this meaning with your mediocre programmers as well as your elite programmers... obviously there are some procedural programmers that dont make very many errors...) with OOD/OOP projects.

Or this?

Overall, I believe reuse is one of those terms used by management, and it has never really been thought out very well. It sounds good in books and technology brochures; people start using the term without thinking what it means, and they believe they are achieving reuse through some twisted meaning of the word. It''s all part of Money-Oriented Programming.

##### Share on other sites
SabreMan    504
quote:
Original post by Anonymous Poster
The whole purpose of having a class, is that it describes one object. If it does that correctly, then you won''t have to rewrite it in your next project( hence you can reuse it!). It''s my experience that if you can''t reuse it, then your class is doing more than it should.

I''m intrigued with this "if it does that correctly" assertion. I''ve heard it said lots of times, and I find it naive. It''s precisely the principle which I disagree with, since the notion of "correctness" changes depending on the context in which the class is being used. You can''t possibly predict what requirements a future user of your class may have, so it is best not to try and incorporate them on a "best guess" basis.

quote:
Original post by Anonymous Poster
For an example, look at STL classes, or MFC classes, you guys don''t rewrite them over and over again for each project you do.

Well, some people do! Anyway, the point here is that using, say, a vector to store a dynamic array of int''s is using vector for the intended use. I also don''t think the STL is a good example, since the people that worked on it, and the time and effort put into it, are not representative of a regular programming team.