I'm confused...

Post #60,770 by johnu 11/2/02 3:36:16 PM Reply	I'm confused... I especially dig their "refactoring" to cover up what is really going on: Code rework* because OO failed at its change-friendly goals...* So you argue that since OO failed at it's change-friendly goals, they invented refactoring (which is changing the structure of code without changing it's behavior). If OO is so change unfriendly, why would changing OO code (refactoring) be so popular? Regards, John
Post #61,016 by tablizer 11/4/02 1:55:32 PM Reply	Inertia If OO is so change unfriendly, why would changing OO code (refactoring) be so popular? You seem to be suggesting that something that requires more effort should disappear from the market place. However, there is often inertia in the industry which prevents this. QWERTY, COBOL, and Microsoft servers are an example of things that were more effort than alternatives, but organizations just did not want to change for whatever reason. Job security, perhaps. Good auto mechanics have fewer repeat customers, it is sometimes said. Futher, OO gurus did not want to admit failure, so they just renamed failure to make it sound more pleasent. BTW, I did not say that OO fans "invented" the term or concept of refactoring. I don't know its true origins. I am saying that OOP has popularized or mainstream-ized the concept. Rather than admit it failed to make code change-friendly, they made code rework into a standard corporate function or step. ________________ oop.ismad.com
Post #61,135 by johnu 11/5/02 8:42:36 AM Reply	My head hurts Let's try this one last time: You argue that OO failed to make code change-friendly. You then argue OO gurus brought out refactoring to cover up that failure. How could that possibly be since refactoring is about changing code? Wouldn't refactoring OO code be impossible if OO was not change-friendly? Regards, John Urberg
Post #61,144 by Arkadiy 11/5/02 9:52:42 AM Reply	That's normal when you talk to Tablizer. Get used to it. -- We have only 2 things to worry about: That things will never get back to normal, and that they already have.
Post #61,228 by a6l6e6x 11/5/02 5:07:00 PM Reply	ROFL! Thanks, Doc. Alex "I have a truly marvelous demonstration of this proposition which this margin is too narrow to contain. -- Pierre de Fermat (1601-1665)
Post #61,555 by tablizer 11/7/02 1:32:15 AM Reply	Misunderstanding "change friendly" Okay okay, now I see the problem I think. There is a big misunderstanding WRT "change friendly". I meant how the code as a whole weathers changes, not each individual peice of code. Change-friendly design is a design that requires the fewest code changes upon a given application requirements change. It is not the ability of the code to morph, but the NEED to undergo change or morphing in the first place. It would be roughly analogous to a plumbing design that avoids the need to bend pipes, and NOT the maluability (bendability) of the pipes themselves. Is that clear now? This kind of reminds me of when John Lennon said, "The Beatles are bigger than Jesus Christ now" in the 60's (IIRC radio story). Religious groups went crazy and held mass record burnings. What they did not understand is that John was comparing their popularity to Jesus, and not their value as beings. Some preists came forward and even agreed with John, saying that "young people don't pay enough attention to religion and too much to pop stars" (paraphrased). John tried to explain the comment to the press, but it didn't seem to come out right. ________________ oop.ismad.com
Post #61,573 by johnu 11/7/02 8:24:09 AM Reply	Where's the "tablizer dictionary"? You need one with all the terms you make up. Regards, John Urberg
Post #61,576 by boxley 11/7/02 8:49:04 AM Reply	oopsismad.com, it makes good reading and helps understanding some points that Bryce makes. thanx, bill oops is tops will work for cash and other incentives [link\|http://home.tampabay.rr.com/boxley/resume/Resume.html\|skill set] "Money for jobs? No first you get the job, then you get the money" Raimondo
Post #61,685 by tablizer 11/7/02 2:41:09 PM Reply	re: Where's the "tablizer dictionary"? I thought it was self-explanatory, but I was wrong. It seems there are multiple valid (or semi-valid) interpretations that I failed to anticipate. I am sorry. I will avoid its usage for now on. How about "maintenance friendly" instead? ________________ oop.ismad.com
Post #61,800 by CRConrad 11/8/02 2:40:56 AM Reply	But then... Easy re-factoring IS "maintenance-friendly"! A lot more "maintenance-friendly" than DIFFICULT re-factoring, anyway...
Post #61,942 by tablizer 11/8/02 10:05:05 PM Reply	Are you saying OOP is easier to refactor? ________________ oop.ismad.com
Post #62,037 by johnu 11/10/02 10:20:00 AM Reply	The real Tablizer dictionary Change friendly = p/r code Maintenance friendly = p/r code OO code != p/r code therefore OO is by definition not change friendly or mainentance friendly Refactoring = something OO gurus made up/stole to hide the fact that OO is not change and maintenance friendly
Post #62,043 by folkert 11/10/02 10:55:15 AM Reply	OMFG! ROFLMAO! LOL2! `[link\|mailto:curley95@attbi.com\|greg] - Grand-Master Artist in IT [link\|http://www.iwethey.org/ed_curry/\|REMEMBER ED CURRY!!!] Your friendly Homeland Security Officer reminds: Hold Thumbprint to Screen for 5 seconds, we'll take the imprint, or Just continue to type on your keyboard, and we'll just sample your DNA.`
Post #61,770 by static 11/7/02 10:42:18 PM Reply	You're referring to the design of the code. IOW, I understand your qualification to mean a well though out design will tend to only need changes to it's meta-data than in the actual code. Wade. "Ah. One of the difficult questions."
Post #61,793 by tablizer 11/8/02 1:01:50 AM 11/8/02 1:06:34 AM Reply	re: You're referring to the design of the code. IOW, I understand your qualification to mean a well though out design will tend to only need changes to it's meta-data than in the actual code Well, that is certainly part of it. But it also has to do with how much code rework is needed per change. For example, in program A, a given requirements change may result in splitting 2 classes and moving 2 methods to another class; but in program B, the same change may only result in altering 2 classes in place. The second one would probably get a higher "change-friendly" score. (There are finer granularity counting techniques, I would note.) It is based on the total effort of rework you could say, regardless of whether it is code or tables that have to be altered. (Note that meta-data alteration may require a less skilled person, and thus less money expended by the company.) ________________ oop.ismad.com Edited by tablizer Nov. 8, 2002, 01:06:34 AM EST Expand All History

Welcome to IWETHEY!