Code reuse is a really big deal. If you have methods that manage the same process repeated in several places, then any change has to be repeated with each method. And that's if you remember where each one is located. Chances are great that you'll miss one. Definitely keep functionality in one operation. Again, a lot of this depends on how you design your objects. If, for example, you create a factory class that creates a complex object, then you have all of that object creation code in the one class (Single Responsibility Principle). Any time you need to create the complex object, create an instance of your factory class and call it's Create()... or whatever... method. No need having to repeat the creation code. Object Oriented Design (OOD) means treating each class/struct like its an object that's capable of interacting with other objects. If the function would have to be repeated with similar objects, then inheritance can be used to ensure that the function is still in one place in the base class. For example say you have three classes Employee, Manager, and Intern. You don't want to repeat a property that queries and returns their mailstop in each one. But since each carry the same principle properties and methods, they could all three inherit from a Person class which would have the MailStop property and the other three would automatically inherit it. Most of the time you can isolate your code for reuse. Anything short of those rare exceptions I believe can create a mess down the road.
Another principle to consider is Inversion of Control. IoC is a term that's been around for ages and depending on the type of development work you do can mean something slightly different. But the point I want to get across is the idea that you don't build a class that manages the processes in one step. That alone breaks SRP as well as Open/Closed principle, etc. With IoC you design objects that encapsulate the functionality it's designed to manage. Either at the application level or with a Service class you can manage the process by instantiating objects and calling the appropriate methods at the appropriate times. Effectively inverting control from the top down to the bottom up. Since you're just beginning, don't worry about all that. Just remember that an object decribes an object: Properties are attributes of the object and Methods are the actions an object can take. From there learn how to create instances between classes and call the operations you need.
