Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Rich MacDonald on 15 Jun 2005 22:40 "Ilja Preuý" <it(a)iljapreuss.de> wrote in news:42abde6c(a)news.totallyobjects.com: > To me, the interesting question here isn't the algorithm of > calculating the intersection of two shapes, but why requesting to *put > the operation into the shape class* should cause any mind-lock. I > assume that the underlying algorithm wouldn't need to change much > regardless of where we put it... Ah yes. Ok, that caused me plenty of mind lock in my early days. I'd put the shape comparison in the shape class(es) and it'd get ugly. Some years ago, RM eliminated my indecision for good with some slam-dunk argument for immediately dispatching shapeInstance1 and shapeInstance2 to some 3rd ShapeComparator class. Don't have the thread handy and it might not have been a slam-dunk but it settled it...the code smelled better :-) I still like the convenience of asking two shapes to compare themselves with each other because I don't think a client should have to worry (know) about the ShapeComparator class, but its right to delegate. Ain't the "pure OO" argument perhaps, but its "the code will tell you what it needs" argument which trumps.
From: Patrick May on 16 Jun 2005 04:56 "topmind" <topmind(a)technologist.com> writes: > In this case, I am requesting an example of allegedly good OO that > many people can publicly disect and analyze. You have already been pointed to the publicly available FitNesse. You have thus far failed to raise any issues with its design or implementation despite claiming to have developed a Wiki using your preferred approach. Please demonstrate how you would improve this software by eliminating the use of OO techniques. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: Isaac Gouy on 16 Jun 2005 11:41 CTips wrote: > Also, does nice have separate compilation, or does it effectively > "compile" a whole program at a time? separate compilation We've compiled the program; let's hide the source files for shape, circle, rectangle, hoop; let's remove a definition from intersect and recompile: package test.intersect; import test.shape; import test.circle; import test.rectangle; intersect(Circle s1, Rectangle s2){ println("circle rectangle"); } //intersect(Rectangle s1, Circle s2){ println("rectangle circle"); } I:\Test>nicec --sourcepath .. --classpath .. -a test.jar test nice.lang: parsing test.shape: parsing test.rectangle: parsing test.circle: parsing test.intersect: parsing test.hoop: parsing test: parsing test.intersect: typechecking test.intersect: generating code test: typechecking test: generating code test: linking I:\test\shape\package.nicei: line 14, column 23: The implementation test failed for method nice.lang.void intersect(test.shape.Shape s1,test.shape.Shape s2): no alternative matches (test.rectangle.Rectangle, test.circle.Circle) compilation failed with 1 error
From: topmind on 16 Jun 2005 13:34 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > In this case, I am requesting an example of allegedly good OO that > > many people can publicly disect and analyze. > > You have already been pointed to the publicly available > FitNesse. You have thus far failed to raise any issues with its > design or implementation despite claiming to have developed a Wiki > using your preferred approach. Please demonstrate how you would > improve this software by eliminating the use of OO techniques. > I never claimed that I can objectively improve on it. I am only questioning suggestions that the OO version is objectively better than non-OO versions. But until you present detailed reasoning for your objectivity claim, there is nothing to attack other than the unfulfilled claim itself. I am complaining that you guys have no objective evidence for your claims. That is NOT the same as claiming I have objective evidence it is better. If you don't understand the difference, then we are stuck at a logical impasse. Personally I suspect you are unskilled in the art of evidence logic, but will give you the benefit of the doubt and assume you are just not understanding my point of view. The difference between X and Y should be considered zero or unknown (null) until shown otherwise. You have not shown otherwise, yet imply that you have. benefitsX - benifitsY = null benefitsY - benefitsX = null I am not claiming there is a known objective non-null answer, but it appears you are. ******************************************** * I am not under obgligation to prove * * objectivity unless I claim objectivity. * ******************************************** At least Mr. Martin seems to claim non-domain-specific objectivity. If you are not joining him, then I suggest you move on. Further, I presented my code examples (on my website) before FitNesse was presented. Why do you get to change channels until you find an example you like but not me? Shouldn't the first get to go first? > Sincerely, > > Patrick > -T-
From: topmind on 16 Jun 2005 14:14
> > >I am having difficulty finding coherent requirements or code samples > >for a dosage system. How about we focus on stuff that polymorphs in > >that example. What are the polymorphic types or classes? > > The requirements are reasonably well stated in overview form in the > first article. By the second or third article there is a very > concrete requirement specified in detail as an acceptance test. > > If you follow the example through the columns, you'll find a number of > polymorphic entities. Perhaps the first you'll find are the test > cases themselves. They derive from the JUnit framework. Next, you'll > find that the acceptance test fixtures are based on a polymorphic > framework (FIT). Within the application you find a polymorphic > gateway to the database, and (Manufacturing) which is a mock object > that masquerades as another system. You find that the messages show > hints of polymorphism, and may become fully fledged polymorphic > entities in a later iteration. > > Bit by bit, as the application evolves, more and more polymorphism > creeps in. The application does not start with a lot of polymorphism. > Rather, polymorphism gets added over time in order to keep the > application flexible and decoupled. > I was hoping for something that everyone can easily study, not *just* you and me. Thus, if I use your example, I would have to consolidate it and clean it up the doc for presenation, removing the story-like flow. I don't want to be a P.I.T.A. but it seems that is your obligation, not mine. Also, I strongly suspect that the debate will end up centering around whether real-world change tends to go with the grain of polymorphism or not. We cannot confirm the pattern of future changes by looking at code alone. So far this appears to be the key to our difference in opinion. I say real changes will better fit sets in the long run and you suggest they will fit sub-type IS-A trees. [1] But until that is resolved, I feel your written work should contain disclaimers about assumed change patterns. The existing OO literature has presented an unrealistic (or at least undocumented) view of change patterns. This is an OO intellectual sin that should be addressed. If you agree with this general assessment of our differences, then we can call it quits and leave this topic with the assumption that we both don't have enough objective information to solve the difference; that it remains an area of future research. Note that sets are not really about "decoupling" things, because I feel that is often impossible. Business rules interweave such that by their nature changes tend to affect a lot of unexpected things. There really is no predictable "grain of change". I have been trying to see patterns in biz-rule clouds all these years but now realize they are just clouds. If they happen to look like something, it is usually short-lived and cooincidence. Rather than pretend we can decouple, the purpose of using sets is to better *manage* the impact of change, to manage the big messy graph that is the real world. If change ripples, it ripples; but at least let's have a systematic way to study, apply, codify, and verify change progression. I have seen too many cases where designers try to pound things into a tree shape, and it grows ugly. It is like how they kept adding epicycle layers to the planet paths in the medeavel days rather than give in to the reality of the imperfect universe. Alexander Stepanov, father of STL, has stated similar things about OO and classification systems. If you need a big name to help change your mind instead of a peon like me, there it is. [1] Others appear to suggest sets-of-trees via multiple inheritance and "interface" inheritance rather than a single tree. However, it is my opinion that such are messier to manage than a set-centric approach. That is addressed in sister messages. Also, relational systems currently seem the best tool to hold and process most set info. Hard-wiring them into code should only be done for "local" classifications. > > > ----- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T- |