Does it make sense to hide public static final constants and make a getter or not?

There was a small argument ... Thank you! :)

  • These are the questions that the serious holivars in the internet start up ...) - Stas0n

4 answers 4

The universal rule is exactly one thing: follow the semantics, the meaning of the code.

If you export a constant , feel free to expose the public static final . For example:

 class GlobalConstants { public static final int DAYS_IN_WEEK = 7; }

If you are exporting something for which there is or may be logic that may change, make it better with the property so that you can change this logic without pain for the clients of your code.

 class MyCar { private static final String manufacturerName = "ЗАЗ"; public String getManufacturer() { return manufacturerName; } }

If tomorrow you switch to Ferrari, customers who have compiled with the old version of your library will have no problems. (But if your string were constant, it would be hard-compiled into the clients code, and they would continue to think that you are driving a Zaporozhets.)

A similar question for C # has already been discussed on the site .

  • one
    you must have had in mind: public static final int DAYS_IN_WEEK = 7; - jmu
  • @jmu: yep, you're right, replace, thanks. Java is not my native language. - VladD

There is no point. The field will not change at all - it is final. It is public - that is, already available. Moreover, to introduce an additional layer is only for adherents of a complete OOP.

If you do not agree, then consider the question - and should setter'y be done for these fields (this is a question with a great deal of irony).

    I understand the question like this: does it make sense to hide static final , for there is no point in hiding public static final - that’s for sure.

    In this context, I would say that yes, sometimes it makes sense to hide. Suppose there is a situation where there is a certain constant that is used only in the current class and beyond it is of no interest to anyone. We will not go far and give an example from real life:

    There is a series of classes (hierarchy), where each of the classes uses the concept of block size (we are talking about block encryption). The horse is clear that the block size depends on the encryption algorithm, say for DES it is 64 bits, for AES there are also 128 and 256.

    This is where the fun begins. The block size is needed by an external procedure (function) in order to understand the block alignment rules (padding) and so on. cryptic mui ne. Accordingly, we need an obvious, block size getter. Say for AES, the block size can be any between 128 and 256 (but a multiple of 32), but for DES it is always constant and 64.

    Well, it turns out something like:

     abstract class Cipher { abstract public getBlockSize(); } class CipherDES extends Cipher { private static final int BLOCK_SIZE=64; @Override public int getBlockSize() {return BLOCK_SIZE;} } class CipherAES extends Cipher { private int blockSize; @Override public int getBlockSize() {return blockSize;} }

    Life is multifaceted and anything can happen. So do not rush to conclusions even in obvious situations.

    • if it is private, then who is arguing. The question was about public. In the code you give it is not quite a getter. Yes, it looks like a getter, but it is not. - KoVadim
    • Well, I wrote a disclaimer at the very beginning. And, by the way, from the fact that the constant will be public nothing changes - such as a getter will still be needed - Barmaley

    I think this is from the category "there is no friend to the taste and color" ...
    But I would make getters.)

    • one
      getter for constant? what's the point? - Gorets
    • @Gorets, I said that everyone has his own answer to this question. If you can't do it without a full op, you will write a getter, if you are a simpler guy, you will not write) - Stas0n
    • @KoVadim he argued well enough, you can store constants in a notebook and do it through Enum, but this is not just "a way - like it or not," it's just stupid - Gorets