There are of course a hundred (thousand) ways to do it but i
like the ObjectFactory Model where you have a master class that creates instances of your various objects, it makes it really easy to manage your collections and to apply all your various validations, which rolls right into your next big project, a well thought out and super-powered debugger class, which turns your automation errors into read-able text.(a must)

Good Luck

Some advice I would give is to perhaps consider writing what I call a "mini engine". This is an engine which encapsulates the following:
graphics routines (startup, shutdown, draw, clear etc.)
resource management (for textures, sounds, models, sprites - you can write a general template resource manager and instantiate it with a different type to create each kind of resource manager),
sound routines (startup, shutdown, play etc.)
camera routines (which might interface with the graphics stuff but should probably be kept separate).
basic physics.

this isn''t a full fledged engine but it would allow you to write some cool stuff and you probably won''t get too bored along the way.

I tried to write a full on engine earlier this year but got bored quickly because of the size of the task. Also I now realise that it was too much of a leap to make from the last game I''d written.
Now instead I''m building such an engine I''ve described above and will use it to make a 3d space shooter.
The good thing about this is it doesn''t involve a lot of other issues which would complicate the project and distract me from the actual game side of things.
Writing a BSP/PVS compilation tool (which I''m still trying to finish) is a hell of a lot more boring than programming a "game".

Keep it small, the biggest problem most people have it trying to do too much at once. Many hobby game programmers it seems start to write their first 3d engine and try to do too much. they get bored with it and then throw the whole thing away and perhaps never even come back to game programming.

Just my overstated opinion
Toby

Gobsmacked - by Toby Murray

Toby has it right, especially if it is your first time. Pick some basic features you would like, in your case if it is your first engine, seeing anything. Then hack, and hack your first game together. The important thing is that you finish it. Do not waste too much time on design for now, just hack it together.

After you finish, or do not finish, you will not only have a complete game you can show people, but you will have a sense of how a whole project''s architecture might work. Repeat. Keep hacking, but because you will have more experience, you will notice that your next engine, and game architecture will be better designed.

Design is good, and I will not argue it. Just do not fall into the trap that so many do, and never finish a project because you are too stuck on getting it perfect the first or nth time.

Oh yea, your original question.

1) Your first question had two common ideas.
A) Pass throughs. Instead of having one class with many different sets of unrelated methods, you may want to consider having the class support several interfaces. Of course, this still means the one source file will have the implementation of all the functions.
B) To save having the passthroughs/interfaces, you can get a pointer to the member itself. This is looked upon like a global to some, and they treat it as a singleton (several articles here).
As alsways, it comes down to personal choice, and the ONLY way to find out the correct way is through experiments. Pick a way. Roll a die. Just decide, and do it. If it works, great for you! If it does not, then you learn, there is no PERFECT design. Some books call it a Silver Bullet. It does not exist.

Second question, this again will be different for every person. Before, I tried making one class that wrapped everything I needed out of DX, just like I did when I was doing software renderers. However, as my tasks changed, my architecture changed. In the end you will have to make some sort of wrapper. DX is a wrapper in itself really. The sort of wrapper you will make depends upon your project. This again comes through experience and what you need.

First, you must ask yourself, what part of the DX library do I need? Graphics? Sound? Input? Etc. It is pretty huge.
Then ask yourself what sections of each part do you care about?
For your first project, keep it simple (KISS). Choose an EXTREME subset, and just make something work, finish a project.