Procedural configuration code to object oriented code

Question

Lets say we have an Webserver-Framework and a Database-Framework, and now i want to configure that Webserver and the Database, then it could look like the following

class Start
{
 public static void main(String[] args)
 {
 new Start().start();
 }
 public void start()
 {
 var dbb= new DatabaseBuilder();
 dbb.port(...);
 dbb.adress(...);
 dbb.user(...);
 dbb.pw(...);
 dbb.xyz();
 
 var myDb = dbb.build(); 
 
 
 var wb=new WebserverBuilder();
 wb.port(...);
 wb.address(...);
 wb.securityPolicy(...);
 wb.sslCert(...);
 wb.xyz(....);
 ...
 
 wb.router().path(...).do(...);
 wb.router().path(...).do(...);
 wb.router().path(...).do(...);
 ...
 
 myWebserver=wb.build();
 
 myWebserver.maybeSomeMoreConfiguration();
 myWebserver.start();
 
 }
}

So now i can refactor that start-method in the example into more methods here in the Start-Class.

But then i want to move this new created methods into own classes.

So my Question:

• Is that a good idea doing this like so? Or are there better/other solutions getting object oriented code
• How to call this classes where i put in the methods (one method into one class)?
• This classes will then hold only one method each, and are more or less stateless. Is that really the right way?
• Are there any Design-Patterns out there, where this problem is described and solved? I didnt found one, but exists there problem-similar patterns?

• Robin Kreuzer 2: As @Doc Brown wished, this time its a question with only main-question, refactoring a procedural main-method configuration code to different components/classes, which should be then be object oriented..... and it has an example.
• John Wu: If you have a class named Start (or any other verb) you might not be using object-oriented thinking. What noun does this class represent to you?
• Robin Kreuzer 2: Of course that is not object oriented in that example, but the aim is getting object oriented code out there. The Start-Class is with its Java-Main-Method the entry-point class
• user949300: One note: I'd use JSON or XML or YAML or whatever you prefer to do as much of the "easy" configuration stuff as possible. Have the Builder start with that file.
• John Wu: @RobinKreuzer2 I asked you what that class represents to you. If you can answer that, I think it will help you find your own answer. Perhaps (for example) it represents an Application. In that case it might contain other classes that represent your database, your web server, etc. which could be member variables. And it could have a start or run method, which in turn could call the methods of the database and web server objects to initialize them. The point is to get away from treating classes like methods.

Answer 1

It seems you have the idea of making code more "Object Oriented" improves a system automatically, and "more classes" = "more OO". But that's fallacy. If adding extra classes just complicates things without bring any benefit, then it becomes overdesigning.

This is mind, let me give you some direct answers here:

now i can refactor that start-method in the example into more methods here in the Start-Class.

Fine, that looks reasonable for me.

But then i want to move this new created methods into own classes. Is that a good idea doing this like so?

If the code is as simple as you have presented it in the question, I don't see any reason why one should add an extra class which only holds one relatively small method. This only adds unnecessary complexity.

Situation becomes different when the refactored "StartWebserver" or "StartDatabase" methods will become so longish that it pays off to split them into smaller methods - then would be a good time to refactor to classes, where the class has just one public method but multiple private ones which are called from the public one.

Or are there better/other solutions

Yes. Don't do it (at least, not yet).

This classes will then hold only one method each, and are more or less stateless. Is that really the right way?

If it is really just one method, not even additional private ones, then it will add most probably unneccesary complexity.

How to call this classes where i put in the methods

Assumed the code will evolve to the point where extra classes become sensible, you may pick a name like DatabaseStarter or WebserverStarter, However, this is pretty opinionated, and don't forget, currently you don't need those classes.

Are there any Design-Patterns out there, where this problem is described and solved?

The question did not state a problem. You seem to have found a tool ("classes"), and now you are looking for a problem to solve with it. But using classes is not an end in itself, it is a means for an end. Use classes when there are enough functions and state that it makes sense to bundle them and create an abstraction on its own - and don't do it for every small single function.

• Phill W.: "using classes is not an end in itself, it is a means for an end." Absolutely agree! (Ditto "Patterns"; the new-fangled labels that people are now giving to the way we've been writing code for decades!)

Answer 2

The question is: will you have any benefit from using classes. A class is a template. If you have more than one instance at the same time, it maybe worth using classes.

Or you have internal structures in different objects, that are very similar, but not identical. Then you can use classes and inheritance to avoid redundant code.

But if you can do something with a simple procedure and two variables, it is possibly not worth using classes.