Should only static functions print to screen?

Question

My question is more about trying to figure out if my belief is correct or valid in that a static method should be the only one that prints to the screen (let's say in a terminal). I am using Java and have a static method main and use objects either from my utility library or from my class itself.

The idea is that, just like how I can pass an exception from the object to the main method, such as File Not Found and let the main (or other static method) handle the exception instead of handling it myself and possibly writing it to the screen without knowing what the calling method wants to do.

Is there an reason not to have this hard requirement against printing to the screen (such as the terminal) as an object? If not, how come languages such as Java allow me to be able to print to the screen as an object?

Edit: I don't believe this is a possible duplicate because I am not asking which methods should be marked static, instead I am asking if I should only print to the terminal in a static method and never do so in objects.

Answer 1

I think there is no widely known principle stating that only static methods should print to screen.

For example, a CLI app can have injected loggers inside its' objects. Such loggers would print to a file by default, but by setting a parameter you can turn a "debug mode" and inject an screen logger instead. In such a case the loggers, which are not static would print to screen.

There's a principle though that recommends that only the presentation layer should print to the screen (MVC), but there could be exceptions, like the example I gave above. The presentation layer is not necessarily composed only of static methods. So it is not really a matter of whether or not the methods printing to the screen are static, but whether or not the methods printing to screen belong (conceptually) to the presentation layer.

NOTE: MVC was initially introduced for desktop / CLI apps to solve exactly that kind of problem. The concept was just later applied to web apps as well.

Although originally developed for desktop computing, model–view–controller has been widely adopted as an architecture for World Wide Web applications in major programming languages. Wikipedia - MVC

Answer 2

The short answer is "No". There is no general Java design principle which suggests only static functions should print to screen.

These types of decisions have to be made at the project design level. For instance, if you as a software engineer / designer you may come up with some reason that for your project it makes sense to restrict output to static methods. But I cannot imagine why someone would make this design decision.

In your question, you talk about throwing an exception from a method call "up" to the main method / static method and doing the business logic of "what do we do now?" there. This is reasonable and appropriate, and it's why Java gives us the ability to define "throws". What you've stated is exactly right, your file opener object may be defined just for opening files, what to do when that fails is the responsibility of the caller.

While that's all true and fine, there's no rule that the caller must be a static method. For instance, you might have a static main method which creates a Database object, and that instance goes and tries to open a file. When that fails it (the Database object itself) may print a "failed to open file" message to the screen, and then proceed to try to create a database over a socket connection to some web server. This is hypothetical, but it's a real-world example of an object which was instantiated which both (1) handles thrown exceptions, AND (2) prints output to the screen in non-static methods. This is perfectly acceptable and very standard use of Java.

You as the designer and project lead, could tell your programmers, "Do not handle exceptions, and do not print to the screen. Explicitly throw exceptions from all of your method calls for everything and we'll handle them in main and only print from there." You could do this, but you should be fired if you do. That being said, there are really robust logging implementations, and even java has its own logging so you have a good level of control over what gets printed to screen / to log files, etc. It's better to just use your logging statements in a controlled and predictable way and put those anywhere you need them, whether that's static or non-static methods.

Answer 3

'Role' is what dictates the prescribed behaviour of methods

The gist of the explanation below is "No".

Being aware of your knowledge of the language restrictions (is it allowed or not), I assume this is more a question on the principles guiding a design, I'll try to explain in such terms.

The basis on which it is to be decided, if a method or even all the methods of a given class should or should not print to the screen, is Role.

Trying to follow the Single responsibility principle as far as possible, a class would generally either be one that interacts with users or one that doesn't interact with users. Only the classes that reside on the edge of the system (UI edge, not n/w edge) would generally be either printing to the console or GUI as designed, mind you these classes will be created only after the decision about UI (console or GUI) is made.

All other classes would generally exist to perform functions that assist in intermediate stage of the result being formed. If they face a situation where some unexpected information needs to be shared outside, they should preferably use channels like logging, raising exceptions or returning error values. This can then be consumed, interpreted and shared outside to the user, as per the decided interface.

For instance, if I create a math library which prints out a message to the console when it faces divide by zero scenario, it would need to be re-written if I later want to use the same algorithm/library for a GUI based environment. This would be in disregard of the concept of modularity/reusability, a major pillar of OOP. Note that the 'role' of my math classes is to perform calculation and not to present it to user. There should be a different class that handles the job of interacting with users. This other class (or set of classes) would deal with how to present it to the user (Console/GUI), how to format/display it (Text/Tables/Graphs/etc).

This is a direct outcome of considering two of the class designing principles namely, Single responsibility principle and Interface segregation principle, in order to avoid indulging in fat interfaces.

Hope that doesn't sound rather vague.