Graphics Library Class Design

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|131\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Concept/Design -> Graphics Library Class Design
Wed, 01 Aug 2007, 20:42
JL235	I'm working more on my Java graphics library. I'm trying to make it very simple by just wrapping lots of the stuff you'd want with games into a few simple classes. But I'm currently at a crossroad about the future design. Current it has full image, window and controls support. I'm already using it for making a few things. But I'm adding lots of features and I'm not sure how to proceed. The current features I'm implementing are border-less and full-screen windows. Both of my design ideas are pretty easy to implement, this is purely a design issue. This is the current inheritance tree where both GraphicsImage and GraphicsWindow are subclasses of Drawable. Drawable contains all the drawing code, which is the same for both classes. Option 1 I could make a 'GraphicsWindowDetails' class, which contains lots of options on how the GraphicsWindow will be when it is created. These options will include location, size, title, enabling borders, resizing and full-screen. The idea is that you create an instance of GraphicsWindowDetails first and then set up all the details of the window you are going to make. You then create a GraphicsWindow and pass in this details object. The advantages with this option is that there are less classes and only one type of window, GraphicsWindow. But the main advantage is that you could create an instance of GraphicsWindowDetails, set it all up, and then re-use it for making multiple GraphicsWindows with the same options. Like a default type of window. It would also allow for easier expansion of any future GraphicsWindow features, as I can just add it to the details class. Personally though, I don't like it when libraries use detail classes. It means in this case you now have three completely different classes to think about in regards to the GraphicsWindow class. Drawable for doing any drawing, GraphicsWindow in regards to the window operations and GraphicsWindowDetails for setting the window up. All play a very different role in the operations of the GraphicsWindow. Option 2 Create a general Window class, and then sub-class this with each of the main types of windows. The advantage with this is the simplicity, in that you just pick the type of window you want to use and then just make it. This option would also be quite easy to extend because any features for all three windows can be added to the Window class. It would also be easy to create any specialist window classes, for example a SkinnedWindow class. The downside is that it uses far more classes, but is that really a problem? Both options are pretty good, easy to implement and would both work very well. That's why I'm finding this choice so hard. Which would other people prefer and why?
Thu, 02 Aug 2007, 00:46
power mousey	Diablo dude, I like option #2. several variants of the Window class. True!! subclass,subclass,subclass. ahhhhhhhh! cheers, power mousey
Thu, 02 Aug 2007, 04:02
Jayenkai	If this is all simple background stuff, then surely the method doesn't matter to the end coder, right? I mean, if you sit there and code a simple "Blitz - Graphics" like function, then build up a crapload of possibilites, then that'd be enough. width, height, + ,1 fullscreen ,2 windowed ,3 windowed scalable ,4 borderless ,5 borderless with mask (for skins) Then it really doesn't matter at all to the coder how you've done all that. For "Window Flags" use a second command, so it's possible to change the window's parameters mid-program. (assuming windows can do that!!) Note : I am, of course, assuming you're doing this for the sake of other coders, not just yourself.. If you're only doing it for yourself, then go ahead and be lazy, and just use option 1! Decide what you need, then code for that, and stop worrying about how others will percieve your code.. It's better to get an end result than to spend 2 weeks deciding on how a window should be drawn. -=-=- ''Load, Next List!''
Thu, 02 Aug 2007, 09:17
Scherererer	Personally though, I don't like it when libraries use detail classes. It means in this case you now have three completely different classes to think about in regards to the GraphicsWindow class. Drawable for doing any drawing, GraphicsWindow in regards to the window operations and GraphicsWindowDetails for setting the window up. All play a very different role in the operations of the GraphicsWindow. well, to solve that problem you could always provide constructors that avoid GraphicsDetail class usage, and then add accessor methods so that you can copy over the GraphicsDetail to another window. So your contructor list might look like this: location, size, title, enabling borders, resizing and full-screen public GraphicsWindow(GraphicsDetail detail); public GraphicsWindow(String title, Point size); public GraphicsWindow(String title, Point size, Point loc); etc... --v with accessors public GraphicsDetail getDetail(); public void setDetail(GraphicsDetail detail); --v I think the second option is good for people that want their own custom classes though, because I always felt that was one of Java's strong points in their libraries was very inheritable classes. Are you going to make GraphicsWindow abstract or is it going to be usable as-is? -=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
Thu, 02 Aug 2007, 09:49
JL235	I would like to point out both options would give the exact same functionality. This is purely about the interface of the GraphicsWindows. This is simply a case of if you want to write: GraphicsDetails details = new GraphicsDetails(); details.setSize(640, 480); details.setTitle("my program"); details.setResize(false); details.setFullscreen(true); GraphicsWindow g = new GraphicsWindow(details); --v or: GraphicsFullscreenWindow g = new GraphicsFullscreenWindow(640, 480, "my program"); --v Although this uses far less code, if you wanted to change from fullscreen to windowed it'd be far easier with the details option. With the second option you'd have to be creating a completely different type of class. @Instinct: I was also thinking of keeping some easy constructors for the GraphicsWindow class. I would also be making an abstract class called either Window or GraphicsWindow which would be the super class for all the types of Window.
Thu, 02 Aug 2007, 12:44
Phoenix	I think that you should make a GraphicsWindow class and merge the GraphicsDetails with it. GraphicsWindow g = new GraphicsWindow(640, 480, "my program", true); g.setFullscreen(false); GraphicsDetails gDetails = g.getDetail(); --v In other words, what Instinct said By the way, which program did you use to create those diagrams?
Thu, 02 Aug 2007, 13:07
JL235	I made the classes in BlueJ and then print screened them. When you make a class it appears like that, with arrows showing how your different classes interact. Quite useful, but I am using NetBeans (which has a BlueJ plug-in) for coding. With that suggestion Phoenix I could get rid of the details class completely and just have a single GraphicsWindow class with lots of methods for changing how it works. The good thing is that it's easy, but the con is that when a GraphicsWindow is made it's all set up and appears for you. To then change it to borderless or fullscreen means setting up the window again. To the user if they made a window and then set it to borderless, it would first open and appear as a normal window. Then disappear, then reappear as a new borderless window. One solution to fix that would be to have the window hidden and the user have to make it shown, something like: 'window.setVisible(true)'. I'd rather not continue down this route because one of the intentions of my library was to have creating a window be as easy as the 'Graphics(640, 480)' of Blitz.