1. Creating/copying a design
2. Deleting a design
4. Accessing a design by id (other parameters to be added as needed)
6. Loading predefined designs
7. Saving and loading available designs for a "running" game
These sound reasonable, although note that there is a distinction between deleting a design entirely from the game, and an empire deciding to remove the design from its available designs (which might be replaced with obsoleting, now that I think about it...).
3. Obsoleting a design
8. Filtering the design list by empire (Ultimately abstracting the way the "designs per empire" is stored, which is mainly what I meant by abstraction) , active/obsolete, hull type/size and other params as needed (Can colonize? Combat? Transport?)
Point 3 and the part of 8 about changing how designs an empire has are similar (ie. storing which designs an empire has access to, and which of those the empire considers obsolete). This might not be a good thing to *store* in a ShipDesignManager, though. Right now, which designs an empire has are stored within that empire, and presumably if obsolescence was added, it'd also be stored in the empire. This makes sense because these are logically a property of the empire, rather than of the design itself.
For example, it would be easier for tracking what information one empire knows about other empires to keep this information within the Empire class. There will probably eventually be a map<int, map<int, Empire*> > in the gamestate. This would be a map from empire1 ID to: map from empire2 ID to Empire object, where the contained object is the information about empire2 that empire1 knows. What ship designs empire2 has would be important information to track, so that espionage could be used to find out this information. If you stored the information about what empires have access to in a separate DesignManager class, you'd also have to separately track what other empires know what empires have access to those designs, which seems to needlessly complicate an already complicated situation.
Also, if you want to track which designs which empires have, storing that in a separate DesignManager class could be awkward, because if an empire was removed from the game, you might then need to loop through all stored ShipDesigns and update them so that they aren't owned by the nonexistant empire... But then you'd lose the historical information that the removed empire had access to that design before it was destroyed (whereas if stored in the empire, you could leave the information in place and just flag the empire as removed, as occurs now). Alternatively, one could leave the data in the DesignManager that the removed empire had access to the design in question, but that might be misleading if one is looking up which / how many empires (implicitly still in the game) have access to the design... Which probably isn't as big of an issue as I seem to be making of it.
Anyway, what I'd suggest is, if you make the ShipDesignManager, it could provide convenient accessor functions to get all the designs owned by a particular empire or other filtering as you feel appropriate, but you should leave the information about what designs various empires have access to or have obsoleted within the Empire class. The manager can easily poll the empire class to find out what designs an empire has or has obsoleted, so the filtering functions can still be implemented.
5. Adding a part to a design
Although ship designs are accessible outside the ui, what I mean is that putting the "add a part" logic in the UI won't enable AI or other UIs yo use that logic without coping it.
You might be slightly misunderstanding the function of the DesignWnd::MainPanel::AddPart function. There actully isn't a ShipDesign object created until the Confirm New Design button is pressed by the player. ShipDesign actually has almost no way to modify it after it's been created. The way the design screen works is that a list of parts and a hull are created by the user selecting or dropping them into place. AddPart just tries to find a place to put a part without the user needing to specify which slot, and adds the part to the list of parts in the UI. Only after the Confirm New Design button is pressed is the list of parts and hull used to create a new, but temporary, ShipDesign object, which is then passed into a ShipDesignOrder, which is both sent to the server and executed locally on the player's gamestate, which adds a permanent copy of the temporary ShipDesign to the Universe's stored designs.
So, one / I could argue that AddPart is mostly a UI logic issue. Deciding where to put a requested part or how to rearrange parts already added isn't really a game logic concern, so much as a player design decision that is being automated... The use isn't actually for modifying an existing ShipDesign, but rather is for modifying a list of parts in the UI that may later be used to create a ShipDesign.
AddPart also probably wouldn't be of much use to AIs, as they'll need to consider the whole situation with all the available slots in order to find a way to arrange all the desired parts... AddPart is intended as a tool to aide interactive ShipDesign creation, which is not how AIs (I expect) would do the designing. For example, if writing a ship design creation AI, I wouldn't just use AddPart repeatedly and hope all the parts I wanted to add get in the design... Rather, you'd check the available slots, and decide on all the parts to add all at once, never attempting to add a part that wouldn't fit due to lack of suitable slots.
(could be in the design class i guess, but i think game logic should be in the managers, not the data classes)
I don't really understand this point. Presently, the content manager classes mostly store and retreive game content objects. Content classes, like BuildingType or ShipDesign, encapsulate that bit of content, which determines details of how game objects behave. Gamestate classes, like Building or Ship encapsulate the game state, and have various methods for modifying that state or interacting with other bits of gamestate, or are manipulated by the Universe or Server or Order type classes, which collectively contains all the various bits of game logic. I'm not seeing how game logic fits into content manager classes...
If you say that this isn't a good idea, I won't argue any further, add it to the UI class and leave the rest as it is.
A ShipDesignManager is not a bad idea, but some details of the scope of the class' function and the internal implementation need to consider the bigger picture.