OOP Is Much Better in Theory Than in Practice

Home

News: OOP Is Much Better in Theory Than in Practice

  1. OOP Is Much Better in Theory Than in Practice (149 messages)

    Think object-orient programming (OOP) is the only way to go? You poor, misguided soul. Richard Mansfield contends that OOP is just the latest in a history of ideas that sound good in theory but are clumsy in practice :)

    This article is quite bad. I can't believe that anyone would publish it.

    Here is one, money quote:

    "A frequent argument for OOP is it helps with code reusability, but one can reuse code without OOP—often by simply copying and pasting."

    I for one can't take anyone seriously when he advocates cut and paste as a solution for reusing code. The rest of the article is similar stupidities. It is clear that the author has never programmed on a team and never actually did any real OOP. He doesn't seem to understand inheritance at all.

    OOP Is Much Better in Theory Than in Practice

    Threaded Messages (149)

  2. I was hoping[ Go to top ]

    This would be an article on function on logic programming and how OOP is just one step in the evolution of higher programming patterns and concepts.

    Gee, that would make a nice article......
  3. post-structuralist object oriented system[ Go to top ]

    For your entertainment:

    "Lua’s Story of O"
    http://alt.textdrive.com/lua/19/lua-story-of-o
  4. Why is this article published on devx, and why the xxxxx is it posted on tss?

    It's about the worst thing I've ever read.

    Also, many people confuse OOP with a language. You can do great OOP in C.
  5. Why is this article published on devx, and why the xxxxx is it posted on tss?It's about the worst thing I've ever read.Also, many people confuse OOP with a language. You can do great OOP in C.
    Some of the first C++ implementations were simply a pre-compiler that translated C++ code to C, and then compiled the result to machine code using a regular C compiler.

    What billions of too well welded synapses can do to a person... :)

    Moving on,
    Henrique Steckelberg
  6. Oh boy[ Go to top ]

    This one easily takes the cake as Stupidest Article of 2005... so far. With just eleven months left, it will be tough to find something more misguided, based on even less actual knowledge and logical thinking. The competition remains open in any case and blogfarts shall be scrutinized in search of similar intellectual gems.

    Thanks to TSS for bringing this important piece to our attention.
  7. the same consensus[ Go to top ]

    was reached on Lambda The Ultimate

    You have to wonder about the quality of oversight on the part of the editors,

    Bob Dionne
  8. A brilliant marketing ploy[ Go to top ]

    You have to wonder about the quality of oversight on the part of the editors,Bob Dionne

    My bet is that it was intentional. Think about all the extra traffic to their site just from people complaining about the article.

    Jonathan
  9. Gang programming[ Go to top ]

    And BTW, what's "gang programming" ? Is there a subtle nuance like in, say, "gang rape" versus "team rape" ?
  10. I think this author suffers from nostalgia for the ‘good old days’. Maybe object oriented programming is too complex for him and his friends to comprehend. Besides why reuse when you can duplicate logic where you need it? Who cares about maintenance!

    I think anyone who’s worked at large company has run across this type of developer. They normally come from a COBOL background and find all those objects confusing. They definitely don’t see any problem with cut and pasting code.
  11. Please repeat as many times as you need to get it:
    Procedural style is not equal to "code duplication".

    There are plenty of cases where procedural style is better/simpler/more convenient than OO.

    OO or Procedures, or combination of both sprinkled with AOP and AttOP – it is all fine as long as architecture is clearly defined and based on Layers Of Responsibilities (LOR).
  12. Isn't your LOR, just an logic encapsulated in objects? Except reason that in OOP you can hide what you want explicitely. You dont' have to "clearly define", it's defined by OOP language syntax.
  13. Ever done any COBOL[ Go to top ]

    Who says that COBOL equals bad programming practices. OK, so COBOL is not an object-oriented language--so what?

    I think that the average COBOL program I have seen in my career was clearer, cleaner, better designed, and contained less duplication than the average C++ or Java program I have come across. Now that says precisely nothing about the language--only about the programmers...
  14. I did copy-past , wow scary!!!!![ Go to top ]

    Lets not to be object freak , Object approach like any other technology is answer to specific need .Complex system and those that are growing are the best ones that fits I don’t think everyone who tells object oriented is not everywhere ,anytime solution needs to be label like this:

    “This article is quite bad. I can't believe that anyone would publish it.” (no reason !!!!)


    Remember if that was as easy as drawing class diagrams… we were living in automated world!!!
  15. Oh Wait.. it is the 80s again[ Go to top ]

    Wouldv'e been a lovely article if it were posted in the 80s as part of the OOP war.

    What next? High level programming languages are evil!!! Lets all go back to assembly.. Or something lower ;-)
  16. Wouldv'e been a lovely article if it were posted in the 80s as part of the OOP war.What next? High level programming languages are evil!!! Lets all go back to assembly.. Or something lower ;-)

    What do you expect from a guy who's the author of "Machine Language for Beginners" and "The Second Book of Machine Language". Really.
  17. While it is, in many ways, a laughable article, the guy has correctly identified, in his own awkward way, some of the areas where OOP falls short.
  18. +1 on the stupidity of this article.

    But I also agree with the concept that there are times when procedural code has its place. There is a pretty good article in the latest issue of SD Times by the Java columnist about this.

    I think that there is a "Golden Hammer" school of thought when it comes to OOP / AOP / Procedural Programming. People need to realize that each methodology has its place. The proper application of these programming methodologies is the key.

    John Murray
  19. lets face it.

    copy and paste?? what and then retest???? that's a joke. what if you missed a character when you pasted? or the clipboard had a bug in it.
  20. I think he also forgot to point out that Java is evil because it lacks the fundamental "goto" statement. And why didn't he include the old "Real programmers vs. quiche-eaters" pamphlet in the bibliography section? Or did I just miss the guru's quote?
  21. Last time I checked ...[ Go to top ]

    Hmm, last time I checked there was a goto statement in Java.

    Bye, Andreas
  22. what a pitty![ Go to top ]

    When I saw the title I got excited only to find that this guy is as un-clued-in as the "Objects are Gods" brigade. What a spanner!

    Really would like to see a decent article from this point of view though; but by someone that knows what they're talking about!
  23. Clearly the message is the result of spending too much time in Irish country pubs drinking the "Black Stuff".. I'm afraid this contributor is out of his depth and not fluent in Object-speak.. He needs a large dose of UML to sober him up... :)
  24. But this is a joke ....[ Go to top ]

    I guess that using a old-fashioned calendar
    today is April, 1st

    ... no ?

    I cannot believe that person are arguing on this article ...

    by the way cut'n paste is good in OOP ...

    obviously if you're programming using a prototype approach
    and not a class-based approach !
  25. Some Issues with OOP[ Go to top ]

    IMHO the OO technology of interfaces and polymorphism are awesome! These design principles just seem to match up exceedingly well with the needs and problems at hand.

    However, I have never have felt as strongly about "data encapsulation." While yes, I always make it work somehow, and in many cases it works very well, there has always been some doubt in the back of my mind as to how "true" this principle really is. There are times I feel like I'm forcing a round peg into a square hole.

    Also, has anyone noticed that SOA sort of looks like the old SASD (structured analysis structured design)? Clear separation of processes and data.
  26. Has some valid points[ Go to top ]

    The article is outdated, yes !!!
    Am I the only one to work with people that make everything a pattern ?
    Layer upon layer of abstractions ?
    OOP is a tool like any other. It can be used properly or not. Poor OO is just as bad or worst than tracing through code littered with GOTO statements that take you round and round until your head spins.
    The problem is not the technology, but instead the people that use the technologies. If you are fresh out of school and only studied OO languages, then the only solution is an OO one. If you are more seasoned then you should be aware that "if all you have is a hammer then everything looks like a nail".
  27. Study before saying ..... :-)[ Go to top ]

    I suggest the author to read a good book about object oriented paradigm (in particular studying the differences between encapsulation and information hiding http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation_p.html) and design patterns (maybe gangs of four book... :-))
  28. ROFL[ Go to top ]

    Whoehahahahaha what a joke.
    Just get it off, i wasted time reading this.
  29. My favorite part is where he uses VisualStudio.NET as a good example of how programming languages can avoid adding machine-related devices to the code. Of course, there's the obvious fact that .NET pretty much ties you to a single OS, but I'll ignore that one.

    But isn't .NET code all OOP? I haven't had much experience with it, but I seem to remember this being true... In fact, it's the first time that Visual Basic has ever been truly OO -- something Visual Basic users wanted for a LONG time.

    Seriously, though, OOP probably is just a step in Computer Science history. Even assembly had its day in the sun before being replaced (read abstracted) by any of a number of higher level languages. I would hardly call OOP a fad, but anybody who sees it as the final stop on the CompSci-Express is deluding themselves.
  30. Don't blame the poor guy. His bio reads as follows.
    Richard Mansfield has written 32 computer books since 1982, including bestsellers 'Machine Language for Beginners' (COMPUTE! Books) and 'The Second Book of Machine Language' (COMPUTE! Books). From 1981 through 1987, he was editor of COMPUTE! Magazine and from 1987 to 1991 he was editorial director and partner at Signal Research.

    Obviosuly he was never a hands-on guy. Looks like he never had to develop and maintain gazillion lines of code. How ironic is it for him to talk about theory v/s practice.

    Where ignorance is bliss, nor do I blame, neither do I argue.

    OO Rocks,
    Srikanth
  31. I don't think he is a real person. He looks alot like Milton Waddams in Office Space (http://www.imdb.com/title/tt0151804/)
  32. Ok, if any of you can remember back this far, didn't anybody here subscribe to Compute! magazine? Own a Commodore 64? Learn programming on a Commodore PET in grammar school (and know more than the teacher)? This guy was a GOD. I learned machine language from his book on the C64! Give him some respect!

    That said, I was about 12 when I was doing all this... But the rush I got from moving sprites in ML was frightening.

    Joe
  33. Ok, if any of you can remember back this far, didn't anybody here subscribe to Compute! magazine? Own a Commodore 64? Learn programming on a Commodore PET in grammar school (and know more than the teacher)? This guy was a GOD. I learned machine language from his book on the C64! Give him some respect!That said, I was about 12 when I was doing all this... But the rush I got from moving sprites in ML was frightening.Joe
    You used the correct verb tense: he WAS a god. That's exactly his problem: got stuck into the past. People moved on to newer and better (sometimes even worse!) technologies, and so should he.

    I also have a lot of respect for steam train engineers. :)

    Regards,
    Henrique Steckelberg
  34. OOP wonderfulness![ Go to top ]

    Not that the comments are surprising on a Java site but just to mention of few "OO" technologies.
    Servlets - That would be doGet and doPost how is OO helping us here?
    Session Beans - Can any one explain how this is OO?
    O/R mapping - This is wonderful talk about bloat! Class = Table? struct anyone?
    Interfaces - In Java I would say this is a lot like #include "interface.h". List of "methods" that an object must implement isn't very OO either.
    GUI - Something that OOP is really good for... Except where talking about Java, which failed on the client side.

    I mostly write in OO languages. In Java a lot of it is procedural with namespace (J2EE). Rarely do I get to use OO and create a nice hierarchy but when I can't image doing it in a procedural language. As they say right tool for the job.
    Just calling like it is.
  35. Longing for the Good Old Days?[ Go to top ]

    .Servlets - That would be doGet and doPost how is OO helping us here?
    Java didn't event HTTP Protocol, just gives us an implementation. Request Parameters are an object, HttpRequest & Session is an Object. You are off base here.
    Session Beans - Can any one explain how this is OO?
    Some people want Service Oriented Architecture (procedures), and can't blame Java for supporting them. Criticize Entity Beans as not OO and you sound smarter.
    O/R mapping - This is wonderful talk about bloat! Class = Table? struct anyone?
    Why use objects at all, better to give the users a SQL+ interface and an E-R Diagram so they can have real control.
    Interfaces - In Java I would say this is a lot like #include "interface.h". List of "methods" that an object must implement isn't very OO either.
    Ever heard of a Specification?
    GUI - Something that OOP is really good for... Except where talking about Java, which failed on the client side.
    Swing doesn't work on client when people don't understand OO (C coders?). Works fine for me.

    Maybe you should try the Java Tutorials, http://java.sun.com/docs/books/tutorial/getStarted/index.html,
  36. I'll bite.[ Go to top ]

    Java didn't event HTTP Protocol, just gives us an implementation. Request Parameters are an object, HttpRequest & Session is an Object. You are off base here.
    Would you like a C procedural example of HttpRequest and HttpSession? http://zild.org/api/index.csp

    This was only part of my point. My real point was what did we get by having an OO interface to this? What construct of OO do we use with HttpRequest and HttpSession? They just seem like data stuctures, glorified "HashMap".
    Ever heard of a Specification?
    Yep, Just trying to point out how much Java constructs are mostly procedural. Every heard of multiple inheritance? Multiple inheritance seems a lot more OO but that would be something Java doesn't support.
    GUI - Something that OOP is really good for... Except where talking about Java, which failed on the client side.
    I use Jedit all the time. Ofcourse it is the _only_ swing application that I have ever used that rocks!! Glad to hear there are other Java programmer that are smart enough to hack Swing.
    Swing doesn't work on client when people don't understand OO (C coders?). Works fine for me.
    Can't agree more. People don't understand OO. So shouldn't we just leave the OO stuff to the 3l33t? The rest of us can just program in procedural stuff with some basic OO functionality. Languages like Python, Objective-C, C, Perl and Ruby?
  37. I'll bite.[ Go to top ]

    I use Jedit all the time. Ofcourse it is the _only_ swing application that I have ever used that rocks!!
    http://java.sun.com/products/jfc/tsc/sightings/S21.html
    Please, don´t talk about things you don´t know.
    Glad to hear there are other Java programmer that are smart enough to hack Swing.
    Swing is hard. If you are new to OO and Java, don´t use it, you *will* fail miserably.

    OO is not overkill. To write a simple chat application I used 15 classes. Now, it is VERY easy to:
    - change the entire protocol
    - add new status
    - change skins
    - i18n
    - change the data provider
    - decorate/change/reimplement the security model
    - implement an entire new interface, even with other programming language
    - etc ...
    All of this without changing a single line of the other classes.
    And things get even better when using UML.

    OO is beatiful.

    ps.: the author article is actually an character
    http://www.luminomagazine.com/2004.03/spotlight/officespace/images/mugs/milton.mug.jpg
  38. Interfaces?[ Go to top ]

    Every heard of multiple inheritance?
    > Multiple inheritance seems a lot more
    > OO but that would be something Java
    > doesn't support.

    Dude, ever heard of interfaces? If you need multiple inheritance, you can fake it quite easely...
  39. I'll bite.[ Go to top ]

    I think your understanding of procedural langauge is very limited since all of your examples strive towards products and technologies based on OOP, thus having class, inheritance and encapsulation paradigms.
    This was only part of my point. My real point was what did we get by having an OO interface to this? What construct of OO do we use with HttpRequest and HttpSession? They just seem like data stuctures, glorified "HashMap".

    Data structures are a one of the most integral parts of OOP, if what you meant was really DATA STRUCTURES as in one of the first things you learn starting doing OOP, not STRUCTS as in procedural C, which BTW was a step towards data structures.
    Yep, Just trying to point out how much Java constructs are mostly procedural. Every heard of multiple inheritance? Multiple inheritance seems a lot more OO but that would be something Java doesn't support.

    Which java constructs, again, are procedural? Did not see anything exemplifying that...And if you know Java well, multiple inheritance is not needed and was replaced by interfaces, which gives you quite a bit of more flexibility. Multiple inheritance of concrete or abstract types is a cludge and is easily replaced by wrapping, deleging and factoring and such gives you a more predictable and structured model. (Although anything can be abused and turned around...)

    One thing I agree on is that UI is not yet to the highest standards...
    Can't agree more. People don't understand OO. So shouldn't we just leave the OO stuff to the 3l33t? The rest of us can just program in procedural stuff with some basic OO functionality. Languages like Python, Objective-C, C, Perl and Ruby?

    And what is that *BASIC* OO functionality?

    Sincerely,

    Artem D. Yegorov
    http://www.activexml.org
  40. OOP wonderfulness![ Go to top ]

    GUI - Something that OOP is really good for...

    This is such a 1970s attitude! Much of the original OOP development was done in Smalltalk in the 70s, and then they concentrated on using OOP for GUI code. This was a short-lived phase, as OOP soon researchers realised that object-orientation was a general technique that could be more widely applied. It pains me to see people stating ideas that are 30 years out of date! I wish people who criticise OOP could get experience of an elegant pure OOP language like Smalltalk, and perhaps then they could really begin to understand the power of the OOP approach, and we could finally dispense with this 'sometimes procedural is a good' myth. Unfortunately Java, for all its merits, is a very traditional and old-fashioned language in many respects.
  41. client side Java[ Go to top ]

    Java failed on the client side? I must have missed that memo. I'm writing an application in Swing right now and it kicks ass. Perhaps you are referring to the AWT?


    Good luck.
    Eric
  42. OOP wonderfulness![ Go to top ]

    You are lmao

    servlets, you could extends servlets by creating a base servlet.

    public void service(HttpSErvletRequest request, HttpServletResponse response){
         onService(request, response);
    }

    public abstract void onService(request, response);

    Session Beans - without OO they won't even exist. You forgot they have to implements interface or extends bean when you create them.

    O/R mapping is the best thing ever.
    You can design your objects nicely first then map them into a normalize table structure. Please go to hibernate.org for your own sake.

    Do you know if

    class A implements B{}

    A A_Object = new A();

    B object = A_Object;

    then, you can do polymorphism and some crazy things.

    I dont understand what are you talking about for the GUI part. anyways, thanks for your info
  43. Background on the author[ Go to top ]

    The author is a VB guy.

    Look at his books on Amazon:

    2-star rated VB book

    If you look at his other books, they are all VB-related.
  44. OOP Therory and practice[ Go to top ]

    In my experiance you need to understand the theory before putting it to practice.

    It is a common phenomena that the inqusitive actually put in the effort into understand it before they start critizing.

    Maybe the resistance to change is the driving force behind all this bickering. If you don't understand it don't use it.

    Those that have understood see tremendous value in oop.

    Some of those that did not are still belive thar RPG is great. I agree it was great at the point of evolution when RPG was king.

    Creativity is the driving force some idea break through some don't.
    OOP is a break through idea and I find it tremedously useful.

    By the way I am from the RPG era. All is not lost
  45. This message came from jeffrey bik and was poted mistakenly from this email address
  46. Hmmmm...[ Go to top ]

    Like everyone else here, I'm wondering if he understands using the right tool for the right problem? Maybe he should be looking for his red stapler...
  47. Hmmmm...[ Go to top ]

    +1
  48. I guess this fellow is just like a lot of old guys, they kept stucked in the past, geez look at this guy he was editor and jatti jatta blah blah blah, but at 80's. I know a lot of people in the industry have a lot of experience and all that, but the experience is nothing when you don't evolve with the industry. This guy keeps saying than OOP is a bizzarre abomanation of god, but for me it's a more natural way to program, so come on pal! we need OOP, for states, for black boxes, for keep the simplicity through our objects for other programmers and for ourselves when we read our code in the future. I do think that OOP it's harder to learn than Structured Programming, and that's because OOP it's beyond it, it's the same for AOP it's beyon OOP. I guess pal you have to try it harder to understand OOP.
  49. No Silver bullet[ Go to top ]

    No single technology at all can solve the software complexity problem.

    I suggest some exciting reading for all
     - "No Silver Bullet" from Fred Brooks
     - 60's and 70's papers from David Parnas.

    I believe, in general, in good software design. I mean: information hiding, good module decomposition, good complexity control.

    I depends much more on the guy between the chair and the keybord than the programming paradigm (OOP, AOP, procedural, and so on).

    I saw, in my life, amazing programs written in C or even in Cobol. I also saw lots of spaguetti code written in Java.

    Hope it helps.

    regards
  50. Quite bizzarre[ Go to top ]

    The article is, least to say, quite bizzarre.
    While it addresses some of the OOP issues which may be real, like it or not, it doesn't seem to do this systematically, and , worst of all, without showing how these problems are avoided in other paradigms. Otherwise said: OOP sucks because it can't solve problems that the other paradigms don't solve neither.
    Which is why this article can't be taken as a serious point of view, in my opinion.
  51. Religious times are over ...[ Go to top ]

    The religious wars about OOP are over and this guy wants to fight them again. Hey, were already a step further with MDA or aspect-oriented programming which are deeply based on the now stable OO foundation.

    But one thing I have to admit: badly written OO code is IMHO worse than badly written procedural code. With "bad" I mean OO programs that are bloated because of excessive usage of patterns and ignoring the principle of simplicity.

    I'm actually trying to fix such a beast and it's so hard because the whole thing is absurdly complex with unnecessary abstractions, factories, proxies, managers, visitors and so on, just the whole catalogue of the GOF-Book. Bad procedural code often comes around in the form of long files of spaghetti code which can be quite easily wrapped up in a class and be locked away forever.
  52. Religious times are over ...[ Go to top ]

    Bad procedural code often comes around in the form of long files of spaghetti code which can be quite easily wrapped up in a class and be locked away forever.
    Except when the following such code is in the middle somewhere -
    If err.Number <> 0 Then
     MsgBox Err.Description
     Exit Sub
    End if
  53. My take on this article...[ Go to top ]

    OOP is like a really, really fast race car.

    If you put an idiot behind the wheel, all the horse power in the world won't make a difference.

    Now, put a talented driver behind the wheel of a Geo Metro. No matter how hard the driver tries he'll never reach his potential behind such a steaming pile of crap.

    My 2 cents on the author.

    Idiot.
  54. My take on this article...[ Go to top ]

    OOP is like a really, really fast race car.If you put an idiot behind the wheel, all the horse power in the world won't make a difference.Now, put a talented driver behind the wheel of a Geo Metro. No matter how hard the driver tries he'll never reach his potential behind such a steaming pile of crap.My 2 cents on the author.Idiot.

    We can resume the thread to the above statement, excluding the last word (Idiot.) I think he just doesn't get OOP, or he just gets machine language far more better. Which entitles him for "Ignorant".

    Saying OOP isn't successfull after all that is happening in the programming world these days is like saying programming languages are useless.

    I would like to hear what he has to say on AOP if he has ever heard of it ! flaf.
  55. I don't like the authors methodology[ Go to top ]

    My personal opinion is that negative articles should clearly state what the solution ought to be. The author talks about a better world, but it seems we must buy his next book to learn exactly what this is.

    Thank you, but no thanks. I will happily listen to someone talking to me from the bottom of a muddy trench, but it is just pathetic when some grunt from suburbia tells someone in a trench he is not digging the trench right.
  56. what happens when an error occurs on the code which is copied and pasted at 10 different locations on the code-base ?? didn't author think about that ??? i think the author's a dumb who knows nothing about OOP :)
  57. life is better in theory than practice[ Go to top ]

    So you should...

    > What construct of OO do we use with HttpRequest
    > and HttpSession? They just seem like data
    > stuctures, glorified "HashMap".

    80% of life is similar. It's just boring routine. Nothing to write home about. The other 20% is good though.
  58. I think, most people confuse OOP with a language such as C++ or Java, including the author of this article. OO is a concept and programming languages are just that - a way to generate instructions to accomplish a task. You can use C++ or Java and still write "procedural" code. In my experience, frameworks and libraries are the best places where OO design makes more sense. Consider for example, Spring framework. The IoC design pattern is realizable because of the use OO concept. It would be harder to achieve this otherwise, if not impossible. But, a business logic, which is unique to an application doesn't gain much by OO design, except comforming to a uniform design. Just take a look at the projects you have been working on and you will realize that there is a lot of "procedural code" inside the objects. By "procedural", I mean, a certain order in which the functions must be called and chained. The objects are not black boxes anymore and you will need to know how each of the functions behaves. The program flow is still procedural, except that "related" functions and data are housed together.

    In summary, OOP and languages are two different things. IMHO, mixing the two is the fundamental flaw in the article.

    Cheers,
    Rag.
  59. WWWhuuuuhahahahaha!

    Richard My Man --- You are da man, Buddy !

    Some one probably asked him to write a book on OOP
    and did work out, Richard got mad.

    Read the story below.

    Richard went to his desk, wrote a book in 15 hours,
    Got it published in another 15 hours. But in next 15 years only 2 copies were sold so he go pissed off, during the same 15 years, he wrote 32 books, none did well finally he said, ditch it. Nothing works, OOP is complex, let the world know.

    Richard, man world got into mess, now what do you propose, shall we scrap, and rewrite all OOP code using cut and paste? Tell us.
  60. me too![ Go to top ]

    In my experience, frameworks and libraries are the best places where OO design makes more sense... Business logic which is unique to an application doesn't gain much by OO..

    Agreed. The beauty of languages like Java (and C#) is that you can still write "procedural" code or procedural stuff with some basic OO functionality. Either because you are a beginner, or because the scenario calls for it. Neither language dictates or impounds on you in anyway how to do things. So the beginner can start easy and (hopefully) be led gently up towards the realms of the full power of OO. This is as it should be. (Like chess, easy to learn but difficult to be Grandmaster).

    However, life has told me that when virtually everybody agrees and joins in vehemence choir against some heretic something smells wrong.

    Can it be that the main body of contract programmers are "jealous" and want to be in the same league as frameworks and libraries authors like Rod & Juergen and therefore force the whole enchilada of OO patterns upon basic simple business projects?

    Regards
    Rolf Tollerud
  61. me too![ Go to top ]

    So the beginner can start easy and (hopefully) be led gently up towards the realms of the full power of OO. This is as it should be.

    This is probably a good way to learn OOP in a hybrid procedural/OOP language Java, but I think it is the wrong way to approach to OOP in general. OOP will always be difficult to learn if it is 'bolted on' and not a natural part of the language. OOP should be simple, lightweight and easy. For example, there should be no primitive types: their presence in Java is for efficiency, not ease of development. There is no real need for Arrays - everything could be collections storing objects. I can imagine the confusion experienced by a beginner who has been using 'int' and then has to deal with 'Integer'.
  62. me too![ Go to top ]

    In my experience, frameworks and libraries are the best places where OO design makes more sense... Business logic which is unique to an application doesn't gain much by OO..

    Now I would add a little nuance to this and I'll say that frameworks and libraries are places where you often find well aplied OOP techniques :-)) Which makes the following comment by Rolf surprisingly valid. Basically he explains how comes that some programs that should be OOP, look like procedural stuff. Is that your case too Rolf ? :-))
    Agreed. The beauty of languages like Java (and C#) is that you can still write "procedural" code or procedural stuff with some basic OO functionality. Either because you are a beginner, or because the scenario calls for it. Neither language dictates or impounds on you in anyway how to do things. So the beginner can start easy and (hopefully) be led gently up towards the realms of the full power of OO. This is as it should be...RegardsRolf Tollerud
  63. OO the worst, except for all the others[ Go to top ]

    Winston Churchill said:

    Democracy is the worst form of government except for all those others that have been tried.

    You could say the same thing about OOP:


    OOP is the worst form of programming except for all those other that have been tried.


    A quick Google search for OOP benefits

    http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=oop+benefits


    and OOP disadvantages

    http://www.google.com/search?hl=en&lr=&q=oop+disadvantages

    shows there's healthy discussion out there on OPP.

    PJ Murray
     CodeFutures Software
  64. 100 times on the black board[ Go to top ]

    All I said that it is a little patetique to wham the full OO sledgehammer on simple business problems Dorel. J2EE programmers are notorious for over-architecturing. If I was their teacher I would force then to write 100 times on the black board: "I am not a framework or library developer".

    Cato the elder used to finish all his speeches no matter the subject with the words,"Furthermore, I believe Carthage should be destroyed". (Praeterea censeo Carthaginem esse delendam)

    I will follow this practice from my illustrious ancestor.

    Regards
    Rolf Tollerud
    (Furthermore it is my view that in the J2EE world you do not differ between Objects, Components or web-Services)
  65. 100 times on the black board[ Go to top ]

    All I said that it is a little patetique to wham the full OO sledgehammer on simple business problems Dorel.

    Its a sign of ignorance to consider OO a sledgehammer. OO is a very simple and lightweight tool.
    J2EE programmers are notorious for over-architecturing. If I was their teacher I would force then to write 100 times on the black board: "I am not a framework or library developer".

    Well, this is a good way to keep programmers employed - ensure that everyone spends their time re-inventing everything! Perhaps you have not, like me, spent considerable time dealing with the nightmarish results of 'cut-and-paste' coding. A developer who does not consider the posibility of re-use in everything they write is being seriously unprofessional.
    Cato the elder used to finish all his speeches no matter the subject with the words,"Furthermore, I believe Carthage should be destroyed". (Praeterea censeo Carthaginem esse delendam)I will follow this practice from my illustrious ancestor.RegardsRolf Tollerud

    Well, next time we need Carthage destroying, we will know who to contact.
  66. He didn't make it to VB.NET[ Go to top ]

    I heard Ted Neward at TSS last year where he said that when Microsoft released VB.NET (which is OO) they lost a lot of developers who didn't like the OO thing. What happened was that the VB developers ready for OO quickly turned to C# and the rest stayed in VB 6. The next release of VB will go back what it was before. I guess this guy is one of the VB6 developers who didn't make it to the new world.
  67. VB is not so much a language (given no chioce a good programmer will use the stuff, and write fairly good code) as a state of mind. After many years of "solving" business problems with an illassorted patchwork of ugly hacks these guys thing they are expert programmers. Despite all evidence to the contary (believe me, they will have encountered a lot of evidence) they will continue to think that they are expert programmers simply by virtue of persistence.

    Good programming is hard, it is not simply stringing together a list of assorted special, it is taking a part of the world and putting it into an order that makes the solution trivial.

    OOP provides a very powerful tool for this process, and OOPLs provide a convienient mechanism to implement these designs (IMHO Java OOP is good enough but far from perfect, Haskell-style type classes would be better; but then I consider interfaces far more important than concrete inheritance)

    I've implemented OO designs in proceedural languages and vice versa. The issue is design: the 'VB programmer' (technically proceedural programmer, but most of them use VB; remember state of mind not language) finds changing language paradigm very hard because they have nothing to fall back on: for them a solution is simply a sequence of actions devoid of structure (functions are just big actions, that they can handle).

    Quite simply there is a certain class of 'programmer' that will never understand any design paradigm, simply because they have no concept of abstract design.
  68. I think it is a joke![ Go to top ]

    Some points is correct and useful.But,most is bad and useless.OOP is the effective way.
  69. OOP is only for the best programmers[ Go to top ]

    I have had the good fortune to work with excellent programmers, and the sadness of working with mediocre ones. My experience has been that excellent programmers using OOP produce incredible code that is flexible, reusable, maintainable, etc.

    Unfortunately, mediocre programmers attempting to use OOP but doing so poorly go the other route. They are typically much less productive than they would have been otherwise. The reason is that OOP introduces some extra overhead when initially writing code. This slows down the mediocre developer (and, to a lesser extent, the excellent programmer). Unfortunately, because the mediocre programmer hasn't used OOP correctly, he doesn't get any of the benefits his slow start is supposed to accrue. His code is not reusable. His classes are not extendable or flexible.

    In short, OOP rocks, when applied properly. Doing so is not easy though, and poor OOP is awful. The scale of productivity goes, with substantial leaps between the levels for large projects:

    Good programmer using OOP
    Good programmer not using OOP
    Bad programmer not using OOP
    Bad programmer using OOP

    There are lots of bad programmers around, and their lame attempts at OOP are the there exists a group of people think it sucks. The greatness of good programmers using OOP is the reason so many others can't fathom what the what appears to be the insanity of the first group. Hence, this debate.

    my 2 cents.
    Eric
  70. The "DeathMarch" mentality[ Go to top ]

    I seriously doubt whether the Author has really worked on any real life projects or is just an academic writing books.

    Procedural programming almost always tend to create "DeathMarch" kind of applications.
    (For those who dont know what the death march is: http://www.amazon.com/exec/obidos/ASIN/013143635X/qid=1107331050/sr=2-1/ref=pd_ka_b_2_1/104-2534818-2646326 )

    Especially the Copy-Paste kind of reuse is the most dangerous thing followed by programmers. Such applications tend to become very fragile, error-prone, complex and difficult to maintain. I believe that OOP has solved the problem to a great extent.
  71. This is all waste of TSS space[ Go to top ]

    This is all a waste of TSS space. Laugh a bit, ignore it, forget it and move on.
  72. This is all waste of TSS space[ Go to top ]

    This is all a waste of TSS space. Laugh a bit, ignore it, forget it and move on.

    But it's sooo much FUN!
  73. encapsulation[ Go to top ]

    I'm no oo bigot recognising that the just'nuff OO methodology is good enough for most people.

    However the author seems confused on many issues. One of the many is that he attacks encapsulation . Saying that hiding the methods from the programmer is obtuse and counter-productive.

    Yet leter on he praises the text box..

    "To the extent that OOP is involved in components such as text boxes (not much, really), it's very successful. GUI components are great time-savers, and they work well. But don't confuse them with OOP itself. Few people attempt to modify the methods of components. You may change a text box's font size, but you don't change how a text box changes its font size."

    That's because they are perfectly encapsulated. They perform a function , how they do it one doesn't need to know. Suffice to say that this is the point of encapsulation in the OO world. Coforming perfectley to the client/supplier relationship. I pass you paramters within class contsraints and invariants and you guarante me a result of type x.

    Black boxing wasn't unique to OO, but OO adopted it more completley than any other methodology.

    OO isn't perfect and for many people the componentized form of OO is good enough abstracting at the component not the class, but the author seems confused about the values of the oo methodology and the benefits it can bring.
  74. I recently had a shift in how I see the role of objects and classes. When I started with OO (in my c++ days) I was told that classes were models for concepts of the "real" world. In this way of doing OO I wrote "heavy" classes with lots of attributes and methods. Also I tended to use a lot of inheritance and polymorphism.
    Today (in java) I look at objects in a different way: since I experimented with ideas from XP and Spring framework I started to use SRP (Single Resposibility Principle) style of programming. The result is that I have 2 kinds of classes. The first kind are POJO's. They are still fulfilling the role of modelling the "real" world, but have only methods related to the responsibility of building up a datastructure (setters, addXYZ methods) and navigating (getters). The second kind are classes that derive a functionality from one or more POJO's. In this style of programming I use a lot less inheritance and polymorhism in favour of composition/aggregation and interfaces. Also, you could say that the POJO's play the role of structs in procedural programming, and the second kind of classes the role of procedures. I am convinced now that this leads to code that is easier to understand an reuse than "classic" OO modelling.
    To conclude this, I think OO programming is swinging back to procedural programming, but as a "next generation" approach to procedural programming in an OO way.
  75. I recently had a shift in how I see the role of objects and classes.

    The "shift" you talk about is actually how Ivar Jacobsen (a OO guru from the 70'ies) described how OO was meant to be used.

    Today, the two categories of classes is typically denoted Domain Classes (information) and Service Classes (that act on that information.)

    This scales extremely well in all sorts of contexts.
  76. I recently had a shift in how I see the role of objects and classes.
    The "shift" you talk about is actually how Ivar Jacobsen (a OO guru from the 70'ies) described how OO was meant to be used.Today, the two categories of classes is typically denoted Domain Classes (information) and Service Classes (that act on that information.)This scales extremely well in all sorts of contexts.

    I would never dare to contradict Ivar Jacobssen, but not everybody agrees about the need of a complete separation. See Bill Schneider's comment on the Anemic Domain Model antipattern (this term was introduced by Martin Fowler) in the pattern section.
  77. On the contrary I find Bram's post interesting, fresh and stimulating. And will almost certainly try it out.

    If we compare with the real world, for example maintainance of home electronic, we see that the tv-repairman does not try to find out the exact failure anymore. As soon he pinpoints the module where the problem originates he just remove the whole module and replace it with a new.

    A good software system can be compared to a bookshelf, with modules instead of books. The bookshelf is build with the full power of OO. But the components however are better build as black boxes, depending upon nothing. The only sane way to build large systems is by self-Autonomous modules IMO. Even if it means some duplication of code. You are free to use OO inside the component of course.

    And that, my gentemen is what is wrong with with OO today. Confusning of the "bookshelf" with the "books".
    The "shift" you talk about is actually how Ivar Jacobsen (a OO guru from the 70'ies) described how OO was meant to be used.

    Perhaps you can give us some links so we others too can see what Ivar Jacobsen really said?

    Regards
    Rolf Tollerud
  78. See Bill Schneider's comment on the Anemic Domain Model antipattern (this term was introduced by Martin Fowler) in the pattern section.

    that's interesting, I didn't know this programming practice was disputed as an antipattern. I found this comment on Fowlers article. What is interesting is that what I see as an advantage is quoted here as a disadvantage: Fowler claims that this turns development back into a procedural model, with the application layer providing all of the procedures that operate on the domain model data structures; and that this flies in the face of a founding tenet of object oriented development - namely, the joining together of data and process.
    I tend not to agree with that: a separation of code in domain and service classes results in code that is easier to
    recombine or adapt in new ways. Encapsulation is not broken, only unnecessary coupling between unrelated responsibilities is avoided.
  79. In this style of programming I use a lot less inheritance and polymorhism in favour of composition/aggregation and interfaces. Also, you could say that the POJO's play the role of structs in procedural programming, and the second kind of classes the role of procedures. I am convinced now that this leads to code that is easier to understand an reuse than "classic" OO modelling.To conclude this, I think OO programming is swinging back to procedural programming, but as a "next generation" approach to procedural programming in an OO way.

    Using aggregation and composition has always been preferred over Inheritance, in addition POJO is not something new, the term might be new(coined by Fowler) however the definition refer to object in its classic style compared to EJB and other enterprise components.
    To conclude this, I think OO programming is swinging back to procedural programming, but as a "next generation" approach to procedural programming in an OO way.
    NO we aren't swinging back to procedural programming, in contrast, we swift toward aspect oriented programming!
    so catch up before it's too late
  80. Using aggregation and composition has always been preferred over Inheritance

    No it hasn't. Inheritance is not always appropriate, but it is a vital part of OOP. It is just not always used well.
  81. Using aggregation and composition has always been preferred over Inheritance
    No it hasn't. Inheritance is not always appropriate, but it is a vital part of OOP. It is just not always used well.

    The introduction to the GoF book about patterns points out that extension by delegation should be preferred over extension by inheritance if you want to make your code reusable. Gamma does not, however, discourage inheritance totally. And in fact a well designed system should use both inheritance and delegation.
    See Bill Schneider's comment on the Anemic Domain Model antipattern (this term was introduced by Martin Fowler) in the pattern section.

    that's interesting, I didn't know this programming practice was disputed as an antipattern. I found this comment on Fowlers article. What is interesting is that what I see as an advantage is quoted here as a disadvantage: Fowler claims that this turns development back into a procedural model, with the application layer providing all of the procedures that operate on the domain model data structures; and that this flies in the face of a founding tenet of object oriented development - namely, the joining together of data and process.
    I tend not to agree with that: a separation of code in domain and service classes results in code that is easier to
    recombine or adapt in new ways. Encapsulation is not broken, only unnecessary coupling between unrelated responsibilities is avoided.

    Clarification: I was just quoting Fowler's opinion, not saying he's totally right. I tend to prefer logic-rich domain classes and a thin service layer, but there are cases that make the reverse preferrable. In an (ugly) application that I designed for IBM Italy back in 2000, where we had servlets but not EJBs, I designed a layer of logicless domain objects that acted also as Data Transfer Objects and were fed to VisualAge-generated DAOs. Later, another architect complained that logic should be in the objects themselves (I hated the architect almost as wholeheartedly as I despise this Richard Mansfield guy but I could not disagree with him on this subject). Then, to add business logic to the "anemic" model, I designed a Decorator for each domain object that added behaviour to the dumb DTO. The decorator was just discarded when the DTO was sent to the presentation layer for rendering. Just a compromise between the two approaches, and an example of using non-inheritance extension: had I used inheritance, the objects should have been duplicated for use in the presentation layer, since in the decorated form they had the capability to write to the database.

    Sadly, this design was too complicated for the development team, and as it was not me that supervised the final stages of the project, it was not used in fact. Well, this urges me to agree with the general consensus on "it is usage of OOP by unexperienced people that makes it unefficient".
  82. (snip)
    Clarification: I was just quoting Fowler's opinion, not saying he's totally right. I tend to prefer logic-rich domain classes and a thin service layer, but there are cases that make the reverse preferrable. In an (ugly) application that I designed for IBM Italy back in 2000, where we had servlets but not EJBs, I designed a layer of logicless domain objects that acted also as Data Transfer Objects and were fed to VisualAge-generated DAOs. Later, another architect complained that logic should be in the objects themselves (I hated the architect almost as wholeheartedly as I despise this Richard Mansfield guy but I could not disagree with him on this subject). Then, to add business logic to the "anemic" model, I designed a Decorator for each domain object that added behaviour to the dumb DTO. The decorator was just discarded when the DTO was sent to the presentation layer for rendering. Just a compromise between the two approaches, and an example of using non-inheritance extension: had I used inheritance, the objects should have been duplicated for use in the presentation layer, since in the decorated form they had the capability to write to the database.Sadly, this design was too complicated for the development team, and as it was not me that supervised the final stages of the project, it was not used in fact. Well, this urges me to agree with the general consensus on "it is usage of OOP by unexperienced people that makes it unefficient".

    This is an internal debate I've had for quite some time myself. "Pure" DTO classes smack of structures rather than objects. My first (OO) love is Java, but the last 1.5 years I've been doing C#, and I found one feature that helps me with this problem. the "internal" keyword. It states that anything within the current assembly (Microsoft's equivalent of "Jar") can see this method or property, but nothing outside can see it.

    With this, create a "solution" with a view assembly, business logic (domain model) assembly, and a DAL/DAO assembly. Note that I don't have to deal with view and model being deployed on separate systems. My domain objects can now contain operations that rightfully belong with them, but the "client side" code cannot access them. I use service classes largely as facades that delegate to the domain objects and handle those operations for which I've not yet clearly identified a proper home. These then act as a cheat-sheet to which operations the client needs to see.

    You can get the same effect with Java's "protected" keyword, but that only works within a single package.

    As most of us here understand, OOP is a tool of organization that helps when used properly. If it isn't appropriate, don't use it. The trick is having the sense to know when it is appropriate, and that takes experience or a good mentor. It's pretty obvious the author of the article that started this has an axe to grind.

    --
    David
  83. NO we aren't swinging back to procedural programming,

    Of course. I just wanted to say that I discovered that isolating a responsibility or behaviour of a class in a seperate class can have advantages. I started experimenting with this when I joined a project that had maintenance problems with the domain model. for example, every domain model element "knew how to read/write itself from/to XML". when they had to support a second XML format for the model, they were stuck. Same problem with calculations they had to do on the model: when the customer asked to support several algorithms at once, the model became completely littered with methods. The GoF provided several patterns to get out of this mess, and later I found out that those patterns could be explained by one meta-pattern: SRP.
    in contrast, we swift toward aspect oriented programming!so catch up before it's too late

    In fact, if you program using composition iso inheritance, you get a lot of what AO promises for free by using a simple adapter. Say you want to add typical AO behaviour to a method like logging, security, pooling, etc..
    if your service class comes from a factory, it is easy to add code in the factory to wrap the service classes in classes that add e.g. security.
  84. Using aggregation and composition has always been preferred over Inheritance
    So why is there no sytactic support in mainstream OO languages for delegation? "Manual" delegation is so verbose that progammers naturally shy away from it. Kinda like inheritance in C...
    NO we aren't swinging back to procedural programming, in contrast, we swift toward aspect oriented programming!so catch up before it's too late
    How much KLOCs of AspectJ have you written yet?
  85. How much KLOCs[ Go to top ]

    How much KLOCs of AspectJ have you written yet?
    Not a "Kilo" yet ☺
    Using OOP or AOP u don’t need to measure your program using "KLOCs", that metric is meaningless in OO paradigm and is not used any more!
    You have to write number of modular and smart "Object" or "Advice", that's all.
    I
  86. I recently had a shift in how I see the role of objects and classes. When I started with OO (in my c++ days) I was told that classes were models for concepts of the "real" world. In this way of doing OO I wrote "heavy" classes with lots of attributes and methods. Also I tended to use a lot of inheritance and polymorphism. Today (in java) I look at objects in a different way: since I experimented with ideas from XP and Spring framework I started to use SRP (Single Resposibility Principle) style of programming. The result is that I have 2 kinds of classes. The first kind are POJO's. They are still fulfilling the role of modelling the "real" world, but have only methods related to the responsibility of building up a datastructure (setters, addXYZ methods) and navigating (getters). The second kind are classes that derive a functionality from one or more POJO's. In this style of programming I use a lot less inheritance and polymorhism in favour of composition/aggregation and interfaces. Also, you could say that the POJO's play the role of structs in procedural programming, and the second kind of classes the role of procedures. I am convinced now that this leads to code that is easier to understand an reuse than "classic" OO modelling.To conclude this, I think OO programming is swinging back to procedural programming, but as a "next generation" approach to procedural programming in an OO way.

    I find it stunning how often the term POJO is used to describe a JavaBean.
    !(POJO instanceof JavaBean) && (JavaBean instanceof POJO)
  87. Cool Joke[ Go to top ]

    There are plenty of retards like this dude, however they're scared to point out their stupid ideas so explicit like this one.
    The article is rubbish in any aspect and provides wrong information for naïve readers.

    He is definitely not good at OOP , however his sense of humor is pretty good, I suggest to TSS to use this kind of stuff in the cartons and jokes section of the site.
  88. I agree but ...[ Go to top ]

    I agree with the observation of over enthusiasm (see my blog entry on the subject http://blogs.msdn.com/chris.green/archive/2004/11/08/253734.aspx ) but I think you miss an important point. OOP is the best metaphor we have for managing complexity. That's why it suited modeling and simulation so well. Once defined objects become autonomous in operation and self contained in terms of code maintenance. Our enemy in OOP is inheritance - it actually adds complexity. Our recent adoption of aggregation in place of inheritance seems to have addressed this short coming adequately.
  89. I agree but ...[ Go to top ]

    Our enemy in OOP is inheritance - it actually adds complexity. Our recent adoption of aggregation in place of inheritance seems to have addressed this short coming adequately.

    OOP is nothing without inheritance. It is the key feature that allows extension of existing code. Inheritance badly used leads to complexity.
  90. I agree but ...[ Go to top ]

    Hey, where has good old common sense gone? :)

    I've got a feeling also: programming is a technical field but also bases heavily on creativity, so just like painting or thinking in 3D spaces, some people have a greater innate talent for that. In the end there will always be this "elite" of programmers for who programming is almost a natural thing, and others which will always struggle at each coding effort.

    Regards,
    Henrique Steckelberg
  91. the third factor[ Go to top ]

    Perhaps we can agree at least that there is a fine line between inheritance/ polymorphism and composition/ aggregation to decide for each situation.

    But the problem is, that the Java developer not only think of "what is right for this project and customer" but also "Now I Must Show How Much Better I Am Than The Avarage MS Programmer" and therefore never get it right. ;)

    (Vic Cekvenich excepted of course).

    Regards
    Rolf Tollerud
  92. the third factor[ Go to top ]

    But the problem is, that the Java developer not only think of "what is right for this project and customer" but also "Now I Must Show How Much Better I Am Than The Avarage MS Programmer" and therefore never get it right. ;)(Vic Cekvenich excepted of course).RegardsRolf Tollerud
    Rolf, your flamebaits used to be more subtle... this one is so obvious it isn't even funny to start another flamewar... :)
  93. the third factor[ Go to top ]

    Perhaps we can agree at least that there is a fine line between inheritance/ polymorphism and composition/ aggregation to decide for each situation.

    Absolutely.
    But the problem is, that the Java developer not only think of "what is right for this project and customer" but also "Now I Must Show How Much Better I Am Than The Avarage MS Programmer" and therefore never get it right. ;)(Vic Cekvenich excepted of course).RegardsRolf Tollerud

    Why do you ruin it all with nonsense like this? Exactly the same design choices apply with Java as with C# or VB.Net - the languages are all very similar and similar object designs can be used. It's nothing at all to do with Microsoft.
  94. 1st April joke?[ Go to top ]

    I just hope this article is a 1st April joke ahead of time...
  95. This is a true statement. But OOP in practice is pretty darn good.
  96. Lets try... Copy-Paste[ Go to top ]

    Lets see if I can program using the Copy-Paste technology...
    Copy-Paste I
    Copy-Paste D
    Copy-Paste I
    Copy-Paste O
    Copy-Paste T
    Yeah!! it works! ;)
  97. Cette histoire ressemble à un essaie sociologique. Sur la communauté des stars d’objet et d’autres NTIC.
    A part quelque voix raisonnables, le reste me fait penser à une meute des chiens qui ne savent qu’aboyer.

    Pépé était peut-être assez maladroit dans sa façon de parler de « copier – coller » comme un moyen de réutiliser le code. C’est le seul reproche « théorique » qu’on puisse lui faire. Et encore !

    Il y a eu même des plantes concernant le temps soi-disant perdu lors de la lecture de l’article de Richard Mansfield. Effectivement le public concerné est toujours très pressé. Il n’aime pas de passer plus de 30 secondes sur un sujet.

    Bon. Je ne suis pas un fan de Bill Gates et VB me file des boutons. On reproche à pépé son incapacité de dépasser le niveau de VB6 pour comprendre VB.NET. J’me suis donné la peine de jeter un coup d’œil sur la liste des livres de Richard Mansfield en vente par www.amazone.fr. Il y en a parmi eux assez récents. Celui-là par exemple (écrit, il est vrai, pas que par lui) « Visual Basic .Net Power Tools » (2003). Voici la table de matière publiée par amazone.
    *************************************************
    Chapter 1: Understanding the .NET Framework
    Chapter 2: New Ways of Doing Traditional Jobs
    Chapter 3: Serialization Techniques
    Chapter 4: Leveraging Microsoft Office in Your Applications
    Chapter 5: Understanding .NET Security
    Chapter 6: Encryption, Hashing, and Creating Keys
    Chapter 7: Advanced Printing
    Chapter 8: Upon Reflection
    Chapter 9: Building Bug-Free and Robust Applications
    Chapter 10: Deploying Windows Applications
    Chapter 11: Building Data-Driven Web Applications
    Chapter 12: Peer-to-Peer Programming
    Chapter 13: Advanced Web Services
    Chapter 14: Building Asynchronous Applications with Message Queues
    Chapter 15: Practical ADO.NET
    Chapter 16: Building Middle-Tier Components
    Chapter 17: Exploring XML Techniques
    Chapter 18: Designing Data-Driven Windows Applications
    Chapter 19: Working with Regular Expressions
    Chapter 20: Advanced Graphics
    Chapter 21: Designing the User Interface
    Chapter 22: Using the .NET Compact Framework and Its Emerging Technologies
    *************************************************
    Bien sûr je ne sais pas ce qu’il se trouve à l’intérieur de cette table de matière et bien sur je ne vais jamais ni acheter ni lire ce bouquin. Néanmoins, sauf le cas hypothétique dans lequel il n’y a que des buzzleword là-dedans, reconnaîtrons que Richard Mansfield ne peut pas être une espèce de coboliste - assambleuriste récalcitrant sortant d’époque quand les ordinateurs étaient plus grands que des maisons.
    Autre chose. A la fin de son article, l’auteur donne un lien sur je cite "...excellent website de Mr. B. Jacobs...". Dans le chœur de ces défenseurs excités de OOP, je n’ai pas remarqué un seul commentaire là-dessus. Pourtant ça mérite d’être lu ou au moins vu. Les gus de java, ça bosse dur, ça transpire. Ca participe évidemment dans des projets OOP-UML-AOP- « software factory/usine à gase » de 10000 jours/homme qui se cassent périodiquement la gueule. C’est normal qu’ils défendent en block toutes les attentes à leur tranquillité mentale.
    C’est bien de réfléchir de temps à autre sur de véritables raisons d’abandon par java d’héritage multiple, sur des errances d’intellectuels du dernier siècle dans des eaux troubles des relations is-a et has-a, sur le nouveau né de « dépendency injection » (niveau d’excitation dans la salle qui fait péter les compteurs : Patriiiiic je t’aime – ceci est pour les français), pourquoi pas, encore une fois sur impedance mismatch entre objet et relationnel ou enfin sur le positionnement de AOP par rapport à OOP - remplaçant, complément ou boucheur de trous…
  98. Consider the profound contradiction between the OOP practices of encapsulation and inheritance. To keep your code bug-free, encapsulation hides procedures (and sometimes even data) from other programmers and doesn't allow them to edit it. Inheritance then asks these same programmers to inherit, modify, and reuse this code that they cannot see—they see what goes in and what comes out, but they must remain ignorant of what’s going on inside. In effect, a programmer with no knowledge of the specific inner workings of your encapsulated class is asked to reuse it and modify its members.

    And this is bad because?
    Why would I want to know how JComboBox or JButton work if I want to use them? I don't care how Sun implemented it, I just want to draw the damn button, is that too much to ask for? Dick, are you listening?
  99. Having read the article, it seems to me the author is a man that the world has left behind. He is desperately trying to prove his knowledge still has value. Like an auto mechanic preaching the superiority of a Carburetor (easy to work on), when the rest of us have move on to computer controller fuel injection. Or an elevator operator, longing for the days of full employment. In Software, like nature, if you don’t evolve with your environment would you will end up as a nitch species, only able to survive in specialize surroundings.
  100. Wow, have you programed before? I and other people have doubts....
    http://www.theserverside.com/news/thread.tss?thread_id=31439
    He responded:
    Aleks,

    Thank you for pointing out to me the nest of excited Java enthusiasts, and
    their reaction to my little opinion piece about OOP. I had serious space
    restrictions to deal with, so I'm afraid some of my points were not as
    clearly explained as I would have liked. A number of people have
    misunderstood my observation that inheritance can conflict with
    encapsulation. I don't mean "inheriting" mere components like buttons, or
    for that matter using procedures or classes embedded within compiled
    libraries. That's a very restrictive definition of inheritance. Inheritance
    in OOP has a far more significant, and I think often damaging, role to play
    in much OOP programming.

    The key to my idea is my phrase in the article: "modify its members." As I
    point out, you don't normally modify the methods of a button--you just use
    the methods as they were originally intended to be used. That's not a
    modification, nor is it inheritance coupled with polymorphing, which is what
    OOP means by the term.

    I'm puzzled why you refer to me as Dick, though I'm certain you meant it in
    a friendly way. I never go by "Dick."

    Anyway, thanks again for inviting me to peek into the room of very excited
    Java people.

    Best, Richard

    End of transmission.........
  101. Richard,

    You know by now that the members of Java TSS never give their opponent the benefit of assuming that he is a intelligent mature individual with normal reason, logic and common sense. They never read between the lines and never understand what is only implied. After all they are engineers!

    Instead they excell in calumny - malicious deliberate misrepresentation. Inheriting from JComboBox or JButton! ;) As if that was what you meant. It is so low it is possible to go.

    Regards
    Rolf Tollerud
  102. Ok let's extend from JTextField...
  103. I forgot![ Go to top ]

    Furthermore it is my view that in the J2EE world you do not differ between Objects, Components or web-Services
  104. I forgot![ Go to top ]

    but who does?
  105. Allright, all extreme comments aside. What would someone think reaction of the readers would when writing an article titled
    'OOP Is Much Better in Theory Than in Practice'? I for example thought that all the time I've spend understanding all the damn objects, classes, private, protected and abstract concepts are useless since I don't need all of that. I can write not so complex programs using procedural step-by-step way of thinking. But guess what? It does not work like that. Example. At my work I had a project to build a flat-file based application that would create database maintenance fields. Another programmer had a project to write application that would be also flat-file based but create reporting screens that run shell scripts from UNIX file system and display results in JSP page. I decided to do it the right way -- MVC, the other programmer didn't think it was a good idea because too much time would be needed to implement MVC for this application and went with Model 1 page to page processing. Guess what? It took me 3 weeks to write the application, the other programmer 2 weeks. But, mine is scalable because I can easily change the behavior of the program by modifying Action classes and create sub-applications by extending from my model classes. The other programer? After trying to make sense between at least 7 jsp pages manager found the program unmanagable and told me to rewrite it. On the base of my application I changed it in under a week. Point in case -- reusable, well written code is much better than bunch of code tied together with nothing.
    One more thing. Almost everything that a human being built reflect nature. Nature is a hint on how to do it write. OOP is how life works.
  106. agh...on my one before last reply it's database maintenance screens and not database maintenance fields....sorry
  107. edit posts[ Go to top ]

    I should really be able to edit my origianl post and not write extra post on original post's edits.
  108. Alexander,

    I know you are an engineer and as such probably a social analphabet but why don't you try to extract the meaning of the original article? Hint: The title is deliberately provocative like Miguel de Icaza in his opening keynote speech at the Ottawa Linux Symposium. You do not think that Icaza thinks that "Unix sucks" do you?

    If you tentatively assign normal intelligence and discernment to the fellow citizens maybe you can find out what he really means! Take it as an exercise. You must train your social skills precisely as you must do train your ordinary muscles you know. And if you do, who knows, maybe one day you even find the courage to address a girl!

    Regards
    Rolf Tollerud
    (Furthermore it is my view that in the J2EE world you do not differ between Objects, Components or web-Services)
  109. I am not going to reply to any comments in this thread anymore. Not because I have nothing to say, but because it waists time for people who are trying to load the page (99 replies). So, Mr. Tollerud if you want to continue on improving my social skills and further discuss this topic you can e-mail me. Clearly this is no longer a good place to discuss this since this is way off the topic. Was this English good enough for ya?
  110. Alexander,I know you are an engineer and as such probably a social analphabet but why don't you try to extract the meaning of the original article? Hint: The title is deliberately provocative like Miguel de Icaza in his opening keynote speech at the Ottawa Linux Symposium. You do not think that Icaza thinks that "Unix sucks" do you?If you tentatively assign normal intelligence and discernment to the fellow citizens maybe you can find out what he really means! Take it as an exercise. You must train your social skills precisely as you must do train your ordinary muscles you know. And if you do, who knows, maybe one day you even find the courage to address a girl!RegardsRolf Tollerud(Furthermore it is my view that in the J2EE world you do not differ between Objects, Components or web-Services)
    You know, it's a cute thing you are defending the original author of the article (well, excluding public insulting other people, as you said you never did besides Cameron). Maybe this way he won't feel so alone stuck in the past, having such a nice company as you. May leagues of OOP-ignoring VB programmers join him, and party like it's 1999! Well, at least until they realize that 1999's already gone too... :)

    Regards,
    Henrique Steckelberg
    (Furthermore it is my view that in MS world they have to repeat things until either people start believing it, or die of boredom)
  111. "excluding public insulting other people, as you said you never did besides Cameron"

    Well I am sure he feels good being elevated to such noble and lofty company!

    My opinion is that Richard is pulling a joke on us. He probably feels that unnecessary abstractions, factories, proxies, managers, visitors, builders, adapters, bridges, composites, decorators, facades, flyweights, interpreters, mediators, observers, etc etc ad infinitum is a little overkill on the for the mostly part simple business run-of-the-mill projects of the day, therefore he exaggerate in the other direction.

    Regards
    Rolf Tollerud
  112. He probably feels that unnecessary abstractions, factories, proxies, managers, visitors, builders, adapters, bridges, composites, decorators, facades, flyweights, interpreters, mediators, observers, etc etc ad infinitum is a little overkill on the for the mostly part simple business run-of-the-mill projects of the day

    To my amazement I find myself agreeing with you Rolf. I find this bewildering mass of patterns largely pointless. I think it can get in the way of the art of coding. There are a few terms (such as Singleton and Proxy) which are useful to allow the communication of ideas, but I'm seriously expecting someone to come up with the 'call a method' pattern or the 'add 1 to a number' pattern. For decades we have been developing software by just sitting down and writing it. Now we are expected to have knowledge of tens (hundreds? thousands?) of patterns, and when each is appropriate. I think the use of patterns has grown wildly out of proportion.
  113. I think the use of patterns has grown wildly out of proportion.

    "Over-ingenieering" is what I heard this fenomena being called. I agree with you, but I also think that the problem does not arise from the usage of patterns; that could hardly be a wrong approach. Loathing the use of patterns means you like to reinvent the wheel for every project.
    I believe there are two main problems regarding patterns and their usage:

    - Trying to apply a pattern to a solution, regardless it's needed or not. I see this every day; says the architect: "coulnd't we somehow use an Observer here?". Weird... Patterns should be used when the problem they attack surfaces in your design, not the other way around.
    - Poor, non-reusable pattern implementations. I must confess that I recode Service Locator for every project. Some day I'll get tired of this and come up with a reusable "something" (component, library, framework, bare class). GoF patterns are TRUE patterns, IMO; the so-called J2EE Core patterns are more design than patterns ;). Of course, reusing a solution does not mean you MUST reuse the code, but it would be great to reuse both. With some patterns you can do this, with others not.

    My humble opinion is that the average programmer considers that applying a pattern means reimplementing it, and that architects (architect as a role) tend to overuse patterns even when there's no need.

    Cheers and happy coding,
    Martin
  114. I think the use of patterns has grown wildly out of proportion.
    "Over-ingenieering" is what I heard this fenomena being called. I agree with you, but I also think that the problem does not arise from the usage of patterns; that could hardly be a wrong approach. Loathing the use of patterns means you like to reinvent the wheel for every project.

    I agree. I don't think all pattern use is wrong, I just have a feeling that any quality developer should already know these patterns and be using them, and does not need them named or classified. My personal attitude is that anyone who actually needs to be told how to use most of the patterns is worryingly inexperienced, and other developers already know this anyway, so what is the point? Making money writing books and articles stating the obvious?

    I exaggerate a little for effect, but this is my opinion.
  115. Yes indeed, the "mass" of design patterns can be confusing, especially for those who are just starting (what to do? where to begin?). And of course, OOP can be felt as overkill, each time you code something for the first time.

    Maybe this could help you: don't see patterns as something that tells you how to code OO, but as something that shows you how to organize your code. There is a subtil difference.

    When explaining an architecture (using patterns) to our customers (non-engineers, managers and such) some react with "Geez, we don't need that complexity!, there's too much code!, it's going to cost too much!...". Human.

    Then I explain to them, with a serene voice, that:
    1) patterns do not increase code quantity (="work"), that quantity stays mostly the same, it's simply better organized, thus allowing them to have us easily add new features in the future, and, as a bonus, without the kind of headaches their unorganized projects have been giving them until now,
    2) in some cases patterns even reduce code quantity (="work")
    3) thanks to the use of these patterns, large portions of the application have already been coded by us and put in "libraries" (aka jar files) for re-use in each new application, thus lowering the overall cost of developpemt as a matter of fact.

    Then they say "Oh, we thought it would cost more than VB and that you'd have to create the application from scratch...", and we say with a smile: "Well, don't tell anyone!"
    Design patterns helped us factor out so much code that writing each complete new J2EE application has become an industrial process. We leave the "Art" part to our graphics designer, you know him, the guy that uses Photoshop and Dreamweaver.

    To me, "OOP" means "re-use" means "less work" means "less headaches" means "earlier home" means "happier me".
    To our customers, "OOP" means "re-use" means "less work" means "less money spent" means "happier managers and share-holders"

    All thanks to OOP and Design Patterns, in the end, everyone's happier (except our competitors): what a joyful world it is ;)
  116. Yes indeed, the "mass" of design patterns can be confusing, especially for those who are just starting (what to do? where to begin?). And of course, OOP can be felt as overkill, each time you code something for the first time. Maybe this could help you: don't see patterns as something that tells you how to code OO, but as something that shows you how to organize your code.

    I'm not starting out - I'm about to reach my 30th year of coding! My point is that a lot of these patterns are nothing more than labelling the extremely obvious. I have been coding using OOP for 20 years, and I have been happily using Proxies, Service Locators, Factories etc. for most of that time without anyone needing to tell me about those patterns. I think patterns are useful as a description of these approaches; a shorthand for communication - but I worry that they becoming something more - they are formalising things that need not be formal. I can imagine a situation where if you don't code to one of these patterns your code will be considered inferior or badly engineered. I can imagine new coders sitting with a large book of patterns trying to figure out which to use rather than just getting on and coding.

    I worry that excessive reliance on patterns restricts skills. Its like giving a painter a fixed pallette of colours rather than letting them mix their own.
  117. I have been coding using OOP for 20 years, and I have been happily using Proxies, Service Locators, Factories etc. for most of that time without anyone needing to tell me about those patterns.

    I know what you mean, for years I did 'refactoring' without knowing it was called that. I just called it cleaning up my code. ;-)

    -Pete
  118. how many patterns exist?[ Go to top ]

    AbstractCore AbstractFactory ActiveRecord Adapter Aggregates Aggregator AnticorruptionLayer ApplicationController ApplicationManagedDataCopies Assembler Assertions AssociationTableMapping BoundDataControl BoundedContext Bridge Broker CanonicalDataModel CaptureTransactionDetails ChannelAdapter ChannelPurger ClaimCheck ClassTableInheritance ClosureOfOperations CoarseGrainedLock CohesiveMechanisms CommandMessage Commands CompetingConsumers ComposedMessageProcessor ConceptualContours ConcreteTableInheritance Conformist ContentBasedRouter ContentEnricher ContentFilter ContextMap ContinuousIntegration ControlBus CoreDomain CorrelationIdentifier CustomerSupplierDevelopmentTeams DataIntegration DataMapper DataReplication DataTransferObject DatatypeChannel DeadLetterChannel Decorator DependentMapping DeploymentPlan Detour DirectBroker DistributedObjectIntegration DocumentMessage DomainModel DomainVisionStatement DurableSubscriber DynamicRouter EmbeddedValue Entities EntityAggregation EnvelopeWrapper EventDrivenConsumer EventMessage EvolvingOrder ExtractTransformLoad Facade Factories FailoverCluster FileTransfer ForeignKeyMapping FormatIndicator FourTieredDistribution FrontController FunctionalIntegration Gateway GenericSubdomains GuaranteedDelivery HandsOnModelers HighlightedCore IdempotentReceiver IdentityField IdentityMap ImplementingBrokerWithNETRemotingUsingClientActivatedObjects ImplementingBrokerWithNETRemotingUsingServerActivatedObjects ImplementingDataTransferObjectInNETWithADataSet ImplementingDataTransferObjectInNETWithATypedDataSet ImplementingDataTransferObjectInNETWithSerializedObjects ImplementingFrontControllerInASPNETUsingHTTPHandler ImplementingGatewayWithHostIntegrationServer ImplementingInterceptingFilterInASPNETUsingHTTPModule ImplementingMasterMasterRowLevelSynchronizationUsingSQLServer ImplementingMasterSlaveSnapshotReplicationUsingSQLServer ImplementingMasterSlaveTransactionalIncrementalReplicationUsingSQLServer ImplementingMessageBrokerWithBiztalkServer ImplementingModelViewControllerInASPNET ImplementingMVCWithUIP ImplementingObserverInNET ImplementingPageCacheInASPNETUsingAbsoluteExpiration ImplementingPageControllerInASPNET ImplementingPipesAndFiltersWithBiztalkServer2004 ImplementingProcessIntegrationWithBiztalkServer2004 ImplementingPublishSubscribeWithBizTalkServer ImplementingServiceGatewayInNET ImplementingServiceInterfaceInNET ImplementingServiceOrientedIntegrationWithASPNET ImplementingServiceOrientedIntegrationWithBizTalkServer2004 ImplementingSingletonInCSharp ImplicitLock IndirectBroker InheritanceMappers IntentionRevealingInterfaces InterceptingFilter InvalidMessageChannel KnowledgeLevel LayeredApplication LayeredArchitecture Layers LayerSupertype LazyLoad LoadBalancedCluster MaintainDataCopies Mapper MasterMasterReplication MasterMasterRowLevelSynchronization MasterSlaveCascadingReplication MasterSlaveReplication MasterSlaveSnapshotReplication MasterSlaveTransactionalIncrementalReplication Mediator Message MessageBroker MessageBus MessageChannel MessageDispatcher MessageEndpoint MessageExpiration MessageFilter MessageHistory MessageOrientedMiddlewareIntegration MessageRouter MessageSequence MessageStore MessageTranslator Messaging MessagingBridge MessagingGateway MessagingMapper MetadataMapping ModelDrivenDesign ModelViewController Modules Money MonoState MoveCopyofData NamingService Normalizer Observer OpenHostService OptimisticOfflineLock PageCache PageController PageDataCaching PageFragmentCaching PartitionedSingleSolutionPartitioning PessimisticOfflineLock PipesAndFilters PluggableComponentFramework Plugin PointToPointChannel PollingConsumer PortalIntegration PresentationAbstractionController PresentationIntegration ProcessIntegration ProcessManager Proxy PublishedLanguage PublishSubscribe PublishSubscribeChannel QueryObject RecipientList RecordSet Registry RemoteFacade RemoteProcedureInvocation Repositories Repository RequestReply Resequencer ResponsibilityLayers ReturnAddress RoutingSlip RowDataGateway ScatterGather SegregatedCore SelectiveConsumer SeparatedInterface SeparateWays SerializedLOB ServerClustering ServerFarm ServiceActivator ServiceGateway ServiceInterface ServiceLayer ServiceOrientedIntegration Services ServiceStub SharedDatabase SharedKernel SideEffectFreeFunctions SingleSolutionPartitioning SingleTableInheritance Singleton SmartProxy SpecialCase Splitter StandaloneClasses Strategy SystemMetaphor TableDataGateway TableModule TemplateMethod TemplateView TestMessage ThreeLayeredServicesApplication ThreeTieredDistribution TieredDistribution TransactionalClient TransactionScript TransformView TwoStepView UbiquitousLanguage UnitOfWork UtilityComponent ValueObjects Visitor WireTap

    Just a humble start. From MS new site,
    http://www.patternshare.org/

    Regards
    Rolf Tollerud
  119. how many patterns exist?[ Go to top ]

    AbstractCore AbstractFactory ActiveRecord Adapter Aggregates Aggregator AnticorruptionLayer ApplicationController ApplicationManagedDataCopies ...
    Just a humble start. From MS new site,http://www.patternshare.org/RegardsRolf Tollerud

    Well, I certainly never saw a design pattern with a name like "ImplementingProcessIntegrationWithBiztalkServer2004" before!

    In my humble opinion, the English language has way to many word names for me to deal with too. Just gimme a sec for me to grab my Cambridge english dictionary and post its entire content...
  120. how many patterns exist?[ Go to top ]

    I wonder if we can call this the
    'Pattern Pattern'?

    -Pete
  121. I mostly agree with you. I'm sorry if I offended you in any way, my post was merely aimed at the general public, not at you personally. I could not know you've been coding for twice as long as me :)

    We humans like to name things, don't we. We started out naming things a very long time ago, living things, non-living things, then came the ideas and concepts. As we learned to think by abstraction, we certainly felt the need to refine our language.
    Naming things we know, and using these names to learn things we don't know is what we've always done.

    But I don't think that it induces a restrictive behaviour and this thread is the very proof: people react, argue, disagree about anything and everything. Many consider themselves as artists in their own way (is coding an art-form? maybe that's why many don't like the whole idea of an industrial aproach of coding). I trust that people will only take the patterns for what they are, and let their true skills burst out in other ways.

    That reminds me of discussions I had about UML: "how much UML do you talk?". Frankly, how many people (colleagues, friends, relatives) do you know of who really use (let alone "master") the "full" spectrum of UML schemas? I think I can quite safely assume the answer is "none".

    Well, I think the same is true for design patterns. The hype will go away just as it did for other things and patterns will become yet another ordinary tool. (hey, I see a pattern in this statement ;)

    I wouldn't worry if a freshman applied for a job and I discovered during the interview that he didn't know how to spell "service locator". I would worry however if the guy claimed to have tens of years of experience and still didn't know what it means. That would mean he had no interest in what's going on "out there" during all those years (when doing Java, patterns is not something one could have overlooked). He might as well be an excellent programmer, but who wants to hire someone who seems to be close-minded.

    As I said before, to me patterns are means to communicate and organize, more than they are means to code. I would not know how to run a business in a unorganized fashion and without communicating.
  122. I mostly agree with you. I'm sorry if I offended you in any way, my post was merely aimed at the general public, not at you personally. I could not know you've been coding for twice as long as me :)

    I didn't take offense - I was just trying to indicate why I had this attitude.
    But I don't think that it induces a restrictive behaviour and this thread is the very proof ... I trust that people will only take the patterns for what they are, and let their true skills burst out in other ways.

    I think you are being optimistic. My experience is that there are a large number of incompetent IT project managers who will leap at the chance to use any new technique to micro-manage developers, and I can imagine them gleefully handing out large books of patterns with the order to learn them.
    I wouldn't worry if a freshman applied for a job and I discovered during the interview that he didn't know how to spell "service locator". I would worry however if the guy claimed to have tens of years of experience and still didn't know what it means. That would mean he had no interest in what's going on "out there" during all those years (when doing Java, patterns is not something one could have overlooked).

    Yes, but I would not expect that simply learning a label for something he/she had been doing for years would have helped him/her in any way.
    I would not know how to run a business in a unorganized fashion and without communicating.

    Developers have been successfully organising and communicating for decades before Patterns appeared.

    I think a basic set of patters are useful, the situation pointed out by Rolf above at the patternshare.org site which includes patterns such as 'Implementing Master Master Row Level Synchronization Using SQL Server ' is madness. (Who would have thought that people could come up with MS-specific patterns?)

    I am tempted to set up a parody site with entries such as 'integerVariable' and 'openAPostgreSQLDatabaseWithJDBCAndWriteOutACSVFileForImportIntoMSAccess95'
  123. Flamebait -1[ Go to top ]

    I can't believe everyone has been sucked into this obvious flamebait.

    It's so funny that it reads like an article on adequacy.org.

    My favourite, besides the comment about the ground breaking CutNPaste pattern, is where he mentiones OOP in the same sentence as Marxism and his reference to "final best solutions" implies Nazism.

    Also, where he says:
    For example, people think of addition as 2 + 2, but a computer stack might work faster if its programming looks like this: 2 2 +. Programmers describe it as little Ashley's first birthday party: the computer starts counting from zero, so to the machine it's her zeroth birthday party.

    and the use of Ashley as a red herring is brilliant !

    Keep up the good work Richard!
  124. Thank you.

    But unfortunately every time in a thread when someone mentions nazism it abruptly ends! :)

    Regards
    Rolf Tollerud
    (Furthermore it is my view that in the J2EE world you do not differ between Objects, Components or Web-Services)
  125. My tuppence[ Go to top ]

    I found this interesting. I've been developing OO systems since I left uni nearly eleven years ago. So I havent done a great deal of procudural stuff. It did lead me to challenge one or two of my assumptions. But OO still holds good for me. Part of the problem was that the people who tried to sell OO to their managers had to use management-friendly arguments. These werent necessarily the main benefits of OO. You really have to learn the best ways to use OO, it doesnt just happen and a bad OO system is just as bad as any other. (Fighting with 8+ deep inheritance hierachies is just one example). The discussion doesnt really cover the power of polymorphism or all the good things that have come along to help us write OO code.
    One thing that did annoy me was the assertion that OO comes from GUI progamming which is TOTALLY incorrect. OO originated with Simula not Smalltalk. Xerox Parc/Smalltalk developed the first GUIs to help them do their OO programming not the other way round. GGRRR

    PS Keep up the good work TSS.
  126. My tuppence[ Go to top ]

    (Fighting with 8+ deep inheritance hierachies is just one example).

    There is nothing wrong with 8+ deep inheritance if it is appropriate (The Smalltalk collections hierarchy is a good example), especially if you have good browsing and refactoring tools.
    One thing that did annoy me was the assertion that OO comes from GUI progamming which is TOTALLY incorrect. OO originated with Simula not Smalltalk. Xerox Parc/Smalltalk developed the first GUIs to help them do their OO programming not the other way round. GGRRRPS Keep up the good work TSS.

    OO did not even originate with Simula - there were much earlier ideas. The point about Smalltalk is that it is a pure OOP language - even Simula was a hybrid Algol-like language. Smalltalk was always about far more than just GUI tools.

    It makes more sense to consider Smalltalk to be a parallel development of OOP, influenced by LISP and separate from the Algol/C-with-extensions language series represented by Simula, C++ and Java.
  127. My tuppence[ Go to top ]

    I think the you're being a little pedantic here. The point was that it is possible to write poor code using OO constructs. Deep nested inheritance hierarchies are, as a rule, a good example of this. There may well be exceptions but the rule holds good in the majority of cases.

    Also the point about Simula was just to show that OO concepts did NOT start with GUI programming or Smalltalk which the author of the article was suggesting. As far as I am aware Simula was the first programming language to include things such as inheritance and runtime binding and so it is credited with being the forerunnner of other OOP languages, but it doesn't really matter, does it?
  128. someone else's $0.02[ Go to top ]

    http://www.geocities.com/tablizer/oopbad.htm

    "Fact: OO fans have repeatedly failed to demonstrate OO superiority. They can talk up a good storm, but cannot walk their talk."

    (not my opinion but still an interesting read) after having to cleanup after $5/hr india programmers who doing "OO" programming i'll have to admit that procedural would be a better way to go in many instances... specifically where don't want to pay very much and you get what you pay for.
  129. +1

    Following the same logical patterns used in the article, Anything is much better in theory than in practice.

    It really takes a stupid and ignorant person to actually claim what the article claims.

    UI is the only thing that OOP is used for? Not for code clarity, compactness, organization and reuse? Hey, let us all go back to writing thousands of lines of procedural code and give massive heart attacks to any developer who would be supporting such code.

    I cannot believe insanity like that can even be allowed to be posted. One good way to mislead novice programmers using article posts as one source for getting information.

    I love the code reuse through copy and paste, I really do...NOT!!!!

    How about just shoving OO languages like Java out of the door a go back to..say...ABAP, ADA (oh, that has OOP concepts)..hey, how about Assembly...:-)))

    Cudos to Richard for remaining a dinosaur for all this many years, I think the punch-card and Fortran years left some daunting mark on the rest of his life. (Or were those the happy pills that he was taking through the long nights debugging his procedural code?)

    Sincerely,

    Artem D. Yegorov
    http://www.activexml.org
  130. Richard an idiot?[ Go to top ]

    I have been a member of TSS.COM for 3 years but never before have I ever received any useful practical tip or trick.

    "I recently had a shift in how I see the role of objects and classes"
    http://www.theserverside.com/news/thread.tss?thread_id=31439#155097

    "Create a "solution" with a view assembly, business logic (domain model) assembly"
    http://www.theserverside.com/news/thread.tss?thread_id=31439#155323

    In this thread I got two!

    Regards
    Rolf Tollerud
  131. Re: Richard an idiot?[ Go to top ]

    I have been a member of TSS.COM for 3 years but never before have I ever received any useful practical tip or trick. "I recently had a shift in how I see the role of objects and classes"http://www.theserverside.com/news/thread.tss?thread_id=31439#155097"Create a "solution" with a view assembly, business logic (domain model) assembly"http://www.theserverside.com/news/thread.tss?thread_id=31439#155323In this thread I got two!RegardsRolf Tollerud

    Wow, pretty impressive... I've been a membre for some years now too, and never before have I met someone who "knows-it-all" so much that he didn't learn *anything* from TSS during 3 full years 'till now!
    (btw why is it you're still a membre then?)
  132. Rolf likes my post?[ Go to top ]

    I have been a member of TSS.COM for 3 years but never before have I ever received any useful practical tip or trick. "I recently had a shift in how I see the role of objects and classes"http://www.theserverside.com/news/thread.tss?thread_id=31439#155097"Create a "solution" with a view assembly, business logic (domain model) assembly"http://www.theserverside.com/news/thread.tss?thread_id=31439#155323In this thread I got two!RegardsRolf Tollerud

    You know, I never expected you to consider anything I write a good thing. Perhaps it is because I was talking about .NET? The techniques I described are language agnostic. .NET's "internal" keyword just happens to work well in this particular context.
  133. A puzzle[ Go to top ]

    I wonder how Mr Richard Mansfield designs his software and how he explains to others how it works and how easy it is for others to maintain.

    Seriously, was I was the only one who was offended by his closing comments.
  134. Author seems to think that the only successful oop libraries are GUI-related.

    Can you imagine the entire java collections framework without oop? If you are old enough I guess you don't have to:

    <code>
    // Add value to list
    call addToList(mylist, indexsize, newValue);

    ....
    method addToList(long[] alist, indexsize ,long value) {
     if (indexsize = alist.length) {
        call resizeArray(long[] arr, newsize);
     }
    ....
    }
    </code>

    Also, the author seems to feel that there is one OOP way of programming. To me OOP is only a set of language features. How you apply those features is a style. You can do oop-like programming in a non-oop or partially-oop langauge and you can do procedural programming in an oop langauge.

    I'm not sure what projects the author works on but I'd bet they aren't of any great size or complexity. He mentions book examples, and corporate scripts so maybe BASIC works great for him.
  135. I wonder if this guy...[ Go to top ]

    ...has ever tried writing a compiler? There are some very direct ways inheritance makes the task easier and cleaner.

    I also wonder how many different languages he has programmed in? Or even different types of language. If he's only been exposed to C++, it would (quite validly) explain his discontent, IMO.
  136. Hello,

        I have been developing softwares for last 12 years. So far I have not seen a single business application which really benefited because of OOP. Well having third party utility libraries certainly makes business app development easy. But because of OOP a client requirement was satisfied by mearly plugging-in different implementation and or one line in some configuration file is really a dream. In particular JAVA community is really plagued by this phenomenon. I have seen at-least two large implementations developed using OOP, full of different design patterns and failed to deliver miserably.

    What I really think is before using every technology or new theory into practice carefully study it and find out whether is it really going to benefit in long-term. As far as OO is concern it really works great in CAD-CAM or programs alike (See samples in various theory books).
  137. thank you[ Go to top ]

    Hi Prasad,
    Thank you for your input. Please let me point you to some some very successful implementations that greatly benefit from OOP, you might want to consider useful adding to your twelve years of experience. Ones that are not necessarily GUI oriented. Hoping it is of any use to you:
    JBoss, BEA WebLogic, IBM WebSphere, most Apache and Jakarta projects and so on... well yeah, I'm a bit lazy I must admit, so the list only includes the very obvious major players, should be sufficient though...

    I wonder if you knew that JBoss for instance is largely recognized for its quality implementations. The guys at JBoss are very open for discussion, so I suggest you ask them why they're using OOP in their product. Who knows, it might give you a useful insight that you were not given during 12 years.
    Well having third party utility libraries certainly makes business app development easy.

    Applications use libraries, but are build on top of frameworks. Ever tried to replicate Struts' under the form of a library, anyone? (or using procedural programming? hey, that could be an interesting challenge for PP lovers: prove what you say!...as if I cared for what they say...)
    What I really think is before using every technology or new theory into practice carefully study it and find out whether is it really going to benefit in long-term.

    It might come as a desapointment to you, but really a lot of people have done that and came to the conclusion that OO(P) was the best way to go. Thats why we have all these quality products offering us a whole new range of features that we couldn't have before (IMO with PP) (I'm talking product features, not necessarily GUI related).
    But because of OOP a client requirement was satisfied by mearly plugging-in different implementation and or one line in some configuration file is really a dream.

    undestand not I sentence.
    In particular JAVA community is really plagued by this phenomenon.

    Which community is not?
    ... using OOP, full of different design patterns and failed to deliver miserably.

    Now I get it: all developpers are good, but the mind of some of them is being perverted by OOP and design patterns and that's why their code is bad! Of course.
    As far as OO is concern it really works great in CAD-CAM or programs alike (See samples in various theory books).

    Hmmm, that sounds a lot like Richard Mansfield speaking. You forgot to add "but java is so lame for GUI development and that's why OOP in general is so lame..."
    I'm pretty sure I could find a "theory book" that says that OOP (and smalltalk and java) were invented by Evil Communists Aliens from Mars to force you to write bad applications that in the end would help the world economy to collapse, diseases to spread, and your brain to melt, in order to for them to abduct your children, rape your wife and take over the world easily.
    Yeah, I've heard of books like that. Richard Mansfelt even pointed us to this, in his opinion, "excellent" website that tells it all: http://www.geocities.com/tablizer/oopbad.htm

    That's why I like these guys, they always give me so much fun ;)
  138. Hello,&nbsp;&nbsp;&nbsp;&nbsp;I have been developing softwares for last 12 years. So far I have not seen a single business application which really benefited because of OOP.

    Curious... I have also 12+ years of development experience and have seen lots of applications that did benefited from using OO. They are business applications mainly for the Finance/Banking/Insurance industries. Also, workflow and some embedded solutions as well for small, medium, big and global 100 companies.

    I guess the issue is not what you have seen but what you have been developing all these years.

    Cheers!
  139. I am not a COBOL programmer, I have been programming since 1990 and I think this author has it right. If instead of cut and paste he had mentioned the use of libraries, and run time linking and loading, I think he would have come across as more genuine to some of you OOP diehards. If you just tone down that noise and capture the essense of what he is saying - DANG MAN ! The guy is right on.. Almost 95% of todays IT applications dont fit into the OOP paradigm and still I see morons struggle everyday trying to fit *information* into objects and objects into relational databases. Overengineer, abuse, reuse... hey now I am thinking of writing a paper tooo.. cya later
  140. Where have you been all these years ?[ Go to top ]

    Almost 95% of todays IT applications dont fit into the OOP paradigm and still I see morons struggle everyday trying to fit *information* into objects and objects into relational databases. Overengineer, abuse, reuse... hey now I am thinking of writing a paper tooo.. cya later

    Hmmm. I must only be coding the in the other 5%.

    I am seeing the opposite being true. I see the problem as people only seeing data and databases. They see a report as one app and "OLTP" as another and the dataloader as another with the only intergration point is the DB. If they encapsulated things in objects alot of duplicated effort could be reduced.
  141. Where have you been all these years ?[ Go to top ]

    Almost 95% of todays IT applications dont fit into the OOP paradigm and still I see morons struggle everyday trying to fit *information* into objects and objects into relational databases. Overengineer, abuse, reuse... hey now I am thinking of writing a paper tooo.. cya later
    Hmmm. I must only be coding the in the other 5%. I am seeing the opposite being true. I see the problem as people only seeing data and databases. They see a report as one app and "OLTP" as another and the dataloader as another with the only intergration point is the DB. If they encapsulated things in objects alot of duplicated effort could be reduced.

    Agree 100%.
    I must be coding in the other 5%... Any monkey coder can hit a database and put together a crappy application without even thinking.

    But OO forces you to think and do it properly... so the question is not to not think but think faster and better... and OO helps a lot in this area...

    That's why we are paid the big bucks...
  142. Where have you been all these years ?[ Go to top ]

    They see a report as one app and "OLTP" as another and the dataloader as another with the only intergration point is the DB. If they encapsulated things in objects alot of duplicated effort could be reduced.

    That's the MS-Access syndrome.

    The article was crappy and that guy was completly clueless. I even sent him and email challenging to come out and start a debate in a public forum just between him and me...

    ... and he just said: I decline your challenge!!!
  143. If you want to debate[ Go to top ]

    That's the MS-Access syndrome. The article was crappy and that guy was completly clueless.
    The author asked for example applications that demonstrate OO's alleged power. That is a fair request. If you claim OO is the cat's meow, you are obligated to demonstrate it with code and perhaps some hopefully semi-realistic change scenarios, not the rigged/filtered kind that Meyers et al use. Many want to see the same thing. Mantra alone does not cut it. OO has great mantra, but often it is too simplistic in my opinion. It assumes regularity in the real world that frankly I don't see.

    Inheritance would indeed simplify change if changes were tree-shaped; but most are not in my observation. And composition, an alternative to inheritance, is messier than procedural+SQL based solutions. Thus, you either have the simple approach that works great in theory but not in practice; or you switch to someting more flexible, composition, which is uglier than the alternatives: a big yarn-ball of object pointers. The simplicity of the animal and shape book examples is lost. It is the Bachmanian pointer-hell that relational proponents despise.
    I even sent him and email challenging to come out and start a debate in a public forum just between him and me...... and he just said: I decline your challenge!!!

    If you want to debate, the guy referenced in the article tends to hang out at the c2.com wiki and loves debating pro-OO'ers. (Although c2 has been flakely lately, it should clear up soon.)
  144. The following was supposed to be quoted in the above message, but a minor typo made the tag be ignored. (Where's the PREVIEW or re-edit mode in this system?)
    That's the MS-Access syndrome. The article was crappy and that guy was completly clueless.
          
    Sorry about the typo.
  145. Much better than OOP and PP![ Go to top ]

    I almost forgot to add this:

    There's a much better alternative to OOP and PP alltogether, it's called Brainfuck!

    Check out this site:
    http://www.muppetlabs.com/~breadbox/bf/

    If Sun, IBM and M$ were aware of this, they would drop all of their languages/technologies instantly and adopt Brainfuck.

    Spread the word!
    Cheers ;)
  146. Kak[ Go to top ]

    Richard Mansfield has written 32 computer books since 1982, including bestsellers 'Machine Language for Beginners' (COMPUTE! Books) and 'The Second Book of Machine Language' (COMPUTE! Books). From 1981 through 1987, he was editor of COMPUTE! Magazine and from 1987 to 1991 he was editorial director and partner at Signal Research.

    I think this says it all. RM's acendency seemed to tail off in 1991... when OO began to gain popularity.

    OO vs procedural is a dogma; actually, most oop code is procedural. A more valid distinction is procedural vs event based. Most apps these days have a high degree of event based logic in GUIs.

    OOP is fundamentally encapsulation, inheritance, and polymorphism. These are useful concepts for any procedural programmer is properly understood.
  147. This article must have really hit a nerve. Paolo wholeheartedly "despises" the author. Farzad thinks he is a "retard." He is discredited because he wrote books in assembler. He is discredited because he is old and "stuck in the past." And on and on and on. Is this representative of the Java community?
  148. This article must have really hit a nerve. Paolo wholeheartedly "despises" the author. Farzad thinks he is a "retard." He is discredited because he wrote books in assembler. He is discredited because he is old and "stuck in the past." And on and on and on. Is this representative of the Java community?
    No, it is representative of the Human race.

    You should hear what the Smalltalkers are saying. :)
  149. "Is this representative of the Java community?"

    Yes.

    IMO
    Rolf Tollerud
  150. He wrote books in assembler? Man, IT books in English are hard enough to read.

    Yes, I think this forum is representative of the Java community, or any technical community. Your point?