Anonymous
Unregistered
|
|
I think this whole argument just shows the FAILURE of object-oriented programming with current technologies. How many times have you seen a 'domain object' that has nothing but data fields and collections. Okay, add some getters and setters (and some adders and removers for the collections). Then nobody wants to 'pollute' this domain object with any further behavior. Okay, isn't this object just like a struct in C? Yes it is nothing but a data structure, and now we are going down the slippery-slope of procedural programming (which is fine unless you really want to be OO).
So now add the type of objects I call 'processors', these are objects that take these data structures and perform actions on them. Almost always, these processers are singleton-like entities. You might as well have coded them in C and just put them in different files to organize them. Or just write a bunch of different classes (to categorize what 'layer' they are in, etc) and use static methods instead. Why instantiate them if you are just writing functions that work with data structures? They have no data of their own, they just contain the functions that work with the data structures.
The point is you can do a whole lot with dynamic memory allocation of structures, which are then operated upon by procedural code. Many great procedural programs have been written like this. However, this is exactly what I see in Java all the time... You have a bunch of data structures with no real behavior, which are operated upon by a bunch of singleton-like objects that have no data. You can throw in a little bit of polymorphic behavior here and there just to make it look like it is fancier than a C program, but in the end, you end up with a harder to maintain program, because you are using an OO language to implement procedural techniques.
And now we get to drawYourself(). Here is where everything on either side of this argument falls apart. Some say that you are going to have tons of different drawYourself() methods in the object, and that you should make other classes to draw it in different ways. And they are right. But, now haven't you just moved the code from a 'monolithic object' into a 'monolithic layer'? Yes, the code is about the same in either location, you have just put them in different places. And guess what, your renderer would probably do very well as a static method, since the object you are rendering has now become a data structure, and your renderer is just a procedures. How OO is that?
I could ramble forever on this, but as far as I can tell, I have raised more questions to myself in this note than I can answer. If you get anything from this, it is this...
* With Hulubs technique, you end up with objects that have way too much behavior and end up with too many dependencies. Objects often know way more about how to do things than you would expect.
* With the anti-Hulubs technique, you end up with objects with no behavior, and in essense just become data structures acted upon by objects that have no data, and are just a collection of procedures.
And in the real world, you get a mixture of both that is probably harder to maintain than either extreme, and this is where I find the problem lies. My belief is there is some missing feature of OO programming languages that reconciles the problems of either philosophy.
|
Jeff Varszegi
Unregistered
|
|
Just because you don't know how to write object-oriented code, you think it can't be done. Sounds like you're halfway to successfully convincing yourself that you don't know what you're talking about. To say you can write a procedural program in Java is old hat.
You sound like an angry person. Chill out-- just because you haven't caught on to an eight-year-old technology yet doesn't mean it's bogus. To discard all object oriented languages and theories as nothing but hype is pretty dumb. I don't know what you're looking for, either; do you think that someone's going to give you enlightenment on how to write object-oriented code in this dying forum? It takes quite a while to really learn what object-oriented coding is about if you do it on the job every day and keep up with your reading.
The kind of thing you're talking about is possible, but in Java it really only works well if you're writing a batch process: something that fires up, processes a bunch of data, and powers down. To write something like a Web server completely procedurally in Java, you would have to dump a crapload of information in global-access areas to avoid creating objects from your own classes, and I'm betting you haven't seen that sort of thing done (although I have).
You sound a lot like a DBA at my place of work. He's a good enough guy, but in his opinion everything should be written as stored procedures if at all possible. You can decide to learn about Java and .NET or whatever you want, or you can keep coding in your assembly language or whatever it is you find most comfortable; just have reasonable expectations about what you'll accomplish, and don't waste my time spouting crap.
Jeff
|
Anonymous
Unregistered
|
|
You missed my whole point. Eight years old? I was doing OO programming in 1991. Okay, so you meant Java, fair enough, but most of the concepts of OO were not invented by the designers of Java, I hope you know. My whole point is that there is some idiom missing from OO languages that reconciles this problem that leads people down the path of making so many objects into data structures, that are operated upon by a bunch of behavior only objects. And if you read more carefully what I wrote, you might get my reasoning and ideas about why this has become an issue. And to conclude, you sound like one of those hOOlier than thou people who is nowhere near as skilled as they think they are.
Here is a hint, if you would like to buy a clue... What I'm saying is how MANY people are using Java in a non-OO way. I AM NOT ADVOCATING USING IT IN THIS MANNER.
I love what I spout, because I love to watch idiots misunderstand it.
|
Allen Holub
Unregistered
|
|
Couple of things,
First of all, everybody who's thinking that I'm advocating heavyweight objects with billions of rendering methods is putting words in my mouth. There are lots of better ways of doing things without exposing implementation details. (The Gang-of-Four Builder and Visitor patterns comes to mind immediately.) So there are more than two alternatives. This is a side issue, though.
Your main point of OO having failed is much more interesting. In many ways, I agree with you. Steve McConnell (ex editor of IEEE Software and author), talks (in his wonderful book "Rapid Development") about his discomfort with OO systems. His main point is that OO is an expert's technology that will never be widely enough understood. There are certainly lots of failed projects (that---in my opinion---failed through a misunderstanding of core OO concepts) to prove his point. There are even more failed procedural systems, though (if for no other reason than we've been doing procedural longer.) Standish Group pegged the project-failure rate at 72%, which is an eye-opening number, to say the least.
On the plus side, we are learning a lot about software process. Techniques like use-case analysis and system modeling are valuable, no matter what methodology you're using. I've also seen a lot more understanding of OO concepts, lately, and have seen a lot of very-well-done OO systems, so maybe McConnell's wrong, and the problem is one of momentum, not inherent difficulty.
Of course, when I talk about "Procedural" vs. "OO," I'm talking about someone who's taking care to design their system properly and build it carefully. There are lots of good procedural methodologies too (Warnier-Orr, etc.) Ad-hoc throwing together of code never works, and that sort of code isn't procedural or OO. It's just a mess.
Programming, of course, is an extraordinarily complicated undertaking. In some ways, it's amazing that we get anything to work at all. I don't think that anybody would argue that we all just give up and go home, though, and I like to think that everybody here, regardless of their position on the current encapsulation issue, is trying to write the best code that they can in the best way they know how.
So, I find OO systems to be more viable than procedural ones in my own work, so I'm biased in that direction. I can't make a general claim that I have the answer to the how-to-program conundrum, though. If both procedural and OO approaches are less than ideal, then we all need to start thinking about better ways of doing things. My readings in Aspect-Oriented Programming leave me unimpressed, but I was dubious about OO systems back in the early '80s when I first learned about them. If we expect to move the profession forward, though, we need to vigorously debate the issues in an intelligent and thoughtful way (and if you discount the polemics, there's actually a lot of constructive discussion going on in this group).
-Allen
|
Jeff_Varszegi
stranger
Reged: 09/18/03
Posts: 5
|
|
A nice, thoughtful reply.
BTW, I think you can register. I did it this morning. It's just not as easy to notice the link to do it in these response forums as it is in the main ones. I'm logged in right now so I can't see it, but there should be "Login" and "New User" links at the top of this section that should be just what you need. Of course, I guess anyone could register with anyone's name, but it would be a little better than posting anonymously.
|
Jeff_Varszegi
stranger
Reged: 09/18/03
Posts: 5
|
|
Okay, I'm a dummy. If you go to the next page of postings by clicking the link at the bottom, you'll see what I'm talking about at the top.
|
JMW
Unregistered
|
|
Thanks for understanding my original post, unlike some other people on here that have replied to my thread. I meant to show that it is a widespread practice (esp in webapps) to use 'pure' domain objects, that have nothing but accessors and collection manipulation methods. And then, these domain objects are fed to a bunch of processing objects, that perform the work, and mutations of them. My point was : THIS IS VERY MUCH A PROCEDURAL TECHNIQUE. My post was meant to describe why (mostly because the processors are little more than functions, since they act as singletons objects (servlets anyone?)).
The "failing' of OO is the fact that in order to make separation of concerns, and to handle many aspects of a system (objects over network, presentation, security, layers, etc), most of the objects that are modeling real-world entities are actually being reduced to data structures with no behavior. Another huge problem is that often one group writes the domain objects, and then they jar them into a library (often with a library to perfrom persistence, transactions, etc, on them) and another group manipulates them. This makes it hard for anyone to add behavior to the objects.
And my final ponderance is what is missing from OO paradigms that resolves this problem. Can you use aspects to get around this? Is there some yet undiscovered technique we could use to provide different "views" to an object with a language mechanism.
I hope this clarifies what my original post intended to discuss. Someone decided to believe that I was actually supporting writing procedural code in Java!
-JMW
|
Anonymous
Unregistered
|
|
Your reply clearly states the problem with both solutions - the key is BALANCE.
I personally find the simple domain object, usually with only a few basic manipulation 'helper' methods, coupled with processor (service) objects to be a VERY elegant solution.
The key is using proper OO techniques (including inheritance!) when creating the processors (services).
The processor objects fit very nicely in a 'web services' world, as they form the basic interface (and implementation) of the service. See how EASY it is to deploy a web service using GLUE with a processor object based system.
When a processor 'uses' another 'service' to peform some 'work', you are using simple delegation.
We have services (defined by an interface - DESIGN BY CONTRACT) to perform service location, service instatiation, logging, persistence, GUI rendering, reporting, security control, and in most cases services delegate to other services to perform some of their service.
This is our 'services' based application framework.
The service implementations are 'black boxes', which leads to extremely easy to maintain code - coupled only to other services via their service interface.
Almost all of our services derive from a base service implementation, where common context methods reside.
In designing a system this way, you also provide the ability to develop different portions of system in isolation and parallel, without fear of one team 'breaking' your service. Changes to the domain objects MAY require changes to the service that uses them (only if the changes remove or change an existing property/method), but since the domain objects consist mostly of simple properties and methods, the associated changes to the services are almost always trivial and can be automated with a decent IDE.
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
