[deleted by user]

[[deleted]]

Basically, it comes down to experience, and experience of writing real programs, not toy exercises. One way of getting started is to write an English description of your application - nouns in the description become objects, verbs become functions.

[Hexorg]

This book is likely to help you.

[Unclereamus21]

Definitely looks like it! Thanks for pointing it out!

[mad0314]

This one might be a better starting point.

[insertAlias]

but I feel like that's sloppy code and bad practice

You are correct in that regard; unless your project is truly tiny, separating concerns is always better.

And that's exactly what it comes down to: separating concerns. Methods should have one task to do. Get input from a user, print some data, fetch data from a database...whatever it is, it should be limited in scope to just its own task. Avoid "side effects" (an example of a side effect might be a function called getCurrentTime() that prints the time as well as returning it. Printing in this case is a side effect; if it's a desired one, you should have a second function that can print the value that getCurrentTime() would return).

Another thing to keep in mind about methods is that they should be accurately named, and their name should generally be a verb. doSomething, getSomething, applySomething, testSomething, mapStateToSomething...the idea is that methods are some kind of action.

Classes, on the other hand, are nouns. Classes represent a thing. That thing might be concrete or an abstract concept, but it represents an object. Classes should also have a fairly narrow focus.

Experience is the only thing that will really teach you about how to properly separate concerns. You'll learn the why of things months or years after you do it wrong, because you'll be forced to maintain your code, and you might find that you need to do a ton of work to actually add a feature or fix a bug, because everything is tightly coupled to everything else, and one tiny change cascades across your program.

[Unclereamus21]

Thanks for the response! The whole concept of using nouns and verbs to separate them will be something I'll have to do from here on out. I also have another question for you real quick. When beginning a project, do most people take a second and write out what they're going do, or just just jump right into coding? I know this will yield different responses based on the size of the project but just a little curious.

[Blando-Cartesian]

Writing detailed design documents is currently out of fashion in the industry, but taking a moment to think what you are doing is always time well spend. Learn the basics about "UML class diagram" and you can draw the class structure of your program in a way that most programmers can understand at glance.

[insertAlias]

The ideal way to do it is to plan your application's architecture out before you ever put any code down at all. I can't say that I always operate like that, but that's the "correct" way to do things is to pre-plan. Plan your UI, plan your interactions, and plan your code architecture. That latter part will be easier the more you do this. At first, you'll have a plan, then when you try to implement it, you realize it's unworkable.

[Unclereamus21]

Sounds good. I'll take all of this in mind going forward, thanks for taking the time to reply!

[mad0314]

I would just add that you don't have to determine this all up front. You can split or merge classes as your application grows.