Jump to content
  • Advertisement
Sign in to follow this  
Wavarian

Does this fall under any particular design pattern?

This topic is 4899 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This nonsense about wether or not you need [virtual functions] for OOP... it's nonsense. You don't need inheritance at all. I write OOP in C. The win32 api is object-oriented C code. Sure, it's ugly. But it's still OOP.

The GOF design-patterns book says this about the template method pattern:
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

Wether or not it's runtime type traits depends on how it's used. You should move the special code into the subclass. Something like

class foo
{
public:
virtual void dostuff() {}
void someoperation()
{
//do some stuff
this->dostuff();
}
};

You don't even need the condition then. A derived class that isn't sizable just doesn't override dostuff. And then it would definitly be the template method pattern.

[edit]I mean virtual functions, not polymorphism.[/edit]

[Edited by - Deyja on September 13, 2005 6:54:08 AM]

Share this post


Link to post
Share on other sites
Advertisement
As Shannon noted, this isn't really a Template Method. The central point of a Template Method is that some of the processing is deferred to later down the inheritance chain. But that doesn't happen here -- derived classes would just override the method in question. In other words, this isn't a design pattern per se, just inheritance in action.

Share this post


Link to post
Share on other sites
Quote:
Original post by Code-R
Quote:
Original post by Deyja
I write OOP in C. The win32 api is object-oriented C code.


L-M-F-A-O!

Look up the documentation for CloseHandle(). You can pass in several different types of HANDLEs, such as those for mutexes and wait events, to the same function. From the outside, the client sees only the 'base' HANDLE type.

Share this post


Link to post
Share on other sites
Win32 is absolutely not object-oriented. There's no inheritence.
It's exhibits strong encapsulation & data hiding, and weak polymorphism.
I'd say it's modular.

The three must-haves are inheritence, polymorphism, and encapsulation, and many (such as myself) consider data-hiding a fourth requirement.

Share this post


Link to post
Share on other sites
Quote:
Original post by Shannon Barber
Win32 is absolutely not object-oriented. There's no inheritence.
It's exhibits strong encapsulation & data hiding, and weak polymorphism.
I'd say it's modular.

The three must-haves are inheritence, polymorphism, and encapsulation, and many (such as myself) consider data-hiding a fourth requirement.
That's a hijacked definition for some people. See Nyygard Classification.
Quote:
Object-oriented programming. A program execution is regarded as a phys-
ical model, simulating the behavior of either a real or imaginary part of
the world.
The notion of a physical model should be taken literally. Most people can
imagine the construction of physical models by means of, for example, Lego
bricks. In the same way, a program execution may be viewed as a physical
model. Other perspectives on programming are made precise by some under-
lying model defining equations, relations, predicates, etc. For object-oriented
programming, however, we have to elaborate on the concept of physical mod-
els.

But alas, Win32 doesn't really fit this description either.

Share this post


Link to post
Share on other sites
Quote:
Original post by flangazor
Quote:
Original post by Shannon Barber
Win32 is absolutely not object-oriented. There's no inheritence.
It's exhibits strong encapsulation & data hiding, and weak polymorphism.
I'd say it's modular.

The three must-haves are inheritence, polymorphism, and encapsulation, and many (such as myself) consider data-hiding a fourth requirement.
That's a hijacked definition for some people. See Nyygard Classification.
Quote:
Object-oriented programming. A program execution is regarded as a phys-
ical model, simulating the behavior of either a real or imaginary part of
the world.
The notion of a physical model should be taken literally. Most people can
imagine the construction of physical models by means of, for example, Lego
bricks. In the same way, a program execution may be viewed as a physical
model. Other perspectives on programming are made precise by some under-
lying model defining equations, relations, predicates, etc. For object-oriented
programming, however, we have to elaborate on the concept of physical mod-
els.

But alas, Win32 doesn't really fit this description either.


That's an awful notion of OO; regard the object relationships described in Design Patterns most of which have very little to do with the physical world.

See Object Oriented
{Encapsulation, Polymorphism, Inheritance}

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!