Re: OO solution?
Date: Mon, 26 Jun 2006 23:04:39 GMT
>>kvnkrkptrck_at_gmail.com wrote: >> >>>In keeping with other discussions in cdt, I can't help but wonder if it >>>wouldn't be cleaner to use an OO solution. >> >>No, it wouldn't. A cleaner solution simply would avoid trying to state >>facts about two mutually exclusive things in the same sentence. A >>cleaner solution would state facts about group permissions separately >>from facts about user permissions. >> >> Just create a Document >> >>>class, and an abstract Viewer class extended by a Group class and a >>>User class. >> >>Already you have introduced a useless entity or concept: viewer.
> Viewer has plenty of uses
Not in the context of the problem given, it doesn't.
- it lets me create a list in each Document
> object that is flexible enough to hold either a Group or a User.
In other words, it is a superfluous entity created so that you could introduce a superfluous structural element while destroying symmetry and tossing away arguably the single most powerful formalism for managing data. I have to admit that is a stunning feat!
> object orientation courses it is taught that this is a powerful feature
> of the OO paradigm.
What, exactly, is the feature you refer to? The need for superfluous entities? The added structural complexity? A very low-level procedural language for specifying how instead of what?
I suggest those teaching such nonsense should be exposed for the idiots and scoundrels they are.
>> Each Document object can maintain a list of Viewers which >> >>>can view it. >> >>And yet another useless structural element: list.
> If I didn't use a list, what pray tell would I use to maintain the
> Viewers that can view a document?
You are asking me what structural element one should use to maintain a completely useless entity? The answer is as simple as it is obvious: nothing at all.
[longwinded java irrelevancies proving OO's inferiority snipped]
>> Each Viewer object can maintain a list of Documents which >> >>>it can view; >> >>Yet another list to hack together something to try to compensate for the >>symmetry you lost by doing something as stupid as using OO in the first >>place.
> Sigh. It's not hacking
Let's see. You started with something simple using a single structural element and two simple instances of that element. You introduced useless additional entities and a useless additional structural element that broke symmetry. Having broken symmetry you compounded your error by multiplying the instances of the useless structural element.
But you claim that's not hacking. If you are not "using kludges to accomplish programming tasks that are ugly, inelegant, and inefficient", what the hell do you think you are doing? http://en.wikipedia.org/wiki/Hacker
- it's OO paradigm computer programming
Other than demonstrating that you are a self-aggrandizing ignorant, why on earth would you use 'paradigm', which means variously an example, a verb declension or a world-view, to refer to a computational model?
With all due respect, your self-assessment is fundamentally flawed and suggests profound ignorance retards your ability to judge your own skills. Skilled programmers reduce complexity while clarifying rather than increase complexity while obfuscating.
[ignorant goad snipped]
>> each Group object can store a list of users that are a >> >>>part of it; >> >>Yet another list, but this was beyond the scope of the original example >>so it isn't relevant to the comparison.
> Here, I'm just touting the extensible flexibilty of the OO paradigm.
Actually, you were demonstrating the idiotic habit of many OO proponents of intentionally and proudly implementing unrequired features as if doing so is anything other than introducing a bug.
> Did I mention each User could maintain a list of the groups of which
> they are a part?
Did I mention that the whole thing including the above question is irrelevant to the original example? What part of 'irrelevant' do you not understand?
Of course, that was part of the exercise, but oh
> well. This, too, could be serializable and synchronized for
Are you honestly suggesting that adding complexity and additional processing is a benefit? Or that taking something directly represented as part of a database and turning it into something one has to write procedural side-effect code to store is a worthwhile endeavor? Seriously. I have difficulty believing anyone could actually be that stupid--in spite of the all too frequent evidence that some people that stupid actually make careers as database experts.
The sky is the limit
Yes, I agree. There is no limit to how much complexity one can introduce moving in the direction of increasing complexity. However, who would be stupid enough to want to move in that direction?
(and still we're probably only
> talking about needing a small team of skilled programmers to maintain
> what would probably be less than a thousand or two lines of code and
> still ensure all the components work together seemlessly).
"Probably less than a thousand or two lines of code". Compared with two data definition statements and two data manipulation statements. Wow. That's incredible. You managed to take four lines of code and multiply it by 250 to 500 without any discernible benefit from doing so. Bravo.
There should be an award for that. Something along the lines of a Darwin award.
Who to name it in honor of though? Occam for multiplying entities beyond all belief? Naw. It would have to be the anti-occam. Who did Occam spar with back in the day? Or Mark Twain for noting that it is sometimes better to remain silent than to remove all doubt? Or how about an 'Annie Award' for posting evidence of being the world's oldest surviving anencephalopath?
>> applicable monadic properties for User objects is left as >> >>>an exercise. >> >>The same would go for the monadic properties of any user-defined type in >>the relational model. Since a monadic property is really just a relation >>with degree 1, I find it amazing you would even bother suggesting that >>direct support for relations of any degree is somehow less clean than >>something supporting only relations of degree 1.
> Okay, forget I used the word monadic. (Sheesh, can't a OO
> paradigmaniac use the right term every now and then?)
I didn't have a problem with your use of the word. I asked some rather pointed questions that you seem to want to evade. Perhaps you might try answering them to yourself even if you don't want to answer them to the newsgroup.
>>The relational model naturally deals with monadic properties as exactly >>what they are. OO necessarily has to kludge anything trying to deal with >>relations of other degrees.
> I'll bet there are a dozen OO experts who could back me up here: as
> long as the kludge is encapsulated, it doesn't really matter
It does matter when comparing with something that is: 1) simpler, 2) requires no kludge, and 3) requires no extra step to separate concerns or achieve information hiding. Regardless what a bunch of self-aggrandizing ignorants might say to reinforce your idiotic ideas.
- and if
> the kludge doesn't work, then it can be changed without breaking
> anything else that uses the interface.
It's refreshing to see you admit the only possible significant outcome of requiring the kludge in the first place: it might not work. Not requiring the kludge in the first place obviates the possibility.
With rdbms, if you change the
> tables, you might have to adjust the interface to match the underlying
Here you demonstrate profound ignorance of fundamental concepts in the relational model. I suggest you read up on views and logical independence.
[idiotic self-congratulation snipped]
>>Other than announcing yourself as a self-aggrandizing ignorant
> Mission accomplished. :-) Okay, end of the workday, I confess... I'm
> not the OO paradigm fan the initial post may have led one to believe.
>>Did you enumerate any benefits? I didn't see any.
> I honest-to-god tried. I'm not sure I saw any, either. Any OO people
> care to tell me where I went awry?
Plonk. Received on Tue Jun 27 2006 - 01:04:39 CEST