Limits of virtual attributes

On Thu, 29 Jan 1998 12:17:00 -0800, Stephen McHenry wrote:

>I certainly agree with the last statement about design patterns and

>collaborating classes being necessary. But, that still does not imply the

>need for public/protected attributes or friends. Design patterns and

>collaborating classes can be quite nicely implemented using private

>attributes and the appropriate private/protected/public methods. Early in

>my OO career, I thought this encapsulation stuff was just a lot of

>theoretical stuff put forth by people that didn't build real systems and

>didn't have a clue what life was like "in the real world". Then, I

>experienced my first system built with good encapsulation and lived with it

>long enough to see the effects. Now, i don't ever want to go back.

I haven't being working on OO projects as long as you seem to have

been; my experience is limited to about two years worth of Forte

programming. When I started, I was also skeptical about the real

benefits of encapsulation; it seemed like such a waste to write so many

"get" methods that consisted of little more than "return(self.x)".

Luckily, I was working with someone who had something like 8 years of

OO experience under his belt. I didn't buy all of his arguments at

first, but as time went on, I more and more found myself saying, "Ah,

NOW I see what you're talking about." And, like you, I wouldn't want

to go back. :)

Dale

================================================

Dale V. Georg

Systems Analyst

Indus Consultancy Services

dgeorg@indcon.com

================================================

at 2007-6-29 9:22:00 >

At 03:13 PM 1/27/98 -0800, you wrote:

>I think you have missed the point of the previous message.

Well, I did miss how he was proposing to use the "friend" concept (as

explained in a previous post), so I guess I can't argue that I might have

missed the whole point altogether.

>While public and

>private keywords can enforce encapsulation at a class level, they do nothing

>to help enforce encapsulation at a component level (component being defined

>here as a set of collaborating classes that offer a public interface).

Agreed. They enforce it at a lower level.

>

>I am also saddened when newcomers are brought into the object oriented

>paradigm and told that class level encapsulation is all that you will ever

>need. It is simply not true. Design patterns and collaborating classes are

>needed if you have all but the simplest of applications to build.

Well, here's where I disagree (at least, I think I disagree. I may have

missed the point of this too ;-)

I certainly agree with the last statement about design patterns and

collaborating classes being necessary. But, that still does not imply the

need for public/protected attributes or friends. Design patterns and

collaborating classes can be quite nicely implemented using private

attributes and the appropriate private/protected/public methods. Early in

my OO career, I thought this encapsulation stuff was just a lot of

theoretical stuff put forth by people that didn't build real systems and

didn't have a clue what life was like "in the real world". Then, I

experienced my first system built with good encapsulation and lived with it

long enough to see the effects. Now, i don't ever want to go back.

Unfortunately, in those days, the performance issues hadn't been solved,

even in C++, and processors were slower and more expensive, so we had to

relax it in a number of places purely for performance reasons. However,

after experiencing it, we never relaxed it in a willy nilly fashion. We did

it carefully, and in selected places where performance was demonstrated to

be a problem.

For some reason, the (possibly anecdotal) story of the first non-Native

American to see Yosemite comes to mind. He was a person known to imbibe too

much, on occaision, and he came back into town, after being gone for weeks,

with stories of a valley so incredibly beautiful that it defied

comprehension. Everyone thought that this must have been some hallucination

and couldn't possibly have been true, so it wasn't until a long time later

when others accidentally stumbled on the valley and came back confirming

what he said that people actually began to think there might be something

to his original story.

>The >public/private settings in Forte do not give a developer any way to

define

>the scope of the privacy.

Agreed. That was sort of what I was proposing in another response

(SQLPUBLIC...) because, in the Forte Environment, I think there are certain

situations where this type of privacy scoping is in order. However, the

need to extend that to the "package" level remains, as yet, undemonstrated

to me. Over recent years, I have been presented with a number of designs

which "required" public/protected attributes or friends, or other

variations on visibility. In all cases so far, they turned out to be poorly

thought out designs, which needed rework. Admittedly, in a few cases, the

rework required almost fell into the category of "brain teaser", but once

the solution was developed, it was much clearer and more maintainable.

