Making a layer

I'm probably not one to advise about code design, but maybe looking at the Facade design pattern will give you some ideas.

Quote:

Original post by Gage64 I'm probably not one to advise about code design, but maybe looking at the Facade design pattern will give you some ideas.

Thanks, I'll take a look at it, I think It could be used to provide an interface like structure, but it would be nice if anyone knew ways to make actual layers.

An abstract interface with a set of various implementations is how you create layers.

Think about it this way. You have a plate with holes in it. Every hole is a different shape. These shapes are the abstract interfaces. It doesn't matter what you fill that hole with, so long as it is the right shape. So, to fix in the octagon, you make a red octagon, and a green octagon, and a yellow octagon. Then you use one of them at any given time, changing it out based on what the other side of the octagon has to connect to, such as the O/S access libraries (one O/S is red, another is green, and maybe you have a debug implementation for the green O/S which is yellow).

Layers don't get "constructed"... you design the components based on what they need, and then you hook them up to other components that provide those services or that data, and layers begin to appear based on the design.

Quote:

Original post by Wyrframe An abstract interface with a set of various implementations is how you create layers. Think about it this way. You have a plate with holes in it. Every hole is a different shape. These shapes are the abstract interfaces. It doesn't matter what you fill that hole with, so long as it is the right shape. So, to fix in the octagon, you make a red octagon, and a green octagon, and a yellow octagon. Then you use one of them at any given time, changing it out based on what the other side of the octagon has to connect to, such as the O/S access libraries (one O/S is red, another is green, and maybe you have a debug implementation for the green O/S which is yellow). Layers don't get "constructed"... you design the components based on what they need, and then you hook them up to other components that provide those services or that data, and layers begin to appear based on the design.

But what if I don't need an abstraction layer? I don't want to make anything simpler or provide common grounds to talk to an object. But simply layers with dependence, so that the bottom layer handles windows, then the layer on top of it, uses bottom layer to get resources, such as files from windows, then the third layer, talks to the second and tells it how many and which resources to get. Maybe I'm not understanding something, can someone give me an example in code/pseudocode, because I don't even know where to start.

Layers are just an abstract concept. A set of things 'A' knows about a set of things 'B', but 'B' knows nothing about 'A'. There. The A layer sits on top of B.

Why would a "resource management" layer ask a "windows interaction" layer for files? That doesn't make any sense to me - they seem like orthogonal functionality.

Quote:

Original post by VanillaSnake21 But what if I don't need an abstraction layer?

Then *what* do you need? Abstraction is the *entire point* of layers. Explain exactly what you want from those "layers" of yours. From what you posted, it sounds you just like the sound of the word.

Quote:

Original post by phil_t Layers are just an abstract concept. A set of things 'A' knows about a set of things 'B', but 'B' knows nothing about 'A'. There. The A layer sits on top of B. Why would a "resource management" layer ask a "windows interaction" layer for files? That doesn't make any sense to me - they seem like orthogonal functionality.

It wouldn't ask it for files, windows management will handle stuff like window creating/ message handling/ and talking to windows - meaning that if the resource manager needs a file, it sends a request to WM layer, and it look for that file, opens it for reading, maybe stalling some other tasks, and gives it to resource manager.

@Barius

Quote:

Then *what* do you need? Abstraction is the *entire point* of layers. Explain exactly what you want from those "layers" of yours. From what you posted, it sounds you just like the sound of the word.

yea "layer" does sound cool [smile]
I guess I know what you mean - it is abstraction, over the past hour I actually though it through, and basically came up with what I think is layer-like code.

I define an interface as a class
Methods of this "class" are all pure virtuals.

#define interface classinterface IWindManagerInterface{public:   virtual void ReadFile()  = 0;   virtual void WriteFile() = 0;   virtual void MakeFile()  = 0;};class WindowManager : public IWindManagerInterface{public:     //overwriting    virtual void ReadFile()  { cout << "Read"; }    virtual void WriteFile() { cout << "Write; }    virtual void MakeFile()  { cout << "Make; } };interface IRManagerInterface {public:    virtual void AllocateMem() = 0;    virtual void DeallocateMem() = 0;};class RManager : public IRManagerInterface , private WindowManager{ public:    /// overwriting    virtual void AllocateMem()   { cout << "Allocating mem..."; }    virtual void DeallocateMem() { cout << "Deallocating mem..."; }};

Notice that i derived the RManager from WindowManger as private. Thats means that the layer above RManager can't directly access WindowManager, but only through RManager's methods.
Can you tell me if im going the right way, is this the layered design?

It's more like a scrunched up piece of paper than a layer.

There's no reason to have a resource manager and a window manager on the same object. They are separate entities. It generally does *not* make sense to implement layers of a design by class inheritance.

And, to me, it makes no sense for a resource manager to depend on a window manager. Of course, I'm not sure exactly what your resource manager does - but your code suggests that it might do something like allocate memory. How could it possibly make sense for a memory allocator to depend on a GUI?

I suggest you forget anything you heard about layers.

Quote:

Original post by phil_t It's more like a scrunched up piece of paper than a layer. There's no reason to have a resource manager and a window manager on the same object. They are separate entities. It generally does *not* make sense to implement layers of a design by class inheritance. And, to me, it makes no sense for a resource manager to depend on a window manager. Of course, I'm not sure exactly what your resource manager does - but your code suggests that it might do something like allocate memory. How could it possibly make sense for a memory allocator to depend on a GUI? I suggest you forget anything you heard about layers.

Ok, Windows Layer is simply there to handle interaction with the system. There is no GUI, I'm using DX for mostly everything. For example RManager needs a mesh, mesh is in "C:\MyMesh.x" I want to get that file. So RM will pass that request on to WM layer. It will check whether the file exists, whether the pointer is loaded fine, and give RM the raw file. RM doesnt have to worry about anything concerning Windows Interaction (I guess this is what abstraction is). WM layer will also handle something like interrupting the game for mayebe a couple of milliseconds in order to do some action or respond to a windows request arriving from some other app, or when the user minimizes, it will stop the game etc... Since the game is like a subsystem of the OS, i figured its important to provide a layer to the OS. BTW whats bad about the code? It seems like its perfect, I'm making layers and I'm restricting access to non consecutive layers by deriving as private.

EDIT: Maybe it's confusing because when I said WinodowManager, I actually forgot the "s" at the end of Window, so the layer is technically called Windows Interaction Layer - WIL