This question already has answers here:
Prefer composition over inheritance?
(35 answers)
Closed 9 years ago.
Should composition be favoured over inheritance as rule - in all circumstances?
I have read that inheritance is actually now being seen as an anti pattern. My problem with that is that some relationships logically fit into inheritance i.e. is-a relationships.
But from reading lately this is seen as wrong?
What is the way to go with this?
No, composition should not be favoured over inheritance as rule in all circumstances. You generally use them for different things and in different situations.
Related
This question already has answers here:
How to implement multiple inheritance in delphi?
(10 answers)
What are the pros and cons of using interfaces in Delphi?
(9 answers)
Closed 2 years ago.
I need to use an external library which has a class hierarchy, TC1 base, TC2 which derives from TC1, TC3A and TC3B which derive from TC2. I need to extend each class of this hierarchy with some attributes and methods, which will obviously need to be inherited from the derived classes. I don't want to change the library code. I can't use class helpers because I also have attributes to add. And Delphi doesn't support multiple inheritance. The use of encapsulation instead of inheritance seems to me not applicable in this case. How can I solve the problem?
This question already has answers here:
Java Interfaces Methodology: Should every class implement an interface?
(13 answers)
Closed 7 years ago.
I have been doing OOP for a quite while and I got confused with usages of interfaces after an argument with a colleague few days before.
Basically, I have been using interfaces when I apply design patterns, especially when there are multiple classes implementing common features.
In my application, there is Hibernate layer and few Sevices classes as example UserService, CompanyService, etc.
The question was whether we keep, separate interfaces also for each Service classes. Such as UserServiceContract, CompanyContract and etc.
My colleague argument was, there is no need to have interfaces.
I came across that in this tutorial also, the author has used interfaces. But there is no common interface that implements several classes only once.
example interface implentation
The benefit of using the interfaces was in this situation, it improves the code structure. Yes, there is IDE features that show what methods available for a class. But, I still want to get your guys idea too about this.
When you are talking design patterns and best coding practices, needing is not what you should be asking yourself. You do not need most of what you do, at least not immediately. Of course you do not know whether you will need different implementations of that contract until you actually do. So this is not a question of what you need right now. This is a question of what you will wish you had later.
What you have seen in the link you posted is the D in SOLID: the Dependency Inversion Principle:
Depend on abstractions, not on implementations.
You are better safe than sorry, you know.
EDIT: Also, I would advise against sufixes for interfaces (or prefixes). If you will be using the interface instead of the implementation, make the interface's name clean. A common choice would be, in your case, UserService for the interface and UserServiceImpl for the implementation.
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
This is a probably a very basic question, but it's one I'm actually running into as I'm learning more about Actionscript 3 in particular. However, my first question is very general: When is appropriate to put functionality in a new class rather than a new function in the same class? According to this Java tutorial, which focuses on basic object-oriented principles, a class is supposed to be a "blueprint of an object". I always understood this to mean that any functionality or behavior that the object would use should be contained within the class. However, according to the single responsibility principle, each class should have only one reason to change. For example, you should have one class to compile a report and one class to print it rather than a single Report class.
Can you guys help me understand the pros and cons to creating a new class? What are the costs to splitting an object into multiple classes? Are there compile-time or performance costs for keeping related functionality in the same class, or for splitting it into two? Are there perhaps times that you would want to split things out, while you might want to keep them together other times?
As far as I remember, there isn't a big difference between having 1 class which can do everything or several classes which can do the same.
It's about readability and how you can extend the code. It's also just about clean code and coupling.
If you have a class called "Printer" you don't want to have "WaterCoolerSound()" in it. Of course the more objects you have the higher the chance is that you can run out of memory. But I am not entirely sure whether one object with all functionality or several classes with the same functionality spread out, takes more memory.
In fact, you could say that if you JUST need a little bag to hold on to some data and not be able to dance like a bear at the same time, it would make sense to have two separate classes.
It's advisable not to think about the performance before you have the code. From the maintainability and understandability viewpoint, of course, smaller classes, with smaller methods are superior. (see The Single Responsibility Principle again :)
Don't get so confused about making classes for just a function. A class should have only related functions.If the functions are of different kinds which will do totally different functionalities and use totally different kind of variables then only u should make a separate class.
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
In OO apps, it's common to have an Application class which holds your top-level managers or whatever. This makes it hard to avoid having a theApp global object, or using a Singleton or something.
Does it matter? Should we seek to make this as OO as possible, or accept that OO principles break down sometimes?
Does it matter? Should we seek to make this as OO as possible, or accept that OO principles break down sometimes?
Sometimes OO theory meets the real world, and you should strive to make things work for your customers first and foremost. A singleton here or there is not a problem for your customer, or for maintainability.
OOP is mainly there to make code easier to maintain, reuse and understand. As long as those goals are met, there is no need to refactor for purity reasons only.
Having a global theApp object singleton doesn't necessarily violate OO principles, so long as data tied to it is properly encapsulated and whatnot.
There's also the situation that few OS's actually have an OO core, meaning that the Application Loader isn't Object Oriented to begin with.
In any case, absolutism on this point is dangerous; some programming languages have an (IMO) overly zealous approach to the whole thing, dictating every function be a method or the like, even when this doesn't make a lick of sense. (System.Math.sin(x), anyone?)
The most effective approach is usually mixing the two methodologies, using functions for functions, and methods for methods; and by extension, using Singletons for things that truly are singular; such as the application object or interfaces to some system services.
Edit: On System.Math.sin(x), it should be made clear that sin(x) is a function in quite literally every sense of the word, and putting it as a method on a singleton is wildly irresponsible, or at least a bit silly. In the comments a case could exist where another class wanted to use the name sin() for a method, but as methods and functions reside in separate namespaces in any case, this really isn't relevant.
I think the goal should be to design as well as possible. I don't want to have a mindset of seek "badges" or stamps of approval, so I'm not interested being as as "OO as possible", rather I seek to make concious trades-off. We favour concepts such as de-coupling and single-responsibility not because it's OO or because we can claim to be using a Design Pattern, but because we increase the ease of development, maintainability, testability and so on. We also favour simplicity because that too increases mainatainability and testability - the "You ain't gonna need it" principle leads us sometimes to leave things a little mre tightly coupled because we don't need flexibility right now.
So, to consider you example, there may well be a singleton in the sense that yes, there is only one of something (a thread pool or some such) but does the code using it need to know that it's a singleton? With a bit of care, use of factories or injection we can limit the knowledge of the n-gleton-ness.
There is no breakdown of OO by having a "theApp" object.
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
What principles do you generally follow when doing class design?
Principles Of Object Oriented Class Design (the "SOLID" principles)
SRP: The Single Responsibility
Principle A class should have one,
and only one, reason to change.
OCP: The Open Closed Principle You
should be able to extend a classes
behavior, without modifying it.
LSP: The Liskov Substitution
Principle Derived classes must be
substitutable for their base
classes.
ISP: The Interface Segregation
Principle Make fine grained
interfaces that are client specific.
DIP: The Dependency
Inversion Principle Depend on
abstractions, not on concretions.
Source: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Video (Uncle Bob): Clean Coding By Robert C. Martin ( Uncle Bob )
Don't forget the Law of Demeter.
The S.O.L.I.D. principles.
Or at least I try not to steer away too much from them.
The most fundamental design pattern should be KISS (keep it simple stupid)
Which means that sometimes not using classes for some elements at all it the right solution.
That and CRC(Class, Responsibility, Collaborators) cards (write the card down in your header files, not on actual cards that way they because easy to understand documentation too)
As mentioned above, some of the fundamental Object Oriented Design principles are OCP, LSP, DIP and ISP.
An excellent overview of these by Robert C. Martin (of Object Mentor) is available here: OOD Principles and Patterns
The "Resource Acquisition Is Initialization" paradigm is handy, particularly when writing in C++ and dealing with operating system resources (file handles, ports, etc.).
A key benefit of this approach is that an object, once created, is "complete" - there is no need for two-phase initialization and no possibility of partially-initialized objects.
loosely coupled, highly cohesive.
Composition over inheritance.
Domain Driven Design is generally a good principle to follow.
Basically I get away with programming to interfaces. I try to encapsulate that which changes through cases to avoid code duplication and to isolate code into managable (for my brain) chunks. Later, if I need, I can then refactor the code quite easily.
SOLID principles and Liskov's pattern, along with Single responsibility pattern.
A thing which I would like to add to all this is layering, Define layers in your application, the overall responsibility of a layer, they way two layers will interact. Only classes which have the same responsibility as that of the layer should be allowed in that layer. Doing this resolves a lot of chaos, ensures exceptions are handled appropriately, and it makes sure that new developers know where to place their code.
Another way to design is by designing your class to be configurable creating a mechanism where the configuration can be plugged in your class, rather than overriding methods in sub classes, identify what changes, see if that can be made configurable and ensures that this functionality is derived from configurations
I usually try to fit the class into one of the oo design patterns.