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 8 years ago.
Improve this question
My project classes are quickly approaching large numbers of lines into the thousands. Is it good programming practice to divide the classes Into smaller classes even if they do the same thing? After all I'd hate to create communication caller functions for the same object.
It is a good programming practice to split up your code so you (and others) don't get lost.
Split it into methods/functions/procedures, classes and packages by meaning, not by size alone.
If several classes do the same thing, have you thought about using inheritance? Don't duplicate code, it makes maintenance harder (and is a waste).
For Java, interfaces and abstract classes can also improve legibility and structure of your code; use with moderation. Many Java IDEs come with handy "refactoring" functionalities which allow you to restructure your code easier and cleaner than copy/paste would be.
( Possibly related topic: "how do you organize your programming work" how do you organize your programming work )
As a rule, each class should have one responsibility that you can clearly state. If you can't state a single purpose for a class, or the narrowest purpose you can define is nebulous and vague, it's time to refactor.
Of course there are exceptions to every rule, and some classes with a lot of utility methods (like String) will be very large. But I generally take a hard look at the purpose of a class when it grows past about 300 lines. (For the second time - I do it the first time before the class grows past 0 lines.)
Related
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 1 year ago.
Improve this question
In Java, operators <, >, >= and <= are not defined for the primitive boolean type.
However, the corresponding wrapper class Boolean implements Comparable.
That is: true > false
is an error, but Boolean.TRUE.compareTo(Boolean.FALSE) > 0 is fine.
How come?
Did the language designers change their mind?
Why keep the incoherent behavior, then?
Although arbitrary, I can think of advantages to having a total order defined for booleans.
Are there any disadvantages?
Programming languages are not mathematical constructs. They are complex projects spanning many years and a lot of different people. As such, they are subjected to opinions, legacy, disagreements, hype cycles, influences of other languages, poor communication, and unfortunately sometimes also to mistakes and stupidity. You could argue that most decisions about a language are in fact arbitrary.
Your question is perfectly valid: why is it like this? Unfortunately without asking people who made the relevant commits how much they can still remember is not really a viable option. So your guess is as good as anybody else's.
It is what it is, but you are entitled to have your own opinion. Sadly, such inconsistencies can be in some cases frustrating to the point when people abandon a language and create a new one. But since computers are physical, limited things, any new language will also be imperfect and opinionated.
If you ask me, having a total ordering on boolean is a good idea - it wouldn't hurt anybody, while it could provide some limited benefit in certain (although very narrow) cases. But there are many more, much much bigger issues with Java. As it stands, I don't think Oracle will risk breaking any existing programs by changing this behaviour.
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 3 years ago.
Improve this question
I have a class that has many fields made of objects of other classes. This class is used by multiple people who keep adding more fields to it according to their needs. I want to know if there's a drawback to this compared to having one collection field, say a Hashmap, in this class which can be used to contain other classes as and when necessary. This looks cleaner to me than declaring many fields which might end up not being used
A class with too many fields and methods is certainly harder to grasp and change later on - the shorter the class is, the easier it is to understand its uses.
On the other hand, keeping different class variables inside one hashmap in order to make the class shorter is not a good idea at all because you will lose type safety and will have to add many additional checks and castings later on.
In conclusion you should always keep the classes as simple and clean as possible without sacrificing best coding practices - perhaps instead of having so many different fields in one class you could have multiple smaller classes, each with their own responsibility, instead.
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 6 years ago.
Improve this question
Question might be silly for experts but please help me with pointers if it is already solved somewhere.
Interview Question : "Design class diagram in best possible way"
You need to design a game "SuperHeroes".
Super hero examples are Batman, Spider-Man, Thor, Hal Jordan, Wonder Woman, Captain America .... n
Spiderman can jump, crawl, generateFire ....n
Batman can jump, crawl, fly .... n
Thor can swim, fly .... n
There can be millions of behaviour.
There can be millions of Super heroes.
Some have few behaviours common in them and some specific to hero.
Design should be flexible enough to add behaviours to the super heroes
Important point to focus was told that "System should be scalable"
I tried twisting decorator pattern to accommodate problem requirements but was failing at many places, also I have to make many interfaces for this, so scalability was questionable.
I tried another approach as Writing all behaviours in one class(If require will classify behaviours in respective classes, kind of utility class which will have all implementations of behaviours). and an Spiderman class which will have list of allowable Behaviours(kind of enum). and it is allowed to call methods from behaviour utility only if such behaviour is allowed in list. I think it is not a good approach.
Please help me with best way to achieve this.
If I understood the question correctly, the problem could be solved with the mixin pattern; however, multiple inheritance is required for a straightforward implementation, which is not available in Java. The subject is discussed in this question.
In games it is pretty easy to get a very huge inheritance tree up to the point, where it is very difficult, if not impossible to add a new entity with a different behaviour. To solve this, something called the Entity Component System is used. It is very flexible, does not limit you to inheritance and is commonly used in larger games.
There is also a follow-up article that describes a specific implementation, and has examples on how it can be used in different situations.
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 7 years ago.
Improve this question
I think javadocs are beautiful. Clear descriptions for each method and class. Our tester can easily write unit-tests without repetitive explanations from programmers.
This is how we practice TDD at our start-up. We first sit and plan the application structure, and we start creating all the methods and classes (without programming), we add descriptions to the classes, constructors and methods with javadoc. We then ship this to our tester who write unit tests. When he is done, we start programming.
No one is actually complaining. Our tester is in love with javadoc and although he is a terrible programmer (that is why he became a tester), he can easily understand the javadoc and write junit-tests.
The thing is, most of us are newbies in a start-up. And I don't know if you are supposed to document all the classes and methods before we even start programming? My question to you more experienced programmers is: is this a good TDD approach?
TDD is useful, because it makes sure you do not miss any requirements. It ends up beings used as unit test cases, and while the programmer starts their work they need to make sure all the test cases are covered.
Testers write system & integration test cases.
coming to javadoc, ideally it should be a must. It removes code duplication/reusablity and also adds some value to system document.
Javadoc should describe the return type, input params and process being carried out within the method.
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 8 years ago.
Improve this question
I currently have several "manager" classes in a project I am working on but have seen a lot of things that advise you to not use manager classes but don't seem to provide any alternatives in my situation. I have a ClickManager which contains a map of "clickable" objects and a ConfigManager which is responsible for loading and saving config files as the config class comes from an API I am using and is too stupid to load itself.
What are some alternatives to using "manager" in these cases?
Ward Cunningham once said (1) that every programmer should have a dictionary and a thesaurus on his or her desk. There's also a saying that there are only two hard problems in computer science: cache invalidation and naming things. (2)
The point is that naming things is important, and it's hard, and it's often neglected. This is why there are classes named Data and Manager littered around many code bases.
There are at least two potential things going on here. One is that the class is doing something reasonable, and it just needs to have a good, concise, descriptive name applied to it. For example, with ClickManager, does it dispatch events to the clickable objects? If so, maybe it's a Dispatcher. Does it lay out the clickable objects? Maybe it's a Positioner. Does it contain the clickable objects (as Erwin Bolwidt suggested)? Maybe it's a Container. Does it execute something in response to a click? Maybe it's an InteractiveCommand. It's sometimes helpful to think more specifically about what a class is doing in order to come up with a good name.
Another possibility is that the class has too many responsibilities, that is, it violates the Single Responsibility Principle. This is often the reason that something is hard to name, because it does a bunch of different stuff. Suppose the class simultaneously contains clickable objects, dispatches events to them, positions them, and executes commands. It's no wonder that it's hard to come up with a name other than Manager because it's doing all of these related, but independent functions. (Note that in many UI toolkits, these responsibilities have been separated into different classes.)
If this is the case it might be advisable to do some refactoring of a big Manager class into smaller classes, each of which has fewer (or one) responsibilities. It should be easier to come up with better names for those classes.
(1) I think it was at an OOPSLA about ten years ago.
(2) And off-by-one errors.