|
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
|
|
|
|
|
Enterprise Architect from Sparx, supply an add-in for full UML support in VS 2005.
|
|
|
|
|
Hope im in the right board for the type of questions i am about to ask.
I'm turning into the BLL / DAL 3 tiers architecture and i'm confused a bit.
Just to clear things up
- i'm working on VStudio 2005, .net 2.0
- my DAL implementation would be in an xsd file (typed dataset)
- my BLL will be my own "wrapper" around the DAL
1) What is the relation between a Database Table, a DAL/BLL set, and a set of operations
i.e: Say i have an Order Editing form. I will in this form Delete full orders, by means of an orders list, and i will be able to Edit some order details, as Both the order header (Master table) and the order rows (Child Table).
Now, should i create a DAL containing both Tables or should i work with 2 DAL/BLL objects, one containing my master table, the other containing my details table ?
On my Shipping Form, i need access to both Order Master/Details and Inventory because when i ship some items, my inventory has to decrease. I also need to validate that i have enough inventory to complete the operation... should inventory be part or the same DAL Definition ?
Should i create a new DAL / BLL ?
I'm sure you can see i'm really confused and i will appreciate any pointers to guide me.
DB
|
|
|
|
|
Howdy
I recently read a 3 part article by Imar Spaanjaars on n-tier (basically 3 tier) architecture in C#. Coming from many years of n-tier architecture in Java I found this article a very good read. It covers the basics real well and explains the important decisions.
The article can be found at
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416[^]
Cheers Q
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