(These were actually the ones that were the most fun. Unfortunately, I

don't have much time anymore for this kind of "sport".)

>In other languages such as Java the scope of privacy can be controlled

>within in the class (this is Forte's current ability), class hierarchy or

>class package (this is effectively the friend concept). This is glaring

>omission from Forte. Without this control, building collaborating classes

>that work together and offer a consumer of the classes a public method

>interface with only those messages that one can call as public is near

>impossible to construct.

>

>The interesting thing about all of this is that Forte themselves do not

>depend solely on the public/private settings in their own Framework

>projects. They have an ability to hide classes, attributes and methods in

>the repository independently of public and private settings. Yet,

>internally they can still instantiate those classes and call those

>attributes and methods. Most of these classes, attributes and methods can

>be "turned on" (made public) to a developer with Forte logger flags. Surely

>the Forte logger flag is not a mechanism that should enforce object

>encapsulation, yet it does. With this mechanism, Forte can "turn off" (make

>private) classes and interfaces while the hidden classes still know how to

>call other hidden classes, attributes and methods. In essence the Forte

>framework classes are all friends of each other. Is Forte wrong for doing

>this? No.

Well, I don't consider myself to be a judge of right and wrong. They have

definitely created an environment where long-term maintainability has been

compromised. I wasn't involved in the development of the internals, so I

can't comment on the situation/alternatives that contributed to their

decision(s).

>They saw the need to be able to control the scope of their

>class, attribute and method privacy and to be able to programmatically

>change it. Very nice.

Nope. Changing visibility programatically is a hack. It's probably worse

than making everything public because you may operate under the assumption

that there is some form of encapsulation and you are wrong. This causes

bugs because, when changes are made, you have no idea who uses that part of

the system because they can "turn it on", use it, and then "turn it off".

>What they have failed to acknowledge is that many

>projects have the same need to control the scope of this privacy.

There are many projects that think they have this need. With a better

design, they would not have it.

>What I have seen many projects using Forte do is to rely on the honor system

>for privacy. That is, things are considered conceptually private by

>prefixing them with an underscore. This is quite troubling because there is

>no compiler (or runtime for that matter!) enforcement of this conceptual

>privacy.

I am in total agreement with this last statement!!

>Yet the simple public/private model that Forte offers just does

>not allow enough control to always be useful.

As detailed in another response, I *would* make some changes. But, they're

not the ones that most people ask for. I have yet to see a design problem

that cannot be accomodated by those changes, and they don't include

"package" visibility for attributes. (Incidentally, something along the

lines of "package public" for methods is not offensive to me - just for

attributes.)

>Just like in real life, privacy is not an all or nothing switch. Things

>private to me may not be to someone or something else. The relationship of

>two things has a lot to do with the definition of privacy between them.

>Today, Forte makes you define the privacy of something without regard to the

>kinds of classes which may use it.

Some of that relationship has been incorporated into the proposal in the

other post. But for attributes, it's far more limited than most people are

asking for. If you have a design for which the visiblity/performance

proposal detailed there is not adequate (and, I'll throw in "Package

public" for methods), let's see it.

Stephen

at 2007-6-29 9:22:00 >

On Wed, 28 Jan 1998 12:58:11 -0800, Stephen McHenry wrote:

>So, what makes more sense is to directly incorporate these

>notions into TOOL visibility declarations. Essentially, we are creating

>three "classes" (not in the OO sense) of visibility - code, SQL and screen.

>And, these would be independently settable for each attribute.

>Consequently, you could have an attribute that was "CODEPRIVATE, SQLPUBLIC,

>SCREENPRIVATE" that could not be seen by other classes, nor could it be

>mapped to the screen, but it could be referenced in an SQL statement.

>"CODEPRIVATE, SQLPRIVATE, SCREENPUBLIC" would allow the attribute to be

>disaplyed on the screen, but not referenced by other classes or SQL

>statements. Now, personally, I'd eliminate the CODEPUBLIC and CODEPROTECTED

>completely for attributes. (BTW, I couldn't think of a reason to have

>SQLPROTECTED or SCREENPROTECTED that made sense.)

This is an interesting and intriuguing concept. I like it. I suspect,

though, that the problem with actually implementing something like that

in Forte would lie in the fact that TOOL is so heavily based on C++.

Anything Forte implements has to be easily translatable to C++, if for

no other reason than the fact that compiled partitions are made by

translating TOOL to C++ and then compiling the C++. The farther TOOL

strays from the basic concepts of C++, the harder that translation

becomes. I suspect that this explains many of the limitations of

virtual attributes. Because virtual attributes do not exist in C++,

Forte restricts them in a number of ways to make the generation of C++

code easier. Just a theory. :)

>I had also thought a possible solution would be to allow an accessor or

>mutator reference anywhere that an attribute is currently allowed. This

>also has significant appeal (to me. ...some people have some trouble

>"wrapping their head around" the idea of "SELECT xxxx INTO mutator();")

I've often thought that this would be a good idea, too, but isn't this

really what virtual attributes buy you?

>Now, of course, we have the issue that, if everyone is accessing accessors

>and mutators, that things will be slower. This is also a problem that can

>be fixed, as a number of languages have already demonstrated - and, it can

>be fixed *without* violating encapsulation.

The question I always ask when someone says that approach A will be

slower than approach B is, "Do we care?" Depending upon the

application, many times the answer may well be "no". I believe that it

is best to begin developing an application with everything properly

encapsulated. If the response time is acceptable, then I think that

the benefits gained by the proper encapsulation outweigh the fact that

it's maybe a little slower than it could be. If the response time is

not acceptable in some areas, then you can start looking at those areas

for ways to up the performance, and even then I believe you can usually

do so without violating encapsulation.

Dale

================================================

Dale V. Georg

Systems Analyst

Indus Consultancy Services

dgeorg@indcon.com

================================================

at 2007-6-29 9:22:00 >

While I usually don't reply to my own posts, my (somewhat lengthy)

original rebuttal did not include perhaps the most important point

about the 'friend' keyword...

You (Stephen) mentioned that the friend keyword only serves to

compromise encapsulation. This is true for only those classes that

you define as being friends. For the rest of the world, however,

the encapsulation remains in place. Remember, the needs of the many

outweigh the needs of the few... So while I may have to break my

business object's encapsulation for one or two special cases (such as

a service objects that populates its member variables from the

database) by declaring them as friends, I am still able to enforce my

object's integrity for the rest of the world that accesses it. So, in

the long run, by breaking encapsulation with the friend keyword, I'm

actually promoting far superior encapsulation...

Chad Stansbury

PS - I will try to read your paper when I have access to a PDF viewer

at 2007-6-29 9:22:00 >

I think you have missed the point of the previous message. While public and

private keywords can enforce encapsulation at a class level, they do nothing

to help enforce encapsulation at a component level (component being defined

here as a set of collaborating classes that offer a public interface).

I am also saddened when newcomers are brought into the object oriented

paradigm and told that class level encapsulation is all that you will ever

need. It is simply not true. Design patterns and collaborating classes are

needed if you have all but the simplest of applications to build. The

public/private settings in Forte do not give a developer any way to define

the scope of the privacy.

In other languages such as Java the scope of privacy can be controlled

within in the class (this is Forte's current ability), class hierarchy or

class package (this is effectively the friend concept). This is glaring

omission from Forte. Without this control, building collaborating classes

that work together and offer a consumer of the classes a public method

interface with only those messages that one can call as public is near

impossible to construct.

The interesting thing about all of this is that Forte themselves do not

depend solely on the public/private settings in their own Framework

projects. They have an ability to hide classes, attributes and methods in

the repository independently of public and private settings. Yet,

internally they can still instantiate those classes and call those

attributes and methods. Most of these classes, attributes and methods can

be "turned on" (made public) to a developer with Forte logger flags. Surely

the Forte logger flag is not a mechanism that should enforce object

encapsulation, yet it does. With this mechanism, Forte can "turn off" (make

private) classes and interfaces while the hidden classes still know how to

call other hidden classes, attributes and methods. In essence the Forte

framework classes are all friends of each other. Is Forte wrong for doing

this? No. They saw the need to be able to control the scope of their

class, attribute and method privacy and to be able to programmatically

change it. Very nice. What they have failed to acknowledge is that many

projects have the same need to control the scope of this privacy.

What I have seen many projects using Forte do is to rely on the honor system

for privacy. That is, things are considered conceptually private by

prefixing them with an underscore. This is quite troubling because there is

no compiler (or runtime for that matter!) enforcement of this conceptual

privacy. Yet the simple public/private model that Forte offers just does

not allow enough control to always be useful.

Just like in real life, privacy is not an all or nothing switch. Things

private to me may not be to someone or something else. The relationship of

two things has a lot to do with the definition of privacy between them.

Today, Forte makes you define the privacy of something without regard to the

kinds of classes which may use it.

Mark Perreira

SCAFFOLDS Chief Framework Architect

Sage IT Partners

--Original Message--

From: owner-forte-users@SageIT.com

[<a href=

"mailto:owner-forte-users@SageIT.com]On">mailto:owner-forte-users@SageIT.com ]On</a> Behalf Of Stephen McHenry

Sent: Tuesday, January 27, 1998 12:00 PM

To: Chad Stansbury; 'kamranamin@yahoo.com '

Subject: RE: Limits of virtual attributes

At 09:34 AM 1/26/98 -0600, you wrote:

<...snip...>

>As an aside, I would

>also recommend that you stop worrying about public/private since (as I

>see it) the only way to programatically enforce encapsulation is via the

>protected and friend keywords which TOOL does not provide. I have long

>ago given up trying to fit the square peg into the circular hole...

I had a long and humerous parody of this statement that I was going to post

that took the consequences of this statement through the full software

lifecycle with all of its consequences, but finally decided that, in good

taste (something I'm rarely accused of ;-) that I couldn't post it. So, a

"more professional" response follows:

The thing that saddens me when I see this type of statement is that some of

the people new to the object paradigm might believe it and use the advice

to build systems. Saying that "the only way to programatically enforce

encapsulation is via the protected and friend keywords" is like saying that

"the only way to programatically stay dry is to jump in a swimming pool."

The protected and friend keywords do nothing to enforce encapsulation.

Exactly the opposite. They only serve to compromise it. For methods, there

are valid uses for "protected". For attributes, there are none. Not a few.

Not once in a while. Not when necessary. None. For more information and a

complete discussion of this topic, readers are invited to:

<a href=

"http://www.softi.com/documents.html">http://www.softi.com/documents.html< ;/a>

for a paper discussing attribute and method visibility.

I do not discuss "friend" in there, so a few words about it are in order

here. The purpose of "friend" is to make completely visible to one class

the private (that is, encapsulated) attributes and operations of another

class. So, saying that "friend" promotes encapsulation is like saying that

the best way to keep people from knowing what's in your house is to remove

all the exterior walls. (Maybe I'll update the paper soon and talk about

friends in more detail.)

I have never found anyone who has experienced the long-term benefits of

good encapsulation who ever wants to go back to the days before we had it

(which is what public/protected attributes and "friends" does).

Stephen

at 2007-6-29 9:22:00 >

You are mostly correct. My response was probably too quickly

typed out and was therefore a little more encompassing than it

should have been. However, I'll stick by my original statement,

with a little more clarification...

For Forte TOOL (especially when dealing with the database)

the lack of the friend keyword often requires that you declare

your member variables as being public - thereby eliminating any

*programmatic* way of enforcing the data hiding aspect of encap-

sulation. I'm ignoring the virtual attribute solution because

I prefer speed and simplicity to kludges.

As for the protected keyword - If you plan on providing

any functionality at a (possible abstract) base class level, all

of the methods must be declared as public for the subclasses

to use that functionality... Regardless of whether that method

is not intended for use outside of that class hierarchy. When

I originally started using TOOL I was constantly going back and

reclassifying methods and/or member variables as having public

access due to the fact that subclasses were not able to access

the superclass's private methods/variables...

Therefore, due to *TOOLs* lack of public/friend keywords *or

their functional equivalents* I have resorted to declaring most

of my attributes/methods as public to save time and frustration.

I do however, declare in my method header blocks the actual

accessability (public/protected/private) that I intended. When-

ever I use C++ and/or Java this is not the case...

Note that this is the essentially the same solution that many

Smalltalk programmers tend to use since all variables/methods are

public in that language.

In conclusion... (finally) You are right in your statement that

protected and friend keywords don't 'enforce' encapsulation...

So I'll reword my original statement:

'The protected and friend keywords (or their functional equivalents)

provide a programmatic means to create and enforce a *useable*

and maintainable level of encapsulation'.

Chad Stansbury

PS - Peggy, is this a good enough rebuttal to begin the debate?

PPS - Thanks for siding on the side of diplomacy - it is often

severly lacking on the internet today...

-

From: Stephen McHenry

To: Chad Stansbury; 'kamranamin@yahoo.com '

Sent: 1/27/98 1:59:57 PM

Subject: RE: Limits of virtual attributes

At 09:34 AM 1/26/98 -0600, you wrote:

<...snip...>

>As an aside, I would

>also recommend that you stop worrying about public/private since (as I

>see it) the only way to programatically enforce encapsulation is via

the

>protected and friend keywords which TOOL does not provide. I have long

>ago given up trying to fit the square peg into the circular hole...

I had a long and humerous parody of this statement that I was going to

post

that took the consequences of this statement through the full software

lifecycle with all of its consequences, but finally decided that, in

good

taste (something I'm rarely accused of ;-) that I couldn't post it. So,

a

"more professional" response follows:

The thing that saddens me when I see this type of statement is that some

of

the people new to the object paradigm might believe it and use the

advice

to build systems. Saying that "the only way to programatically enforce

encapsulation is via the protected and friend keywords" is like saying

that

"the only way to programatically stay dry is to jump in a swimming

pool."

The protected and friend keywords do nothing to enforce encapsulation.

Exactly the opposite. They only serve to compromise it. For methods,

there

are valid uses for "protected". For attributes, there are none. Not a

few.

Not once in a while. Not when necessary. None. For more information and

a

complete discussion of this topic, readers are invited to:

<a href=

"http://www.softi.com/documents.html">http://www.softi.com/documents.html< ;/a>

for a paper discussing attribute and method visibility.

I do not discuss "friend" in there, so a few words about it are in order

here. The purpose of "friend" is to make completely visible to one class

the private (that is, encapsulated) attributes and operations of another

class. So, saying that "friend" promotes encapsulation is like saying

that

the best way to keep people from knowing what's in your house is to

remove

all the exterior walls. (Maybe I'll update the paper soon and talk about

friends in more detail.)

I have never found anyone who has experienced the long-term benefits of

good encapsulation who ever wants to go back to the days before we had

it

(which is what public/protected attributes and "friends" does).

Stephen

at 2007-6-29 9:22:00 >

Hi Stephen,

Well I've read your paper. I agree.

But, in my own experience in Forte, I have to recognize that I don't

have protected visibility : it makes me very often pass a private

attribute or method to public when I need to overwrite in sub-class.

If I give a class or a service to other developpers, I need to protect

my code. That's right. So my real aim would be to have someting like

isInternal property on my class and then to use interfaces for instance

as publication. If I look at interfaces, I only can use Virtual

attributes and so have the limitation that a virtual attribute

can access only public attributes or methods : it becomes not so

virtual.

If I look at Forte libraries as Framework and then in debug :

1- there are more public attributes and methods then published in

the documentation

2- nearly every public attributes of the documentation seem to be

in fact a virual attribute

3- in debug I have to look at internal attributes to see real values

in most cases

Here are just some ideas...

So let's continue the discussion of November 1997...

at 2007-6-29 9:22:00 >

I'd strongly recommend that you *not* use virtual attributes as a

means of making your attributes private. Just think about what kind of

performance hit you're going to take by incurring a message send for

every virtual attribute that you're fetching into. As an aside, I would

also recommend that you stop worrying about public/private since (as I

see it) the only way to programatically enforce encapsulation is via the

protected and friend keywords which TOOL does not provide. I have long

ago given up trying to fit the square peg into the circular hole...

Now,

with 4.0 and the introduction of Java, that's another story (I hope)...

-

From: Neil Gendzwill

To: kamranamin@yahoo.com

Sent: 1/23/98 4:42:22 PM

Subject: Limits of virtual attributes

Can you use virtual attributes in SQL statements? We'd like to select

data into an object with private attributes, and using virtual

attributes

seems like a slick way to do it. It compiles OK, are there any run-time

considerations? If you can use a virtual attribute, is there some

syntax

that will let you put the access methods directly into the SQL

statement?

Also, the guide to the workshops claims that you can't map a window

widget

to a virtual attribute, but I've tested this in 3.0F and it seems to

work

fine. Am I missing something?

========================================================================

Neil Gendzwill, Senior Software Engineer, SED Systems, Saskatoon, Canada

E-MAIL: gendzwil@sedsystems.ca PHONE: (306) 933-1571 FAX: (306) 933-1486

Guest at 2007-6-30 22:02:43 >