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.
> 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.
Ed Kirwan wrote: > Paul Sinnett wrote: > http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls... > 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.
>> 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.
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.
> 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.
