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
I want to make a UML class diagram. By hand, not generated from code. The problem: UML is a very broad specification - I can't map all Java features to how they should look like in the diagram. There are associations, dependencies, aggregations, compositions. They are all well-documented, but not specifically for Java, so:
When should I use which type of connection?
How to handle inner classes (static or not)?
What about static, final, abstract methods/fields? I think I must make it bold/italic/underlined, but how do I map those together?
Abstract classes, Final classes, Enums?
too broad. Try asking for a specific application.
Just nest them.
Use according stereotypes.
Abstract classes are shown with name in italics. Use stereotype for <<final>>. There's a <<enumeration>> meta type.
I use draw.io when I need to make the UML and/or other diagrams. Everything there is manual, you just drag the design and then write the fields,functions, class, etc.
If you don't know when to use connections, classes, etc then go back to learning then try again once you know good enough.
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 8 years ago.
Improve this question
This question may be a little off-topic but I can't really understand why there is no Interface class in Java.
Every class defined has its java.lang.Class object constructed by JVM. And naturally to me, interfaces should not fall into Class objects, but java.lang.Interface objects instead. That would make sense, wouldn't it?
I know there is this class assignability thing going on so that a class implementing an interface can be casted to that interface, but wouldn't it be a better idea to call it Type instead of Class? And then extend Type to create Class and Interface.
I know for sure Java developers won't do anything about it, but I'm just curious.
You are probably right. Class not only represents classes and interfaces but also enums, arrays and primitive types. Type seems to better describe its purpose. It might also make sense to have derived classes like AnonymousClass. Currently some methods such as getEnclosingConstructor() work only for certain types of classes.
In fact, designers of C# decided to call their equivalent Type.
To know exactly why this was done this way, you would have to ask the people who made that decision. My guess is that in Java 1.0 this made more sense, as Class was more tied to .class file.
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 need to create a hierarchy of different kinds of vehicles.
I'm not sure exactly how I am supposed to name each of the different types of cars. My first thought was to name them FordTruck and FordCar, but that seemed like a bit too much for each class.
My other idea was to just create separate packages for cars and trucks, so that the names won't interfere. Having the same name in different packages seems to have the disadvantage of less readable code when trying to implement methods that use both Cars and Trucks.
What is the convention and what is the best practice for naming the files?
The Make is better suited as an Enum of Vehicle instead of being a Class itself.
Edit: I'm going to expand upon this a little bit. You make a Class to represent nouns (things), the Make (Dodge, Ford, Chevy, etc...) is an adjective, something that describes a noun. Instead of giving it its own class, you make it a property of the class it is describing. A String would do as well, I just chose Enum because I prefer them.
Make should be a flag inside Truck and Car, not a class. As Mike N said, and Enum constant would do.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I know abstract classes and interfaces in java but I want to know how to bring abstraction in working software/project? how to thing in such way which brings abstraction.
Your question is vague at best, however the usage of interfaces helps abstraction because you are not working with concrete types. For instance:
IPrinter p = PrinterFactory.getPrinter(conditions);
...
p.print(content);
In the below line, you are not aware of exactly what printer you are using. Since you are just using the logic, you do not really care. All that you care about is that the factory will give you the printer you are after and that the print method will print the content to the right stream.
If you want to change the printer being used, you make the amendments in the factory class so that you get a different IPrinter implementation which does what you need (which in this case it would be to print to some other media). This would mean that you have essentially changed the outcome of a piece of code without changing much of it.
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 8 years ago.
Improve this question
Like in Scala? Is there any pattern in Java to avoid having all the boilerplate setter/getter without using 3rd party jars? Thanks
update:
my aim is to avoid having too many ghost methods for Dtos, thanks
If all you want is to avoid having to type, use auto generation feature of IDEs like some others mentioned.
If you want to avoid seeing getter/setter in your classes, use a library called lombok which can generate the getters/setters behind the scene
If the above options are not OK for you and you need to set the value only once, you can declare all your fields as public final and have a constructor setting the values.
CAUTION: I am not suggesting this third option as a good practice as it breaks the Javabeans convention. Also it exposes your class' internal structure, but honestly, even with prolific use of getters, you are exposing class fields to the client.
There are a lot of IDE's out there for java that will help you with this problem.
In Eclipse, when you right click on a variable, you can choose Source -> Generate Getters and Setters.
I never used Scala but this should do.
in idea intellij u can create as AlT+ insert and then choose getter+setter
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
Anyone know what the opposite of a Plain Old Java Object is?
I'm talking about your typical terrible java class. Very complicated, tightly coupled, non-modular quagmire of ridiculousness?
Is there a term for a such a class?
Not sure you understand what is meant by POJO, from wiki-pedia a POJO object is simple an object that doesn't:
Extend a prespecified class, implement a prespecified interface or use annotations.
Basically this means an object that isn't part of a broader framework. Most badly designed, tightly coupled java objects are still POJO.
There is no such thing such the "opposite" of the POJO.
POJO is a simple java object (as you correctly say) and is used to separate them from objects which server special causes. I mention some example object categories which are not POJOs:
EJB
java bean
DTO
COM objects
CORBA objects
Hope I helped!
I know "Big Ball of Mud" is a term applied to software architectures that have the characteristics you describe, so maybe you could apply this term to classes as well.
The term POJO is a bit overused. You need to define it clearly so that you can come up with an opposite in your line of thinking. Following could give you an idea.
"POJO describes Java objects or classes that can function on any java context."
Following this description you can probably consider it to be the opposite of Enterprise Java Beans in a Java EE context.
Have a look at Enterprise Java Beans for more information.