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.
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 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.
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'm using Java to do some complicated calculations, and have a lot of classes that need access to a lot of the same variables. These variables are set at different stages of the calculations, in different classes. The problem is that my code is getting quite messy as I am being forced to pass the same parameters to a lot of different methods.
I am looking for peoples thoughts on what the best approach here would be? One idea I have is to make a superclass with all these variables set in it and extend this class everywhere it is needed.
Another option is to pass an object holding all this information around from method to method but this seems overly complex.
Neither of these solutions feel like the cleanest approach to me. Any thoughts or suggestions of design patterns/ideas that may help me are appreciated. Thanks for your help.
I'm going to suggest that using a Wrapper object is the best way to do this. Make sure all fields are immutable (final keyword in Java). Use a Builder or Prototype pattern to create new objects to return.
How about using a Singleton? That way you'd have global access to it without passing any instances around and all the variables will be under one roof reducing messiness.
I would recommand to separate the problem world (i.e. the variables) from the algorithms (i.e. calculations) in separate classes. The algorithms would get passed in the problem world, and modify it accordingly. This can be seen as an implementation of the Visitor Pattern.
Depending on the complexity (number of variables, number of algorithms, uncernity of solution path), you could also implement a Black Board Architecture. But I think that would be an overkill, if you're not doing something in artificial intelligence...
If there are a lot of values to be passed around, perhaps an in-memory database would be an appropriate solution. A lot of databases these days offer an in-memory engine, e.g. MariaDB.
Make a superclass of subclasses then refer to those subclasses of the superclass everytime you need to pull information
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 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 9 years ago.
Improve this question
i have been reading about this topic , and the more i read the more confused i get ,
can somebody please elaborate , we were using language C which follows structural approach ,
so what was wrong with this approach , that we moved to create a object oriented language JAVA .
I have been reading so many theoretical aspects , can some body please give more of a few practical illustrations ,
WHY WE NEEDED OBJECT ORIENTED APPROACH IN THE FIRST PLACE
I am not looking for an answer to be given in any interview or tutorial
I am looking for an answer to get the better understanding/practical importance of object oriented aproach
There are many explanations regarding this. But I would like to refer this
Modularity: The source code for a class can be written and maintained independently of the source code for other classes. Once
created, an object can be easily passed around inside the system.
Information-hiding: By interacting only with an object's methods, the details of its internal implementation remain hidden from
the outside world.
Code re-use: If a class already exists, you can use objects from that class in your program. This allows programmers to
implement/test/debug complex, task-specific objects, which you can
then use in your own code.
Easy Debugging: If a particular object turns out to be a problem, you can simply remove it from your application and plug in a
different object as its replacement. This is analogous to fixing
mechanical problems in the real world. If a bolt breaks, you replace
it, not the entire machine.
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'm developing an application in Java with MVC architecture. Doing so has greatly decoupled and simplified my code, but the problem is that the model has no intrinsic visual representation. That is, there are no characters, no specific enemies, no buttons, no text boxes - the model is made up of hundreds of instances of one type of object. Each instance is controlled by an instance of a strategy pattern (technically, it's a hierarchy of strategy patterns); it is the only differing point between each instance in the application. The type of strategy each instance uses should therefore ideally make it look slightly different than others around it.
I'd like to avoid a giant if statement chain with dozens of "instance of" calls checking for the type of strategy used when developing a view for this application. I'd also like to avoid a similar chain using an enumeration. Any suggestions as to how I can make my view without succumbing to a massive if chain? Any suggestions as to how I could design my view properly so that it wouldn't be so tightly coupled to the strategy instances?
Thanks in advance for your time!
#DJClayworth asks the critical question:
Are you interested in presenting to the user the strategy [to be] selected, or the results of that strategy?
Assuming you'll need both, let the model contain an enumeration relating strategy names, implementations and descriptive text. The implementation can use a class literal as a runtime-type token.
In this example, enum Rule serves all three purposes as an implicit model. It supplies a legible name and description, as well as a constant representing a particular composite strategy. No case statements are required.