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 4 years ago.
Improve this question
I have a web application (in ASP.NET MVC) with a Quotations controller. This controller can handle multiple Quotation types, MotorQuotation, PropertyQuotation, etc...
Currently it is using inheritance i.e. a Quotation model and it's children, to model the domain. The various children classes have differences in the data they store and not their behaviors. The difference in behavior would come with their validation methods as the validations can be different dependent on what unique fields a child class may store.
The question is how would someone model the quotation objects using composition instead of inheritance?
The way you describe the problem, it sounds like this is a good case for using inheritance. The rule of thumb is to use inheritance if A is-a B and to use composition if A is-implemented-in-terms-of B.
The recommendation to prefer composition to inheritance does not mean "never ever use inheritance". It means use inheritance appropriately. For example, if you write a Stack class in C++ using an std::vector, you don't want to derive Stack from vector. A Stack is not a vector, it is implemented-in-terms-of a vector, which implies composition. You also want to avoid creating deep class hierarchies, because that results in tight coupling.
In your case, however, inheritance seems like an obvious choice.
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 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 6 years ago.
Improve this question
If I have many classes which are pretty similar with each other then, does making them inherit from an abstract class a good option?
Only if they are a true abstraction in the Dog is an Animal kind of sense. Stuff on your abstract classes must make sense to all derived.
Otherwise you risk using your base class to sort of import an API. Although you see some frameworks do this, without deliberate design you are usually better off extracting the commonality out to shared dependencies which all the classes commonly use.
Abstract classes that no client code directly references or uses is typically a sign you may be running off track.
Absolutely. Though I would use an interface/protocol where possible. They're more flexible, as they give you the freedom to inherit another class.
The best choice depends on the nature of your classes, and what their duplicated code is.
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 currently developing a school project and we are instructed that we are required to implement Object-Oriented Programming concepts in our software. But I don't want to implement it just by simply inheriting this class to that class and overriding this method to implement its own functionality and so on. Though it is still acceptable but I want to do it differently. By differently, I mean by using design patterns. I'm trying to understand it one by one and I noticed that some of them are very useful(Builder, Memento and Adapter). But the problem is there are so many of them and if possible I want to put/implement it all(those 3 design pattern). Is it okay if I do that? Would it mess up the project as a whole?
As always: It depends.
Overusage of patterns on small and simple bits of code can obscure the code. But it can also make it more clear.
Don't use patterns wherever possible. Use them when it serves a purpose. Every pattern has its purpose and if you can't find that purpose in your code, you shouldn't rewrite it to match a pattern. Try to keep your code a) maintainable and b) easy to read. If a pattern fulfills these criteria more than your approach without patterns: go for it.
You can have code with dozens of patterns and code with none. In both cases it can be the ideal choice.
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
What are the best practices for separating data in different classes? Not just objective c, but programming in general.
For example, if someone was making a game like angry birds, how one manage classes?
Would you have a separate class for just the projectiles (in angry birds case, the birds) and have different classes for the targets, music and images, etc?
There is no simple answer to this. You first need to really understand, deep in your soul, how object-oriented programming works and what it represents. Then you need to make your own decisions based on that understanding and your understanding of the problem at hand.
I've seen many "cookbook" applications of OO and MVC and the like that are terrible, even though the writers dotted all the i's and crossed all the t's and their college professors would have given them an A+ on the project.
But in general I'd probably have a common superclass (with several subclasses) for entities that represent visible, movable objects, but probably not use that for music, eg.
not even data but your functional approach must be modular. create as many smaller components in terms of classes and define their behavior as methods and set the interaction between them through the Game Manager/Logic control system that you design for your game...
Best of luck..!!