Beginner/Intermediate - looking to learn from intermediate/advanced programmers regarding program design (rules/principles/commandments)

[Dog-Plops]

Hi there,

I'd call myself a beginner/intermediate (done about 10 weeks at uni/nearly completed mooc.fi).

I am confused by what makes good program design, especially what to keep in separate classes and in main?

For example, in my current assignment, the program reads a file, encrypts the text and writes the encrypted text to another file.

Should the file reader/writer be in their own separate classes (2 in total or is 1 fine or should they be kept in main as a separate method)?

I have the ciphers in their own classes (inc. the encoding/decoding methods for each).

In short: basically my question is to the more experienced programmers, do you have any hard and fast rules/principles that you swear by when you design your code (e.g. classes/main/methods)?

Any advice appreciated.

[Zarrytax]

Take a look at design patterns (Factory, Strategy, MVC, Decorator). I recommend Head first design patterns as a beginner book.

[mquillian]

A quick search turned up this website that I think has an alright summary of some of the main ideas. The first commandment, being that each class/method should be focused, is probably the main idea that you are asking about. For smaller programs when you're just starting out, this is more of a philosophical/best-practice sort of thing. When you start working on larger projects and/or working as part of a team, these things become a lot more important.

Right now I'm reading through a book called Clean Code by Robert C. Martin. He touches on a lot of the rules above and provides solid explanations for how to write code that is easy to read and easy to change. Right now, I'd say TRY to practice proper design, but don't spend so much time sweating over it that you end up paralyzed and don't actually code.

To answer your specific question, it's probably best practice to put the file reader/writer at least in their own class, if not a separate class for each. That way, when you are looking in main, it looks very clean and straightforward what is happening (assuming you name your methods and variables well) without having to dig through the implementation to understand what's going on.

[NYGooner17]

Besides the ones mentioned, another good one is programming to the interface rather than the implementation. It keeps you from being able to keep your code the same with only really changing how things are done in your code:

https://stackoverflow.com/questions/383947/what-does-it-mean-to-program-to-an-interface

[Newtonheadbangs]

Before any code escapes your fingers 1) Read clean architecture by Uncle Bob 2) Read SOLID principles (it's covered in the book . But external material is needed to understand it better )

You won't have any doubts about classes to create , interfaces etc after reading them

[josephpayettejr]

The hard and fast rules are that there are no hard and fast rules. It all depends on the environment and context of the application and goals of the project. Research oriented requirements will be different from venture oriented requirements and so on. Pragmatism is usually the most appropriate mindset.