|
The Grand Negus wrote: In any case, from a human programmer perspective, (b) is a significantly easier approach because you have to keep much less in your head; things are what they are, period.
Not in my experience and this is precisely why I endorse an object oriented architecture. I've found value in it.
The Grand Negus wrote: Developments of a paradigm that deny the basic tenents of the original paradigm are not developments at all - they are admissions that the original paradigm was simply wrong, which has been my contention since the object oriented approach was invented and popularized by biologist/programmer "everything is an object" Alan Kay. I've lived through this kind of thing once already: the apparent advantage of hierarchical and network databases that fail to live up to their promise and eventually disappear in the light of the simpler relational model.
The basic tenents of the original was fledgling at best. And it was misunderstood in my opinion to mean that encapsulation includes every possible operation. For this reason the string comparison methods for CString in MFC are outside the class structure. Just procedural methods.
I don't agree that everything is an object, and that's been one of my objections with C# and .NET is that they take that approach, albeit catering to the needs of some procedural through the introduction of static classes, which are really just object like containers of procedural functions.
You won't win this argument with me, as its too subjective. I enjoy architecting with objects. I truly enjoy it.
The Grand Negus wrote:
I might think so if I didn't from time to time re-visit the alternative approaches to see if I had missed something. So far - after several of these re-visits - I still see very little benefit (and much unnecessary confusion) in the object-oriented approach. Really. I've coded the same non-trivial applications both ways and the object-oriented approach adds nothing but unnecessarily complexity and more machinery. See, for example, the discussion under point (2) in this[^] thread.
And that's certainly valid for how your mind works when designing systems. My mind works better with a blend of object architecture and procedural. Each does have a place.
This statement was never false.
|
|
|
|
|
|
As far as i can tell, the difference between a Procedural program and an object, is that Procedural sub programs have a single Method entrance with a large parameter list / block and internal branching, wheras an object can expose properties and a number of methods depending on the requirements, so the branching would occur on the level above.
Procedural Program - A set of methods with a central repsitory of values.
Object - A Set of methods with a central repository of values.
As for re-using code by copying functions, you're still fixing something that isn't broke, and an object that already works, works.
If someone changes your Sub Programs, and it breaks, you're still stuck with the same problem as someone breaking your Dll, so it's kind of a moot point. Software is software, in many ways it compares to real life, but it is still a non tangiable platform and the information age caveats apply.
The Grand Negus wrote: This is exactly what I mean by unnecessary complexity. First, they adopt a "pure" object approach and then, when they can see that it isn't quite working, they add something to simulate what they already had before they went with the objects. Schlepps.
I think that's the wrong way round, they static members came first, then objects.
That's just my two cents, but then.... What would i know.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
The Grand Negus wrote: Not in the "pure" object approach invented and popularized by Alan Kay. His first pronouncement on the subject being: "Everything is an object."
A key component, maybe the component, of object oriented programming for Alan Kay was message passing. Keeping that in mind, let's look at your oven example:
The Grand Negus wrote: The difference is that the procedural approach separates data and process: nouns over there, verbs over here. Cookies there, ovens there, baking something that the (implied) cook does with cookies and ovens here.
The object approach makes the processes part of the data: methods inside objects. Cookies there, ovens there, baking a method inside the cookie which somehow bakes itself. Or maybe inside the oven. Who knows? And what happened to the cook?
Well, my take on that would be that the aforementioned objects would send messages to each other. So we have an Oven that takes a Cookie. The Cookie is placed in the Oven by a Cook. The Cook sends a message to the Oven to bake at 350 degrees for 30 minutes. The Oven sends messages to the Cookie so that it changes as a result of the baking. When the Oven is done, it sends a message to the Cook that it is finished baking. And so on...
If I were implementing this in C#, I'd create an interface representing anything that can be baked; the Cookie class would implement this interface. That way the Oven doesn't have to know it's baking a Cookie, just that it has a "bakeable" object that it can send messages to.
|
|
|
|
|
And that is the problem in a nutshell. You are too focused on the english correlation to the code. I don't think about nouns and verbs. Never liked my English class. So, the moment you force me to focus on English you've lost me.
The Grand Negus wrote: An animal is a thing...
A cat is an animal with...
A dog is an animal with...
To pet a cat...
To feed a dog...
To bake an animal in an oven...
Frankly that is just too much to supply.
And the elipsis implies that the definition is incomplete.
I really don't liken to the concept of programming in this fashion.
How do you reuse code?
How do you take the definitions supplied in one program and make them available to other programs. Code reuse is a biggie. I for one, will not take on a language where I need to define everything everytime.
This statement was never false.
|
|
|
|
|
I drop the assembly in the directory I'm using. Once built I don't need to cut and paste.
This statement was never false.
|
|
|
|
|
The Grand Negus wrote:
I'm a Telecaster man myself, but I won't deny that there's virtue resident in the Humbucking pickup device...
Only if you have the option of a coil tap.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Pete O`Hanlon wrote: Only if you have the option of a coil tap.
One of my Les Paul's has that option. The Black Beauty pickups let you switch back and forth between single coil and double coil. I won't claim it sounds like a strat or tele in single coil mode, but it does sound sweet.
Will get back to this thread later time allowing...
|
|
|
|
|
Leslie Sanford wrote: One of my Les Paul's has that option.
Sweet.
I've always wanted to go more Les Paul, but having come from a Van Halen/Vai rock type background - I've always ended up buying guitars with Floyd Rose style trems. Mind you, as I'm getting older (and a bit more mellow), perhaps it's time for me to experiment with a fuller sound.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Well, I don't see it this way. I'm not a purist. It doesn't have to be exactly right the first time. Not only in design, and development of code, but also in design and development of paradigms its an iterative process. I'm not gonna choose to throw the baby out with the bathwater here.
Like I said before, which you seem to be selectively leaving out of the discussion is that I personally prefer a blended approach and don't see this as competition between procedural and object orientation, but rather as complimenting themes to be used where useful.
So, I enjoy the current wave. I'm productive in it, and can think fluidly when designing a system.
This statement was never false.
|
|
|
|
|
The Grand Negus wrote: And since I use my tools, in essence telling them what I want them to do, it isn't a big leap to the conclusion that the procedural approach is a better fit when working with tool-like objects.
No sell. Software is a better match to the machines that we build using tools. Therefore how we use tools is not germane to your "procedural" point. Software is more comparable with an automobile or an aircraft carrier than tools. You are just wrong... as usual.
led mike
|
|
|
|
|
|
The Grand Negus wrote: Your definition of "tool" is too narrow
No, you are ignoring that those are machines. Machines are used by people as are tools but they are vastly different of course. Ignore it if you like but then you have the resultant flawed analysis and bad decisions based on it as a consequence.
led mike
|
|
|
|
|
|
The Grand Negus wrote: I stand by my original argument: living beings do things by and for themselves; artifacts (tools, machines, etc) are used by humans as an aid to the accomplishment of an end.
that's your original argument? Whatever... I quoted what I was replying to, here is another:
The Grand Negus wrote: most programs are more like tools that are used to do things - the procedural paradigm is more appropriate in these cases.
you are just wrong, period.
led mike
|
|
|
|
|
led mike wrote: The Grand Negus wrote:
most programs are more like tools that are used to do things - the procedural paradigm is more appropriate in these cases.
He seems to think that because humans use a procedural approach to using a tool, that it follows a tool should be coded, and follow, the same procedural method. Not so IMHO.
This approach may be true for simple tasks for programs to follow, but OOP developed out of the need to develop more complex tools.
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
|
|
The Grand Negus wrote: And that a paradigm that pictures a word processor as a tool is more likely to succeed than a paradigm that see a word processor as some kind of plant or animal.
It is a tool. The problem is that you're not looking deep enough into the word processor. As with any tool, say an electric drill, it's made up of parts that interact with each other in very specific ways to accomplish a function of the drill. Some parts are interchangable with other drills to modify their function in some way.
Animals and plants are built the same way. Out of many smaller pieces that interact in specific ways to give a more complex organism life and various functionalities.
The adaptability of humans is a testament to such a concept. Human's weren't made with wings, so they couldn't fly. Add the classes called MetalWings and a class derived from IThrust and you've enhanced the abilities of the Human class so he/she can fly, and you done it without modifying the code for Human.
Your argument is flawed because you're ignoring the fact that all tools are made up of smaller pieces, that, individually, are interchangable and couldn't do any part of the task the tool was designed for by itself. The interaction of objects is what provides the functionality, not the objects themselves.
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
|
The Grand Negus wrote: Actually, OOP developed out of biologist/programmer Alan Kay's notion that programs are like living beings, their "objects" like living cells.
They are. They are also like tools as you suggest and Machines as I stated, they are also like a pair of shoes or a bar of soap... so what?! There are many things that programs are "like" but you are trying to limit them to being "exactly" like a hammer and therefore we should only think of them from that perspective.
Perhaps the software you have experience with is more like a hammer than an Aircraft carrier but that is not my experience and therefore you are never going to convince me, and I hope not many others either.
led mike
|
|
|
|
|
The Grand Negus wrote:
Actually, OOP developed out of biologist/programmer Alan Kay's notion that programs are like living beings, their "objects" like living cells. That is the notion I'm arguing against.
Maybe its conception. But not its adoption. Its adoption is pretty wide spread wouldn't you say? I say that's because it effectively solved some complex design requirements fairly elegantly.
This statement was never false.
|
|
|
|
|
I don't think its profitable to force what we do into these narrow terms.
And what difference would it make to consider them as tools or machines.
But I think a valid point is missed. Take the automobile for instance. You can take the brakes and use them with one auto or another. Parts are interchangeable. An engine is a complete object consisting of other objects. It has input and output. But, it is an object. Not a function. Its action is a function of those objects' interactions. In this case, I'd like to put my 350 from my Blazer and drop it into my Jeep. A few other objects and viola! I can do it. I liken software to this. The assemblage of parts.
Looking at the human being. The liver is an object. It performs a function. That function is encapsulated. Taking the heart for instance, we've even been able to supplant the human heart with it, and acheive the desired functioning irrespective of the host object. Human or pig.
Procedurally this can't happen. Only with objects. In your world maybe the only objects are the concepts of modules and routines and sub-routines.
This statement was never false.
|
|
|
|
|
Let's start by saying I don't think procedural solutions should be banned. I've never advocated one over the other. But subscribe to a balance.
How would you procedurally replace a human heart with a pig heart? Easily enough, as that is in fact a procedure. But, is the heart itself a procedure? Can you swap out the pig procedure for the human procedure? Maybe, but its stretching it to make it fit. An object description works better in this case. I would have the heart be an object, and the transplant a procedure.
Really, can you argue against a blend of paradigms? Is procedural absolutely the best for all cases?
This statement was never false.
|
|
|
|
|
The Grand Negus wrote: But OOP has it all inside-out, just like many here who strongly resist (but don't understand) what I'm saying. For example, I've said repeatedly that specialized syntaxes can be used within a Plain English program where they are more effective in getting the job done; but the overall framework should be the natural language, not the special one. We write math books in English (the framework) with the formulae (special syntax) inserted in appropriate places, not the other way around.
Math books are talking to humans. You wouldn't use it to solve the problems.
When I'm performing mathematics I prefer mathematical syntax. I break word problems first down to a set of images that break out the problem into mathematical notational concepts then work with the math syntax to solve the problem. I can't solve the problem using English. When I am writing music I rely upon time signatures to dictate the pace and feel, and I depend on notation and the key signature to dictate the notes and range of the melody. I rely upon chordal notation and the circle of fifths to plan progressions. I rely on that same circle to work out complementary tensions to use in chordal movements, say when writing a sax spread for a jazz standard. When I'm performing code construction aimed at talking to a machine, I prefer the C-Style of syntax. The same as with music and math, I would not want to conceive of and develop the solutions in English. But, now we've left the procedural vs object debate we were originally discussing.
This statement was never false.
|
|
|
|
|
That prefers to work with objects.
This statement was never false.
|
|
|
|
|
I want to draw class diagram inside visual studio 2005 web application. I know that i can add a new item of type "class diagram" to my solution but the .net class diagram is very poor. I can't add multiplicty for my relation. I can't add an association class. I can't make a dependency between two classes. so, can anyone help me to find a better way to draw a good class diagram and to get the generated C# classes from it?
Thank You
Ahmed
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
