Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I've started to study concepts like Cohesion and principles like Single Responsibility Principle. I am very confused about the difference between them.
The web has a lot of information, but I find it very difficult to filter out the correct comparison.
What is the relationship between Cohesion and Single Responsibility?
Is it possible for a class to have only one responsibility but low cohesion?
Cohesion can be seen a software quality metric, while SRP is more of a subjective software quality principle. As the Pragmatic Programmers describe it, cohesive code happens when things that belong together and depend on one another stay together.
For instance, if a class's instance variables or properties are all used by its methods and its methods alone, but the methods also do not use any external data or methods from other objects, that class is said to be highly cohesive. However, if that class happens to be reading and writing from a file, that class can be seen as not adhering to the Single Responsibility Principle, as reading and writing can be viewed as two very distinct tasks. Regardless, you can also see the class's main task as "do IO operations with the file system", so SRP is somewhat open to interpretation depending on the context it's applied.
This concepts are described in a concise manner in Wikipedia here and here.
One responsability is still an abstract concept. If the responsability is to build a report, it is one task, but still a task with several steps and data parts. So there is some space for low cohesion to happen in the class. Just making a calculation, if simple, is much more "atomic" and high cohesion.
If you see SRP as having a single reason to change the class, I think that helps too.
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
While searching on the internet for information I found it difficult to get a good understanding of which approach should be taken.
One concern is that Util or Helper class is considered an antipattern because it often violates Single Responsibility Principle.
Yet Util or Helper classes are still widely used.
Are there any good reasons to prefer one or another?
This question is probably too opinion-based…
But in my experience, most of the utility/helper methods I used to write in Java were related to a particular class or interface: I had a load of String- and char-based methods, a load of methods that used a Collection or List or array, a load of methods for handling Components and Frames and other Swing classes, and so on. I wasn't thinking of them as extension methods when I wrote them (mostly long ago!), but in hindsight that's how they seemed to go.
So when converting things to Kotlin, almost all of my utility methods fell out as top-level extension methods. I didn't initially intend that, but it seemed the most natural way.
And I expect that will apply to the majority of helper and utility methods. I'm sure there are cases where a utility class is more appropriate — but in my experience those cases are pretty rare.
You should also consider methods in companion objects; that's the most natural place for factory methods, and for other ‘static’ functionality that's closely related to a class without fitting into a normal instance 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 5 years ago.
Improve this question
I've read numerous articles (1,2) about the pitfalls of inheritance and the other options that you can consider.
I've never understood deep inheritance hierarchy. How deep does an inheritance have to go before you consider other options?
From my experience, most well-designed object-oriented classes should be at level one, ie, they should not extend any other class (not counting a fundamental base class such as java.lang.Object). Such classes should be declared as "final" (final in Java, sealed in C#).
A minority of classes will be designed as base classes. They will typically have subclasses at level two in the inheritance tree. Usually, they have a number of protected methods, some of which are overridable (virtual, non-final) and others not (final, non-virtual). For example, a class implementing the Template Method design pattern will normally make the template method itself non-overridable.
Any additional subclasses (at level three and beyond) should be rare. I would recommend to avoid anything beyond a depth of three, unless you are using an existing library such as Java Swing which was designed to require deeper inheritance levels (which doesn't mean the design of Swing is good).
In any case, any class which is not meant to be used as a base class should be declared as final/sealed, in order to prevent or discourage inheritance abuse.
These recommendations are in line with recent books that discuss OO and API design, such as "Effective Java", "Practical API Design", and "API Design for C++".
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 4 years ago.
Improve this question
Why do we use OOPs concepts?
What are the advantages/disadvantages of OOP?
Where do we use OOP?
How do we tell if a program can be written in OOP paradigm? How is it organized?
Note : I'm not related to technical field... So please consider this in your answers.
In short: to reduce the cognitive load required to write, maintain and understand the software.
Software systems are inherently complex, so developers need some tools to break things down to the modules and individual components that could be analyzed and understood without enormous efforts — and OOP is just that kind of tool.
Thats quite a big question. And I try to give you a feeling why we do develop principals like oop ,soa,....
Most of the principal target to make software less complex. Imagine a file with 1.000.000 functions. it would become difficult to find the you want to change. Especially if there are not veryx wqell name like "Update" so you could have a thousand "update" methods.
Often things are less complex if you don't see the complete information pool so you can focus and things you may need. Thats also why there ideas like the information hiding principle .
Another thing is that when you have standards you have to think about. For example in Real life you know that you can sit on a chair (thats a standard) you don't ahve to think about it. Thats why standards make like easier. Some aspects of OOP establish standards (e.g. use of classes) therefore there is little less complexity.
Having class which are grouping the functions may be the first step towards oop. Now when you search a function you would most propably know what you want to udpat "a custoemr" so you know this function may be in the customer class and you have to only look over these methods.
And most of the time thats what principals are made for. making software more read and understandable
OOP is much much more and not the only paradigm .But there is so much more and OOP has so much principals and interprations. It would be too much to explaind and discuss it here. I would also recommend you to have a look at the CleanCoders Movement which provide this in a more general way.
CleanCoders Webcasts
Does ORganization matter
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 6 years ago.
Improve this question
I have a class called 'Inventory' that has two subclasses, 'Drink' and 'Condiment'. They are a part of a software system being developed for use in a hot drinks vending machine. Note that this isn't really going to be implemented, rather it is a piece of coursework for my Software Engineering class. Anyway, I'm having trouble deciding what stereotype to apply to 'Inventory', as I can see it having aspects of both a control class (managing the drinks and condiments during a transaction), and of an entity class (noting the quantities of each item in its subclasses, but it also is the sole manager of the water water levels, as hot water is common to all drinks dispenses from this machine).
I'm basically looking for some guidance on how to classify this class. Thanks a lot.
You might consider that since you are unsure how to classify it, perhaps you could design separate control and entity classes. First rule of software engineering: if the design feels wrong then it probably is.
Come to think of it, the zeroth rule is: know when to ignore the other rules, especially the ones about stereotypes and design patterns.
I vote for entity class -- Having inventory is not the same as controlling inventory.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
In a program, I can design lock to threads,lock to object or files.
Are there difference between these locks?
If yes,
how many kinds of lock are there which can be used to design?
Are there some tutorials to design locks in object-oriented programming?
As someone dss538 said, the "answer" really depends on the context of the question.
What exactly is it that you need to protect access to?
An piece of data or single object, items in a container of some sort, a piece of code, a system resource like a shared file?
Another really meaningful question is how frequently are you going to be accessing this "thing" and what are you going to do with it?
Different locking techniques tend to have different overheads and while a critical section or mutex may be perfectly fine for something that is rarely accesseed and rarely updated, if you're rarely updating it and frequently accessing it you might want to look at a reader writer lock. Another follow up question here is "should I be using spin-locks" here, and again the answer is it depends? What else is going on in the system and are you going to trade one kind of bottleneck (a coarse grained lock) for another?
A final question I like to ask is what are the alternatives to "locking" something, i.e. if I can "safely" take a copy of my protected thing and work with that copy "safely" (ideally without modifying it), it's certainly a lot easier than worrying about every place I might modify said "thing."
I apologize for the vague answer but a more specific question would help here.
I would encourage you to read up on concurrency prinicples and understand the traditional "Dining Philosopers" "Sleeping Barber" and perhaps even "Santa Clause" problems to understand more context of how these things work.
A lot of the content on Wikipedia is good, particularly 'Concurrency Control' is a useful starting reference point if you don't have a good OS / Concurrency book on your shelf.
The answer depends on the context of your question.
Are you obtaining locks from some API? Check the API documentation.
In general, though, I would say no. A lock is a lock. The fact that you are using it to protect a file or an object does not matter to the API. How you use it is up to you. You certainly could abstract away and have FileLocks and ObjectLocks if you wish, but that is up to you.