As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have always gone with the popular convention of using access modifiers and encapsulation in order to make sure a class wouldn't break if it was implemented wrong. However, I have noticed that OOP really doesn't need encapsulation and that using access modifiers actually induces more headaches than benefits. Additionally, by not using access modifiers you are being more of an OO programmer. My reasoning is listed below.
Python supports OOP yet it does not use access modifiers or encapsulation. Showing that in OOP languages access modifiers are not mandatory.
Although compilers are more advanced are still nano-second differences between using accessor method versus variable access. In restricted systems like Android this would affect a games FPS drastically. (Although using the final modifier on methods would reduce the nano-second difference significantly in most cases)
By not using private or package modifiers coding gets simpler and faster for the original coder. Future user of the class would still be able to use public interfaces without breaking or playing with the class implementations. Furthermore, if he wishes to modify or upgrade the class he may still do so and access the private modifiers. In an analogy, when you decide to modify a car you know there is a possibility that you may break something, but if you're willing to take the risks and know what you're doing being allowed to open a lock that has a clear sign saying (open at your own risks) is better than having to replace the unbreakable lock, locking the part you wish to modify.
What I do now is a mix of public modifiers for public interfaces and protected modifiers for implementation details so users can do their risk-taking by sub-classing. Is there any reason why I should reconsider doing this instead of conventional encapsulation?
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm currently in the process of cleaning up a a large Java code base, and I was wondering what was the proper (standard?) structure/ordering of a Java class.
What I mean is:
Should public static final fields be first among the fields of a Class?
Where should a static initializer be?
Where should private static helper methods be?
Also, as a side question: is it a good idea to have large harcoded SQL queries for PrepareStatements in the code?
You should be more worried about naming convention, clear code documentation and overall the correctness of the program (i.e. no bugs), after this you can worry about the order of defining variables, methods etc
This is the code convention for Java
To answer (some) of your points:
static initializer usually appears in the begining of your classes, after the variables if it happen to come first.
private methods can go to the end of your class (before variables if they are at the end), but it is matter of preference, because usually the one who reads the code care more about the public methods that the class expose to the rest of the program
Having the SQL statement inside the program or stored externally (e.g. properties file) depends on how often they are changing; but as long as you are using PreparedStatement you should be OK.
Well, here you're gonna find Java code conventions: Java Code Conventions
I really don't like harcoded SQL statements. But, sometimes they are necessary. See if you can encapsulate that on a library (like hibernate or something), or if at least you can break it into minor sql codes.
Adding
I would also take a look at: How to Write Doc Comments for the Javadoc Tool to mantain your code well documented.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Using a getter/setter in the internal code of a class instead of accessing the instance variable directly, is it good or bad practice? At least for setters one could add additional code validating the value, but for the getters it's just overhead? How intelligent is the Java compiler, if my getters/setters just set/get the value directly, will Java optimize my code and replace the getters/setters by direct access to the instance variables, so there's no method calling overhead?
It is more common to access the field directly. The value of a setFieldName method is more obvious for programmers using your code in other classes. With the implementation details hidden, they might not realize what ranges of values are acceptable, so keeping fields private and forcing other developers to go through a setter makes sense. But inside your own class, the case for using a setter is much weaker. If you look at the source for the java API you'll find that getter / setter methods are generally not used within a class.
There is no need to do that inside a class, unless want to perform additional operations in those getters / setters.
The access to the class members can be direct to the class internally, as:
The reason for hiding is mainly to hide the implementation (and there's no need to hide the implementation from the class itself)
The getters and setters access the members directly, so to call them just to avoid access the members directly is somewhat, umm... redundant.
Regarding performance - I honestly think that in most cases, you shouldn't think about it, you should decide whether to call a method or access directly in terms of readability, scalability and maintenance, not in terms of whether it will take another nano second or not. This approach pays off in the long run. There are places for optimizations, and you should be efficient, but keeping your code clear and maintainable is much more important once the code base is over 20 lines.
Accessing directly is a good thing. However, no one can say getter/setter access is bad, inside the same class. If you are developing a Java bean, you will definitely understand what I am saying. Think you are trying to get the user input of a JTextField as a String. In this case, the getter methods will allow you to do lot of things including String truncating, trim, uppercase, lowercase, etc. If you are trying to do this all just by accessing the direct variable (eg: String s = textField.getText()), you will find it quite difficult to do it. So, what I think is, the good or bad depends on the situation and what you are developing
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Is it bad to use Underscores in Function Names? Can I know the reason why?
ie:
Function GET_NAME(byval sword as string) as string
Not at all. The coding convention is a very subjective term. One might feel one coding style great and another find it worse. The key point is maintain one coding style only throughout your code for ease of upcoming developers and maintainers.
However, avoid all caps for function names (as shown in your example). It's generally reserved for macros (C/C++) / constants.
I would use them sparingly in my own API, but to say that they are bad is simply untrue. If so, .NET specifically would have problems with default naming for event handlers!
void Form_Load( //...
void Page_Load( //...
void btn_Click( //...
// etc.
In this specific case, all caps with underscore separators are generally understood to be constant values.
Firstly, its very subjective matter and depends from Person to Person. One may feel like using _ in function, others may not. There's no harm if you use it.
Frankly speaking, you don't usually use _ sign. But, you can to use this '_' in the variable declaration.
Note : You can check out the msdn link ( atleast for C#,
Visual Basic, C++ )
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
what is the advanrages oop over structural programming?
The main advantage that it allows you to control the complexity. You can create an object which represenets some real one, put the logic inside it and hide all the implementation details behind some interface, which is public.
That way, the client has no idea how the object is implemented but deals with public interface to control it. For understanding suggest the program interface of the car:
public interface Car {
void speedUp(int mvh);
void breakDown(int mvh);
}
Then, you can have a lot of implementations - Ferrari or WV, or something else. They all will have some implementation details, but all have the common interface, and don't need cleint to be aware of implementation details.
Object Oriented Programming has many benefits over structured programming. some of them are reusability,reliability and maintainability.OOP akso helps to reduce large to smaller more manageable problems.In terms of extensibility and reusability,for instance:"Encapsulation allows the internal implementations of a class to be modified without requiring changes to its services (i.e methods).It is also allows new classes to be added to a system,without major modifications to the system.Inheritance allows the class hierarchy to be further refined, and combined with polymorphism, the superclass doed not have know about the new class, i.e, modifications do not have to be made at the superclass"
If you understand what Object orientated programming is about the answer is self evident. OO programming is a superset of procedural code can do, so by definition it is richer in helping you solve any problem.
It allows you to define and assign responsibility for a given set of data to a given set of code, and it allows you to group responsibilities into a unified interface.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Why is it convention to place getters and setters after constructors within classes?
I would rather see them placed immediately after class fields, before the constructors, in order to see which of the private fields are accessible via getter & setter methods. Especially if the methods' bodies are single return or assignment statements.
The Java coding convention states that methods (getters and setters are methods) should be after constructors declarations. It just a convention and it exists to make code easier to read in general.
If you judge that the code is more readable with getters//setters after fields rather than after constructor, you're free to do it.
Resources :
Java code conventions - Class and Interface Declarations
Java code conventions - Why Have Code Conventions
My take is that you have fields, then constructors, then methods so you can read through the class saying: "this is what makes up the object, this is how you build it, and having built-it here's what you can do with it".
That said, it's entirely subjective. If another layout makes sense for you and your team in your domain of interest, then do it differently. The only thing you should be wary of is making sure that your projects are internally consistent. It can be very off-putting to see code style change class-by-class.