Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I went through some code today. And I spotted something like this:
public class SomeClass
{
...
final private class SomeHandler implements Blahblah
{
...
}
}
Since no one should be able to access SomeHandler from outside, I fail to see why we should make it final. Does anybody have some different insight?
Declaring a class as final has two related but distinct purposes.
It tells the compiler "do not allow this class to be extended". This is done primarily to prevent mistakes.
It tells the reader "do not worry that this class might be extended". This is to aid understanding.
In the case of a private final inner class, we can assume that one person writes or modifies the class and that they do it after understanding the design. Thus, the likelihood of someone mistakenly extending a class that shouldn't be extended (by design) is small.
However, someone reading the code who needs to know is the private inner class might have been extended needs to scan the entire Java source file ... unless the class has been declared final.
Hence final could be serving a useful purpose ... in making the design manifest to improve readability.
On the other hand, the final in the example you found could have been added without any particular intent; i.e. it could simply be "redundant".
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 12 months ago.
Improve this question
When programming in OO languages like C# or Java, is there a good situation where declaring a public field inside a class is actually valid (I myself always use a property for not making the user of the class depend on the data and to support data protection)?
Otherwise, it feels weird that C# for example allows you to do so.
According to the C# coding conventions public field should be used sparingly:
// A public field, these should be used sparingly
public bool IsValid;
Why? I think because of:
can be edited by any other user of class
if you want to add some logic to field, then you need to create property instead of field. By doing this, you will break a contract of class
it is not possible to override variable
However, there is a case when you need to have field as #VGR said:
public const string foo = "";
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
As someone who is learning Java I find it hard to pick whether I should create class with empty constructor or making all her methods statics.
If I’m having a class without properties that read files and doing operations on the data and Being called only one’s shout it be static or have empty constructor.
Because I need to call only one method from the class (and he calls the rest) should I make all methods static or should I call her by creating empty object ?
Actually it would be a private constructor, not empty as you don't want to instantiate the class. But here are a couple guidelines.
Create static methods that don't require accessing instance fields but do some computation. An excellent example of this is the Math.class
Instance methods are used when accessing instance fields and possibly changing then. Getters and setters are good examples. Sometimes private helper methods can be declared static.
But don't use static methods as the fundamental type or because they are easier to use (i.e. work in static or non-static context). They are contrary to the concept of OOP.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm new to Java.
I was reading about Encapsulation concept in Object Oriented Programming.
While reading, I saw a line telling that :
If constructor of a class is declared as private, it will cause some
problems.
But it didn't tell what kind of problems could occur.
Can anyone tell what kind of problems are there with private constructor ?
When you declare a constructor of a class as 'private', you will not be able to create new instances "objects" of that class.
This is a problem if you do want to create new instances of the class, but this implementation is useful when making a Singleton Design Pattern.
If you are interested in knowing more about design patterns, I can share some resources with you.
Here is a book by Carlos E. Otero that covers the topic of design patterns:
https://books.google.com.tr/books?id=IL6FBLJn69UC&printsec=frontcover&redir_esc=y#v=onepage&q&f=false
Simple words, object or instance can't be created for that class.
As soon as, you write this statement below. For example
SomeClass c = new SomeClass(); // this will give an exception.
Basically, private constructors are used for making singleton classes.
On declaring a constructor as private you can't instantiate the class using default constructor. So, you need to create a constructor with public to access it outside.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I know there were a lot of questions about putting constants into interfaces, and that is a bad practice.
But I have a question, what if I have a class, where I want to define some sets of constants, but I want to have them in groups, is it a bad practice to have interface/class inside a class and define constants in there, so my constants are grouped?
e.g.
public class MyClass{
public final class A {
public static final String A = "a" ;
}
public final class B {
public static final String B = "b";
}
....
}
Yes you can have nested class to group the constants. It's really not a bad practice.
the question leads to a misleading. From my point of view the necessity to group constants is related to the fact that they regards different classes and so they must be putted int the correct classes; in other words this question can be an alarm about a not perfectly correct class design.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I was having a query , I have declared a class in which all the methods are static and it is following the utility design pattern that is it is acting like helper class Now can I replcae that class with correspond to enum also , Can I have enum having all the staic methods inside it, if Yes then what other advantages it offers ..!!
The problem with static method is: they can't be mocked for testing. At least not easily.
Putting the methods in an Enum with a single instance gets you a little closer. I'm not sure if enums can be mocked with the standard libraries, you certainly can't without using reflection.
But if you put your methods in an interface implemented by the enum, and everybody else just using the interface, accepting an instance of that interface via constructor (or setter if you have to) you can mock it as easily as you want.
Yes, you can use an enum as a utility class. There aren't many advantages to it, however: it boils down to the private constructor, which prevents uncontrolled instantiation. I would prefer sticking to the ordinary class with a private constructor since there's an expectation for an enum to be used for an enumerated type and not as a utility class. If you used enum for a singleton, that would give it only a slight bit more sense.