Go Back   Armenian Knowledge Base > Technical sections > Languages, Compilers, Interpreters > Algorithms

Reply
 
Thread Tools

A Singleton Discussion
Old 01.03.2006, 03:16   #1
Easy rider
 
Silver's Avatar
 
Join Date: 11 2005
Location: tristeza
Age: 39
Posts: 1,082
Rep Power: 0
Lightbulb A Singleton Discussion

Howdy,

We all know that using global variables eliminates all abstraction and basically means a bad design.

Code:
int APIENTRY WinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)
{
	CGame::Instance()->Init(hInstance);  // Initialize the subsystems
 
 
	while (CGame::Instance()->getGameWnd()->HandleMessages())
	{
		CGame::Instance()->Run();
	}
 
 
	CGame::Instance()->Shutdown();
 
	return 0;
}
This is the main.cpp of the project I'm currently working on, with the error handling removed. Basically, my CGame is a class that is accessible to everyone from everywhere - ****y, but flexible. It is also the top container of all data in my application. It contains pointers to all different subsystems like the graphics subsystem, the game logic subsystem, the sound subsystem, the window subsystem etc. Through CGame::Instance()->get***(), each class can aquire a pointer to the subsystem it wants and work with it. That way, all objects on my world can 'see' each other and interact with each other the way they are programmed to. And I really do not see a possible 'abstracted' alternative - maybe someone can point me out!

Here is an example situation in my project. The CRabbit class implements the functionality of a bunny and is inherited from ICreature. Each ICreature must implement a Draw() routine. Since the graphical output in my app is quite complicated, it's wrapped with the CGraphics class. So my shrinked code for CBunny::Draw() looks as follows:

Code:
void CBunny::Draw()
{
	CGame::Instance()->getGraphics()->DrawMesh(this->mesh);
}
Which really does look natural to me. I have only one game, only one graphical subsystem, only one memory manager etc running during the entire application lifetime. So I really (and I mean really, please) want to see a bulletproof reply of a better alternative for the design, provided with arguments and all. Anyone?
__________________
http://sssilver.googlepages.com/blog...ner_300x30.jpg

http://www.hra.am/img/Gulyan1.gif

You must spread before giving to Silver again.

Re: A Singleton Discussion
Old 01.03.2006, 07:50   #2
Грустно...
 
Agregat's Avatar
 
Join Date: 08 2002
Location: Там, где всегда идут дожди
Age: 42
Posts: 21,717
Rep Power: 9
Default Re: A Singleton Discussion

Зайцу не надо знать о том, что такое игра. Более того, он не должен знать, как и зачем его рисуют. Он должен экспортировать mesh, а дальше RenderManager должен заниматься тем, что по очереди рисовать все объекты. Более того, только рендерер может знать что рисовать, а что нет - так как только у него есть правильный З-порядок. А заяц, о своем порядке знать не долже. Ну и т.д.

Re: A Singleton Discussion
Old 01.03.2006, 20:49   #3
Easy rider
 
Silver's Avatar
 
Join Date: 11 2005
Location: tristeza
Age: 39
Posts: 1,082
Rep Power: 0
Lightbulb Re: A Singleton Discussion

So am I getting you right that a better design would be splitting all entities existing within the scope of the task into 'Data Containers' (CMesh, CHuman, CRabbit...) and 'Action Performers' (CRenderer, CWalker, CDLLManager, CLogger...). But then again (if that's what you mean), aren't all 'Action Performers' singletons by their nature?

Also another question, if a bunny lives in a specific world, I assume he knows how to live in it. I assume he knows how to handle other animals on the same world, how to eat the grass growing on that world, how to draw itself and how to have sex with any other creature, that's at least how it seems natural to me. I want to think of a bunny as of something more than just a bunch of parameters, something that makes use of the world it lives in for the survival of its own, the way its programmed to use it. Isn't that how the real world is constructed? I am too unexperienced and the opinions I express could seem too immature, though. Why not give all the objects all the knowledge about the entire world (like in the real life) and limit their ability to modify it merely by the implementation of the specific creature (like in real life)?

If the universe logics solely exists within some CUniverseLogic(), we can't hope to expand it later by adding revolutionary creatures to the world - can we? We'll have to modify the universe logics core. Go deeper with this, please. Also, if anyone could advise some good reading, that'd be fantastic. Thanks a lot.

Re: A Singleton Discussion
Old 02.03.2006, 07:41   #4
Грустно...
 
Agregat's Avatar
 
Join Date: 08 2002
Location: Там, где всегда идут дожди
Age: 42
Posts: 21,717
Rep Power: 9
Default Re: A Singleton Discussion

Заяц не есть контейнер - заяц есть заяц. Так как у тебя может быть миллион зайцев.
Заяц должен уметь Есть, Срать и Трахаться. У него должны быть соответствующие методы. Он должен уметь есть траву и не есть мясо. Но он не должен уметь себя рисовать. Так как заяц сквозь сеточные глаза пчелы и в моих глазах выглят по разному. Рендерер должен определять как выглятит тот или иной заяц в разных контекстах, а вот форма у зайца есть - поэтому меш он должен экспортировать.

Re: A Singleton Discussion
Old 02.03.2006, 07:50   #5
hex god
 
Griffon2-7's Avatar
 
Join Date: 03 2002
Location: Yerevan, AM
Age: 46
Posts: 3,172
Rep Power: 0
Default Re: A Singleton Discussion

Quote:
Originally Posted by Agregat
Так как заяц сквозь сеточные глаза пчелы и в моих глазах выглят по разному.
Держите себя в руках, Виктор! Держите себя в руках!

Re: A Singleton Discussion
Old 02.03.2006, 08:56   #6
Грустно...
 
Agregat's Avatar
 
Join Date: 08 2002
Location: Там, где всегда идут дожди
Age: 42
Posts: 21,717
Rep Power: 9
Default Re: A Singleton Discussion

Держу. Стараюсь, по крайней мере!
Reply




Реклама:
реклама

All times are GMT. The time now is 12:13.
Top

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.