Form object question

Question

Does anyone have any hard and fast rules about what kind of code the form object should handle as opposed to letting the object itself handle it? For example, if there is a race, should the object that is racing say, horses, handle the race as part of being a horse, or is it better to place that inside the form object? I guess what I'm asking is how one decides what goes into an object like a horse as say a method, and what goes into a form object instead of a horse. Are there any rules you use to figure out where code is best abstracted in this case?

Answer 1

This is called "separation of concerns". Let the form handle the display and user interaction. Let the Racer handle racing.

Answer 2

I try to develop my software so that core functionality that is not UI dependent is abstracted into classes that bear responsibility for their tasks.

Try to think:

How could I write this so I could have both a GUI interface and a console interface without duplicating any code.

The UI should only handle visuals & user interaction. Everything else should be organized based on its role.

Answer 3

Not sure there is absolutely a right answer here. But agreed with John Saunders. A "Form's" job is primarily responsible to display data to the user and accept data input. The closer you keep it to that, and that alone. Think about when there's another place for this type of data to be used, if the code is elsewhere, it can be reused.

Have a "Business Object" or a "Facade" handle the logic of the race, and the form to display it.

Answer 4

Try to represent things the way they are in the real world. Anything that describes the properties or actions of a horse, belongs in a horse object. Anything that describes the properties or actions of a race (including, perhaps, a collection of horse objects), belongs in a race object. A form is not a real world object, but just a gadget for displaying information from horses/races/whatever. So don't store anything with the form except as needed to present the real data on the screen.

Answer 5

Since the form is part of the UI I would apply my UI hard and fast rule: UI = formating, sorting and displaying data plus accepting and verifying input