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.
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 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.
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 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'm have to use 50 different custom datatypes(/classes) which are defined in a document(xml/json), they have only fields and no methods and maybe strong validations.
My question is should i go ahead and create(/generate) 50 classes or use some generic data structure (like HashMap<String,Object>)?
Update: My fear is if i go with class geneartion, then my codebase might increased by very much
and if go with schema-less way, my data integrity might be compromised, so which one is lesser evil.
Unless it is just ridiculous, more code is more forgivable, in general. There are a few different reasons:
If you give them base classes at the right points, you can have it both ways, as your handling code can hold the base classes, and may have anchor points for extracting, validating or cleaning information stored in the different formats. Surely some of the processing can be shared.
If absolutely everything really falls to the base class, you can refactor the sub-classes out of existence without pain. On the other hand, if you start the amorphous way, gathering the special cases back into separate classes is more likely to go wrong.
Excessively large code is only bad if the extra volume does not clarify the logic for readers. I would have the classes, if they constitute units in which people think.
Also, actual functionality is more important than format or even readability. So if the risk is to data integrity vs code bloat, protect the content, not the form.
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
For my Software Design class, I have to find out if it is possible to decrease coupling and decrease cohesion at the same time by using the Facade pattern?
As you all probably know, when there is low coupling, the cohesion of the classes is high and vice-versa.
To me, this is a contradictory state, but I still think it is possible but can't find the enough evidence to support this.
My answer is this. The reason for this is that if we give some instructions to the classes that are cohesive they would not function in the same manner if there were no instructions. Given that, let say that we have the same facade with the instructions that have the capability to receive attributes from the classes that have low or high coupling. If this is true, the classes wouldn't be so dependent to each other and the coupling would be also decreased. In that way we have a facade which in the same time decreases coupling and cohesion of the classes.