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 am using Spring framework usually with the common simple form:
Controller <-> Service <-> Repository
And I usually have a common services that I put inside a CommonService class and make all other serivces extends class.
A developer told me that it is better to inject the CommonClass in each service instead of using inheritance.
My question, Is there one approch better than the other? Do JVM or performance affected by one more than the other?
Update
There is no direct relationship between CommonService and other Services, it is not has-a or is-a relationship, it's like a utility service.
It is the principle of favoring composition over inheritance. If you inherit from a certain class, both are tightly coupled which makes it harder to keep separate things separate.
Unless an there is an is-entity relationship between the two, it is better to model a uses-entity relationship, because this allows for easier changes later on.
Of course it depends on the use case and it is more of a design and architecture question than a performance aspect.
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 1 year ago.
Improve this question
Should the classes always have connectivity in UML? For example, in the following diagram, class Zugriff is not connected to any other classes. It that a valid or correct class diagram in UML?
Yes. You SHOULD but not MUST.
Class diagram is UML structure diagram which shows the structure of the designed system at the level of classes and interfaces, shows their features, constraints, and relationships - associations, generalizations, dependencies, etc.
(from https://www.uml-diagrams.org/class-diagrams-overview.html)
These classes and interfaces should have a type of relationship so that it makes sense to put them together. A typical relationship is a generic (weak) use.
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
is there really a preferable relationship between classes ? or it depends on the software we have ?
I know that we have is-a and has-a relationships in classes relations but, is there a one relation that is Confident and it most preferable between software-designers.
The only preferred relationship between classes is independence. Because independence means guranteed separation of concerns and freedom to evolve. (Joke)
But unfortunately independence is not very useful: Lots of lonesome classes will only help to solve lots of little isolated problems. If you really want to make something useful, you'll have to relate the right classes. And then, the only thing that matters is what relationship helps you to best address your needs. Sometimes it's inheritance (is-a), sometimes it's composition (has-a). It all depends on the context.
What your "doctor" probably meant was to prefer composition over inheritance. This is a useful advice. But it is a simple rule of thumb: it is not a universal truth.
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
Let's say you have some issue to develop. And as recommended practice it is good idea to use interfaces ( I don't mean GUI, I mean interface or abstract class ). And you can apply two ( I'm pretty sure, but for now I noticed I apply two ) ways:
Design interfaces upfront and then implement them.
Implement classes and then on basics of classes discover interface.
Personally I prefer second option, but during discussions with other developers I noticed that somebody prefers first approach. I can say that I prefer second approach for the following reasons:
I can faster write code
I avoid unnesessary code ( something that I never will use )
Interfaces in that case are more binded to "real" life
For me it is more convenient.
I'd like to hear other advices why somebody prefers option 1 or option 2.
As usually I code in C#, but AFAIK java also have idea of interfaces
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 7 years ago.
Improve this question
Does every type modeled in DDD have to be either an entity or a value object?
No, in DDD you can modelled the following types of objects:
Domain Event: A domain object that defines an event. Where a domain event is something that happened that domain experts care about.
Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services.
Repository: methods for retrieving domain objects should delegate to a specialized Repository object such that alternative storage implementations may be easily interchanged.
Factory: methods for creating domain objects should delegate to a specialized Factory object such that alternative implementations may be easily interchanged.
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've been hunting for tips on good Java coding practices, by looking at the code of accomplished programs. My first target was Minecraft, since I'd tried my hand at modding it, and I started to question my choice. Here was code from an accomplished game, and it was giving me two very different ways to go about things.
For those who don't know, Minecraft instantiates its items once and subsequently references that single instance and its methods for any operations it needs to carry out, using information from other sources for the method parameters. Its entities, on the other hand, are instantiated once for every individual entity in the world and are responsible for their own information.
So, the crux of the issue is: Which method is more efficient? Is there a particular reason to favor one over the other? Is it situational? Is it more efficient to do it one way or the other?
The answer is, in most cases, it depends.
What you describe is the singleton pattern, which there's one and only one instance of an object. This is beneficial if having more than one instance is either expensive (such as multiple instances of a DAO), or doesn't make much sense (such as multiple instances of a DAO).
Individual instances of objects is necessary if you hold two separate, distinct instances of the same class - for instance, say you're holding two diamond pickaxes. I wouldn't imagine that a singleton would make sense in that context, since you can interact with each pickaxe individually.
Use the pattern most suited for the situation. There is (and won't ever be) any one-size-fits-all way of solving problems like this.