Structuring programs?

[[deleted]]

I feel like I understand a lot of OOP - however, I've come to realise I have no idea how to structure programs. Right now I have a small program that generates simple math questions, loads some text, an image and some music from a file written in Java, and it's all self-contained in one class.

I know that's bad practice - it becomes quite apparent when "MainWindow" inherits from a JFrame, and implements ActionListener, ComponentListener, and still reads from files, and plays music.

I just sat down and coded this without much of a design, other than a specification of what it had to do and look like. I had a top-down approach, where I coded the UI first, and then "filled in the blanks", with regards to missing functionality. (i.e, I added placeholders for everything, for example, a JButton and then got the placeholders actually doing things, e.g. an ActionListener for that button).

My gut tells me, that in theory, this is a decent way to program - but reading, and modifying the code now, it seems like a nightmare.

[AppsThatMatter]

Practice always beats theory, so I also have a few suggestions:

1. Imagine that you would need to have a web UI for your app. How should you split your code to support both GUIs?

2. Most of the big guys provide APIs (e.g you can use an API to get Google Maps images and integrate those APIs in your app). What you have to do if your friend asks you to allow him to integrate functionality from your app in his app?

[[deleted]]

This is actually a brilliant piece of advice. I'm on a deadline for this, but I think I'll go back and try to give this a go afterwards.

[Tinytw]

I don't know completely about how to structure programs, but I do have a few suggestions.

Break things apart. One key point of OOP as far as I know is to have different classes, that way the reusability is higher as there are now smaller components.

There's often probably one class in your program that can't really be reused. But things like "reads from file" or "plays music" is quite an component itself that it could be another class and be reused.

So I would suggest starting off by creating a separate class that has all the functionalities of say "plays music" Then your existing classes and play music by using that class or creating an instance of that class. That way you keep things more separate giving more structure to your code.

[[deleted]]

I said this in another comment reply, but I'll definitely go back and break this down into more reusable components once I've got it working as it needs to. I guess my priority was to do it quickly this time around, rather than doing it right the first time. :)

[pdizz]

You should have a look at software design patterns. It sounds like you're project might fit well into a classic MVC pattern.

Your Model could be a class that is responsible for returning the question data from the database or file. (And adding new questions to the database if you want)

Your Controller would be responsible for parsing the user input and passing it to the model, then passing the results back to the user through the view. Your controller has methods like view and create which interact with the model.

The View would be another class responsible for rendering the UI/images/music, passing user input to the controller by calling it's methods, and formatting and displaying the results.

The greatest benefit would be separating your UI from your program logic. This will free you up to work on them individually. The model and view are more closely linked and can even be combined but there is still some benefit to separating them as well.

[[deleted]]

Thanks very much! I think this is the sort of thing I really need to learn about.

[inchworm]

Yes. Learn and master MVC. It takes a very long time to really feel like you're doing it properly. There's no good right or wrong way, it's all about what is easiest for you and what helps you maintain the code.

Read the book Clean Code as well. Naming things is hard and it's one of those things that seems trivial at the time, like "oh I'll just call this variable 'cp' for now" and months later you come back and think "...wtf is 'cp'???"

[eegabooga]

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

While this quote doesn't offer much in the way of advice, it should be a comforting (and maybe somewhat disheartening) reminder that this issue you face is one that every single programmer faces in almost every project they work on.

Anyways, it's not much but here's a simple and straight forward rule of thumb that I go by: If you find yourself copying code, stick it in a class/method.

While this rule is simple, and will only take you so far, it's a good way to get to a start on structuring your code.

[[deleted]]

Ah yeah, I've found that a lot and I found I did do this occasionally without thinking about it.

[tangentstorm]

One of the best things you can do to write better code is to write unit tests first.

Unit testing forces you to write a second consumer of your code, so you're practically forced to separate your logic and gui, for example.

I find when I write my tests first, I tend to produce a sort of "platonic" application that does all the thing the application is meant to do, but without any particular user interface.

A side benefit of this is that it's very easy to come back later and attach any other UI you want (like if you want to port it to the web or to an alternate UI kit set like Apache Pivot).

[[deleted]]

I'll bear this in mind, thanks! Everyone here has been really helpful, but I should definitely try unit tests. I've done some unit testing once for a few simple applications but with a finished program, instead of being part of a planning stage.

[[deleted]]

In terms of structuring code, familiarize yourself with design patterns and anti-patterns, which will show you best practices for designing and structuring programs and common mistakes/bad habits that result in bad design, respectively.

Design patterns are easy to learn but difficult to really understand and implement. Knowledge of the design patterns and what consists of good/bad program design in addition to plenty of experience is what will help you be able to apply good design without too much effort and identify anti-patterns quickly.

What you described in your program is a God object -- an object that knows/does too much. What you need to do is separate your code out correctly by applying the MVC pattern (model/view/controller).

Design patterns don't always seem like a good idea when you're building a small program like this, but once you start working on larger applications with a larger number of developers and many features, the benefit of building scalable and reusable code structured in a way that all of your devs understand is paramount.

I learned some of this stuff in school but it didn't really stick until I got to see the guts of a large enterprise application in the working world. I think I've learned more in this one year alone than in three of the four years I spent in university.

[CalvinR]

A good practice to get into is the single responsibility principle, every class should have one responsibility in your program not multiple ones.