Pitfalls of OOP
in [OOP]
|
Prev: Call for Papers & Sessions: The 2010 International Conference on Software Engineering Research and Practice (SERP'10), USA, July 2010
Next: Informatics 2010: submissions until 25 January 2010
From: Paul Sinnett on 21 Dec 2009 06:13 http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
From: Ed Kirwan on 21 Dec 2009 13:47 Paul Sinnett wrote: > http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf That slideware rekindled my admiration for game design. I haven't thought about processor pipelining in years. If the slideware - excellent though it is - has a weakness it's that it could be interpretted too broadly. There's certainly something striking about the bold assertion on slide 110, "It's all about the memory." It isn't. Development cost is a factor. Though at least the follow-up on slide 112 clarifies somewhat, "Remember, you are writing a game." The weakness mentioned above is that readers could overlook the game-aspect and take the advice to be generally applicable, which it is not. Encapsulation is about minimising the number of potential dependencies with the highest change-propagation probability, so that if you change the code in one place, you minimise the chance ripple-effect, forcing costly changes elsewhere. That's not a benefit to be thrown out lightly. Of course, when you're as close to the metal as Tony is, then potential ripple effect costs perhaps pale compared to the enormous financial losses of a game that doesn't sell because it's too slow. Expensive business, game development. Ed. -- www.EdmundKirwan.com - Home of encapsulation theory
From: BGB / cr88192 on 1 Jan 2010 23:36 "Stefan Ram" <ram(a)zedat.fu-berlin.de> wrote in message news:oop-20091222192819(a)ram.dialup.fu-berlin.de... > Paul Sinnett <paul.sinnett(a)gmail.com> writes: >>http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf > > The author might have a point. But it is hidden in a > disgusting PDF file. What would be an abstract of this PDF > file giving the central theses in two or three sentences? > > Also, it starts with �object-oriented programming�, then > brings in C++. I wonder what C++ is suppossed to have to do > with object-oriented programming. > in many peoples' minds, C++ == OOP, and in many others, Java == OOP. then there is a lot of C++ which looks like Java being regarded as OOP (whether or not it actually follows the core principles of OO is another issue). this is why I dislike "OOP", it is the whole "you know we are the holy ones because we eat the right food and wear the right kind of hat" mindset. granted, personally, I have little against OO otherwise.
From: Doc O'Leary on 2 Jan 2010 12:45 In article <hhmigs$fch$1(a)news.albasani.net>, "BGB / cr88192" <cr88192(a)hotmail.com> wrote: > in many peoples' minds, C++ == OOP, and in many others, Java == OOP. So? Ignore all those people. Suggest to them that they instead find a satisfying career in the fast food industry. -- My personal UDP list: 127.0.0.1, localhost, googlegroups.com, ono.com, and probably your server, too.
From: S Perryman on 3 Jan 2010 06:44
Ed Kirwan wrote: > Paul Sinnett wrote: > http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf > That slideware rekindled my admiration for game design. I haven't thought > about processor pipelining in years. > If the slideware - excellent though it is - has a weakness it's that it > could be interpretted too broadly. There's certainly something striking > about the bold assertion on slide 110, "It's all about the memory." > [...] > The weakness mentioned above is that readers could overlook the game-aspect > and take the advice to be generally applicable, which it is not. The issue they have is squeezing every drop of performance out of an implementation that is being produced by a particular code generator, for a particular processor env. That is a matter of *algorithmics* (providing the best solution to squeeze those drops out) , and *abstraction* (how to present the algorithmics to user components, without coupling those components to the details) . None of which is specific to OOP. > Encapsulation is about minimising the number of potential dependencies with > the highest change-propagation probability, so that if you change the code > in one place, you minimise the chance ripple-effect, forcing costly changes > elsewhere. No, that's *coupling* . Encapsulation is about organising things into something that can be *referenced as a whole* . Whether that whole is a module, ADT, class etc is another story. > Of course, when you're as close to the metal as Tony is, then potential > ripple effect costs perhaps pale compared to the enormous financial losses > of a game that doesn't sell because it's too slow. When one has to talk of "pitfalls" in terms of particular processors etc, then the point is lost. I would expect a similar slide-pack to come from TI, ADI etc called "pitfalls of OOP" , showing the problems of 'typical' C++ impls of convolution, FFT etc on their DSPs. Regards, Steven Perryman |