Designing Interfaces

Started by
5 comments, last by Rocket05 20 years, 3 months ago
i''ve finally reached the stage where I realized that designing your programs extensivly before jumping into code makes for much more successful programs. I''ve been researching design patterns, UML, and other general software design techniques, but i''ve yet to find any information on desiging interfaces. Obviously, interfaces are usually very implementation specific, but I was wondering if there were any general techniques for realizing what all is needed, and how to pack that functionalilty into a handful of methods (something kind of like the is/has technique for desiging class inheritance/fields).
"I never let schooling interfere with my education" - Mark Twain
Advertisement
One thing that I will probobly do when I am ready to work on the design for the interface for my game, is do a very rough sketch in a somple GUI frendly WYSIWYG program like VB. There will be no code, or maybe just enough to transition between the different menus and thats it.

I think this is what you were asking anyway...

Dwiel
Heh, please pardon me for not being clear. By interface, i meant code (class/object) interface, not user interface

thanks anyways for attempting to help, Tazzel3D
"I never let schooling interfere with my education" - Mark Twain
"Use cases" for discovering what software needs to do.
CRC cards or equivalent technique for which class does what.

That''s what we do anyway.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley
To be somewhat more informative:

Use Cases
CRC Cards

Personally, I just think about it and start writing. If I'm having trouble getting something to work, I remember to consider the possibility that my interface design was wrong.

And always always remember to refactor! This includes refactoring interfaces. Of course it's often best to aim at the easy targets first, but don't be afraid of big refactorings either.

[edited by - Zahlman on January 14, 2004 7:50:37 AM]
If you''re making an interface that''s designed to swap out the underlying implementation rather easily (ex: making a graphics class so it switches between OpenGL and Direct3D fairly seemlessly), then don''t have your interface tied to API dependent details. Abstract it enough so you really aren''t concerned with what''s happening under the hood, so to speak.

I''ll agree with Zahlman and say that writing stuff out on paper is a pretty good way to go about it. Just start jotting down ideas that come to your mind, listing the different specs and tasks for your interfaces. Working things out on paper first saves a lot of headaches when it comes time to code.

And don''t be afraid to scrap ideas for new ones. If you think you have a better idea of how to do something, start doing the paper thing again until it starts coming together.
Actually, by "writing" I meant the code - I almost never put things down on paper, but I cede that such technique probably doesn''t work for everyone. I just find it easier to keep things in my head, most of the time.

This topic is closed to new replies.

Advertisement