Pitfalls of OOP
Paul Sinnett
Ed Kirwan
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
BGB / cr88192
"Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
news:oop-20091...@ram.dialup.fu-berlin.de...
> Paul Sinnett <paul.s...@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.
Doc O'Leary
"BGB / cr88192" <cr8...@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.
S Perryman
> Paul Sinnett wrote:
> 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
Ed Kirwan
> Ed Kirwan wrote:
>
>
>> 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.
>
Sorry, I should have stated the definition of encapsulation that I used to
make the above statement.
The International Organisation for Standardization's Reference Model of Open
Distributed Processing defines it as:
"Encapsulation: the property that the information contained in an object is
accessible only through interactions at the interfaces supported by the
object."
(Here, they also define, "Object," as, "The model of an entity," rather than
the narrower, operationalist view of an object's being the instantiation of
a class.)
In 1972, Canadian David Parnas described how software should be designed
using the technique of, "Information hiding,":
"We propose instead that one begins with a list of difficult design
decisions or design decisions which are likely to change. Each module is
then designed to hide such a decision from the others."
The point being that if functionality that might change is hidden, then
changing this functionality will have a less burdensome impact than would
be the case had that functionality been accessible to all other modules.
Reading the encapsulation definition above, we see that if an object's
information is accessible only via the object's interfaces, then the object
itself must manifest two fundamentally different phenomena: that which is
accessible to clients (the interfaces) and that which is not accessible to
clients (the contained information). It is suggested that the ISO and
Parnas definitions can be married by the proposal that the information
which is not accessible to clients is information-hidden in the Parnasian
sense.
To the degree that behaviour may be information-hidden, potential changes to
that behaviour propagate to other parts of the system with less probability
than changes to behaviour that is not information-hidden.
It was in this sense that I meant that encapsulation is about minimising the
number of potential dependencies with the highest change-propagation
probability.
Coupling is the measure of the strength of association established by a
connection from one module to another. Potential coupling (at least with
respect to the classes discussed in the slideware) is potential number of
dependencies between the classes of a system. So I'd say that the claim I
made about encapsulation above is not a definition of coupling, but rather
states that encapsulation helps minimise potential coupling.
Still, "Encapsulation is about organising things into something that can be
*referenced as a whole*," is a also a succinct distillation.
S Perryman
> [ defs snipped but read and acknowledged ... ]
Encapsulation and information hiding are orthogonal concepts.
Encapsulation is an *enabling mechanism* for information hiding.
When a user U uses a component C, and the usage forces U to be
dependent on the (internal) implementation of C, there is said to
be a *content coupling* relationship between U and C.
Content coupling is one form of coupling relationship that can
exist between components.
Information hiding is a means of preventing content coupling.
Regards,
Steven Perryman
Ed Kirwan
>
> 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.
>
You are wise. Rarely are religious belief, consumption habit and headwear
fashion indicators of cost-effective production.
Minimising the potential cost of ripple-effect is, however, a good indicator
of cost-effective production.
When faced with dogmatic assertion, the wise man will ask for evidence. An
alledged production benefit that cannot show objective evidence of its
benefit is to be rejected.