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.
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 4 years ago.
Improve this question
After reading Interface vs Base class I understand that Inheritance should be used where there exists a "is-a" relationship and interfaces should be used in "can-do" kind of places.
If that means, base class can only have business objects and interfaces will have only the contracts?
For e.g Dog class will have a base class Animal with properties like Eye,Nose,Leg etc and interface IAnimal will have "Run", "Jump" etc.
Will design applicable for all the scenarios?
The answers on that question you linked actually say it all. Especially the accepted answer and its first comment. You use an interface to declare the contract and a base class for shared implementation.
I'd consider it a common practice to define interfaces for (almost) everything. An interface can also contain getters and setters and therefore define its subtypes properties. If two or more classes that implement that interface share some implementation, you can moved that to a base class. That base class would then also implement the interface.
Your understanding is correct, but I think it relies more on good practices than actual language rules. Please consider the following:
In languages that support multiple inheritance (C++) interfaces are just classes with all methods virtual and abstract. See this question
Languages that don't allow multiple inheritance (Java), the most important difference is that a class can have no more than 1 superclass, but can implement an arbitrary number of interfaces. There are also differences in declaring variables (variables are implicitly static and final in Java interfaces) but it's still not a big leap to think of interfaces as of 100% abstract classes.
Java 8 introduced default methods (see this question), which can kind of blur the obvious distinction between those two.
So while technically it's not true neither that interfaces must only define the contract (default methods can implement a fallback behavior in a Java 8 interface) nor that abstract classes must define behavior (because a pure abstract class with no implementations can exist), the approach that you described is kind of reasonable and common in real world.
It depends.....
That's a good starting point but it is not right to say that it will be applicable in all scenarios. Systems keep changing and as part of refactoring (http://refactoring.com/catalog/) sometimes interfaces become subclasses and the other way round. Interfaces are good for Mix-ins which you mention as "can-do" kind of behavior and Inheritance where a group of classes share certain properties and possibly some behavior enabling reuse and avoiding code duplication (which is essentially what a IS-A relationship is). You can read more about it in Effective Java by Joshua Bloch (there is an item on Interfaces and Inheritance).
If we take your example, the methods "Run" and "Jump" can be either defined in Animal base class or they can go in an interface as you mention, in fact they can actually go in multiple interfaces too. So you might start off by building a inheritance hierarchy and later refactor them into interfaces as the system evolves.
This is a hard one. I've read this question in forums but nobody could come up with a satisfactory answer.
Coming from a C++ background, I've been told that Java achieves multiple inheritance through interfaces. One of the main purpose of Inheritance happens to be "code reuse".
I've been trying to understand the use of interfaces through the years. I've not understood whether interfaces achieves code reuse. If yes, then how?
Please give a good code example to substantiate that.
I already understand that interfaces are :
used to specify a contract.
used to specify additional roles,
behaviors that the class plays.
used to achieve "polymorphism", (eg: A
method like addKeyListener(KeyListener e) can accept any class that
implements KeyListener as arguments(so that it becomes of type
KeyListener),even if its not in the inheritance hierarchy of
KeyListener.
But how is it useful in the case of code reuse, when I need to add the code for the concrete methods myself....I could as well omit implementing the interface.
So how does Interfaces achieve code reusability (if it does at all)?
Coming from a C++ background, I've been told that Java achieves multiple inheritance through interfaces. One of the main purpose of Inheritance happens to be "code reuse".
Well no, Java just doesn't achieve multiple inheritance. Interfaces are the closest Java can get to multiple inheritance, but it's actually not inheritance, and it doesn't yield code reuse in the same way that inheritance can.
Where it can save you some code is that you can use all the implementations in the same way, rather than having to duplicate calling code.
VB.NET, VS 2010, .NET 4
Hello,
I've written an application. I've discovered that it is full of circular references. I would like to rewrite portions of my code to improve its design. I have read about tiered programming and want to implement something like it for my application.
Background: My application is a control program for an industrial machine. It parses a recipe (from an Excel file) which contains timing information and setpoints for the various attached devices. There are three main types of devices: Most are connected through Beckhoff terminals and communicate via TwinCAT (Beckhoff's pseudo-PLC software) and two are RS-232 devices, each with a different communication protocol. I can communicate with the Beckhoff devices via a .NET API provided by Beckhoff. I have written parser classes for the two RS-232 devices. Some of the Beckhoff devices are inputs, some are outputs; some are digital, some are (pseudo-)analog.
I think my problem is that I was trying to wrap my head around OOP while writing the application so I created classes willy-nilly without a clear idea of their hierarchy. At some points, I tried to do what I thought was right by, say, making a "Device" class which was inherited by, say, a "TwinCatDevice" class and a "Rs232Device" class. But then I just stuffed all of the communication code in those classes.
What I'm trying now is creating some communication modules (e.g., UtilTwinCat, UtilRs232) that contain abstract methods like "Connect", "Disconnect", "Read", "Write", etc. Then I'm trying to rewrite my "Device" class and subclasses to use these modules so they don't have to contain any of the (sometimes redundant) communication code.
Here's my question: Would it be good design to create separate classes for each type of communication type? i.e., should I have, say, "TwinCatReadOnlyDigital", "TwinCatReadOnlyAnalog", "TwinCatWriteOnlyDigital", "TwinCatWriteOnlyAnalog", "TwinCatReadWriteDigital", "TwinCatReadWriteAnalog", "Rs232ReadOnlyDigital", etc? Or perhaps some interfaces like IReadOnly, IWriteOnly, IDuplex?
This seems like it can't be the right approach in that I imagine someone who is good at programming wouldn't end up with a billion different classes for every eventuality. Is there some way I could selectively implement an interface on a class at run time? I think that's a stupid question... I'm still trying to wrap my head around why one would use an interface. I'm looking for some basic insight on how to grapple with this type of design problem. Specifically, if you have a lot of "things" that differ slightly, is the best approach to create lots of classes that differ slightly?
Thanks a lot in advance,
Brian
Edit: I just wanted to add, to be clear, there is a finite number of devices whose parameters are known, so it would be straightforward to write classes for all the types I'd need. I just wonder if there's a better approach.
That's not really enough information for any concrete answers, but let me make a few suggestions.
"I'm still trying to wrap my head around why one would use an interface."
Mainly because then you can "program to the interface", that is you needn't care if you're working with a Beckhoff or an RS-232 device - you only care that you can send data to it. Just to make it clear: interfaces don't contain implementations. Classes implementing an interface promise to provide concrete implementations for the functions of the interface.
Instead of IReadOnly, IWriteOnly and IDuplex use two interfaces: IWriteable and IReadable (or whatever names make sense). Duplex classes will implement both interfaces.
The Strategy or more likely the Template method patterns may help you with the slightly different classes. Maybe even simple subclassing, but keep in mind that there's often a simpler, nicer solution.
Don't repeat yourself (DRY): try to find one and only one place for every piece of logic.
Functionality shared by several classes should reside in a superclass or utility classes.
Also, more concrete questions will result in more concrete answers :)
This question already has answers here:
Closed 13 years ago.
Duplicate:
When to use an interface instead of an abstract class and vice versa?
Probably one of the most famous software developer job interview questions.
What would be your answer?
EDIT: I'm trying to find out how you would answer this in a real-life situation. Please try to formulate your answer as you would on a real job interview (be complete, but don't be too long, post no links of course).
An interface only describes the actual signature of its methods etc. Any class implementing that interface must then provide an explicit implementation.
An abstract class can contain a partial implementation of its methods etc.
An abstract class can have member variables, an interface cannot (or, in C++, should not).
In Java, an "Interface" is a well-defined syntactical element, while in C++ it's merely a design pattern.
Interfaces provide definitions of methods that must be implemented by a class. The purpose of interfaces is to allow you to generalise specific functionality regardless of implementation. You may have an IDatabase interface that has an Open/Close method. The class that implements that interface may be connecting to a MySQL database or MS Access database. Irrespective of how it accomplishes this task, the goal is still the same...Open database, close database.
Abstract classes are base classes that contain some abstract methods. They cannot be instantiated they are to be derived from. The purpose of an Abstract class is to allow you to define some generic functionality and sub-class to implement more specific functionality where appropriate.
So in summary, you should use interfaces when the implementation of each class differs completely. Use abstract classes when you have some similar behaviour but need to implement parts differently.
Hope that helps.
I would say that the difference is language dependent, but that in C++ at least, abstract classes are the means by which interfaces are implemented.
As far as job interviews are concerned, I've always heard that the key point is that an interface is a contract; an interface, while not implementing it itself, guarantees functionality.
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.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
When designing a new system or getting your head around someone else's code, what are some tell tale signs that something has gone wrong in the design phase? Are there clues to look for on class diagrams and inheritance hierarchies or even in the code itself that just scream for a design overhaul, particularly early in a project?
The things that mostly stick out for me are "code smells".
Mostly I'm sensitive to things that go against "good practice".
Things like:
Methods that do things other than what you'd think from the name (eg: FileExists() that silently deletes zero byte files)
A few extremely long methods (sign of an object wrapper around a procedure)
Repeated use of switch/case statements on the same enumerated member (sign of sub-classes needing extraction)
Lots of member variables that are used for processing, not to capture state (might indicate need to extract a method object)
A class that has lots of responsibilities (violation of Single Repsonsibility principle)
Long chains of member access (this.that is fine, this.that.theOther is fine, but my.very.long.chain.of.member.accesses.for.a.result is brittle)
Poor naming of classes
Use of too many design patterns in a small space
Working too hard (rewriting functions already present in the framework, or elsewhere in the same project)
Poor spelling (anywhere) and grammar (in comments), or comments that are simply misleading
I'd say the number one rule of poor OO design (and yes I've been guilty of it too many times!) is:
Classes that break the Single
Responsibility Principle (SRP) and
perform too many actions
Followed by:
Too much inheritance instead of
composition, i.e. Classes that
derive from a sub-type purely so
they get functionality for free.
Favour Composition over Inheritance.
Impossible to unit test properly.
Anti-patterns
Software design anti-patterns
Abstraction inversion : Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
Ambiguous viewpoint: Presenting a model (usually OOAD) without specifying its viewpoint
Big ball of mud: A system with no recognizable structure
Blob: Generalization of God object from object-oriented design
Gas factory: An unnecessarily complex design
Input kludge: Failing to specify and implement handling of possibly invalid input
Interface bloat: Making an interface so powerful that it is extremely difficult to implement
Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction.
Race hazard: Failing to see the consequence of different orders of events
Railroaded solution: A proposed solution that while poor, is the only one available due to poor foresight and inflexibility in other areas of the design
Re-coupling: Introducing unnecessary object dependency
Stovepipe system: A barely maintainable assemblage of ill-related components
Staralised schema: A database schema containing dual purpose tables for normalised and datamart use
Object-oriented design anti-patterns
Anemic Domain Model: The use of domain model without any business logic which is not OOP because each object should have both attributes and behaviors
BaseBean: Inheriting functionality from a utility class rather than delegating to it
Call super: Requiring subclasses to call a superclass's overridden method
Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
Empty subclass failure: Creating a class that fails the "Empty Subclass Test" by behaving differently from a class derived from it without modifications
God object: Concentrating too many functions in a single part of the design (class)
Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
Poltergeists: Objects whose sole purpose is to pass information to another object
Sequential coupling: A class that requires its methods to be called in a particular order
Singletonitis: The overuse of the singleton pattern
Yet Another Useless Layer: Adding unnecessary layers to a program, library or framework. This became popular after the first book on programming patterns.
Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation
This question makes the assumption that object-oriented means good design. There are cases where another approach is much more appropriate.
One smell is objects having hard dependencies/references to other objects that aren't a part of their natural object hierarchy or domain related composition.
Example: Say you have a city simulation. If the a Person object has a NearestPostOffice property you are probably in trouble.
One thing I hate to see is a base class down-casting itself to a derived class. When you see this, you know you have problems.
Other examples might be:
Excessive use of switch statements
Derived classes that override everything
In my view, all OOP code degenerates to procedural code over a sufficiently long time span.
Granted, if you read my most recent question, you might understand why I am a little jaded.
The key problem with OOP is that it doesn't make it obvious that your object construction graph should be independent of your call graph.
Once you fix that problem, OOP actually starts to make sense. The problem is that very few teams are aware of this design pattern.
Here's a few:
Circular dependencies
You with property XYZ of a base class wasn't protected/private
You wish your language supported multiple inheritance
Within a long method, sections surrounded with #region / #endregion - in almost every case I've seen, that code could easily be extracted into a new method OR needed to be refactored in some way.
Overly-complicated inheritance trees, where the sub-classes do very different things and are only tangentially related to one another.
Violation of DRY - sub-classes that each override a base method in almost exactly the same way, with only a minor variation. An example: I recently worked on some code where the subclasses each overrode a base method and where the only difference was a type test ("x is ThisType" vs "x is ThatType"). I implemented a method in the base that took a generic type T, that it then used in the test. Each child could then call the base implementation, passing the type it wanted to test against. This trimmed about 30 lines of code from each of 8 different child classes.
Duplicate code = Code that does the same thing...I think in my experience this is the biggest mistake that can occur in OO design.
Objects are good create a gazillion of them is a bad OO design.
Having all you objects inherit some base utility class just so you can call your utility methods without having to type so much code.
Find a programmer who is experienced with the code base. Ask them to explain how something works.
If they say "this function calls that function", their code is procedural.
If they say "this class interacts with that class", their code is OO.
Following are most prominent features of a bad design:
Rigidity
Fragility
Immobility
Take a look at The Dependency Inversion Principle
When you don't just have a Money\Amount class but a TrainerPrice class, TablePrice class, AddTablePriceAction class and so on.
IDE Driven Development or Auto-Complete development. Combined with extreme strict typing is a perfect storm.
This is where you see what could be a lot of what could be variable values become class names and method names as well as the gratuitous use of classes in general. You'll also see things like all primitives becoming objects. All literals as classes. Function parameters as classes. Then conversion methods everywhere. You'll also see things like a class wrapping another delivering a subset of methods to another class inclusive of only the ones it needs at present.
This creates the possibility to generate an near infinite amount of code which is great if you have billable hours. When variables, contexts, properties and states get unrolled into hyper explicit and overly specific classes then this creates an exponential cataclysm as sooner or later those things multiply. Think of it like [a, b] x [x, y]. This can be further compounded by an attempt to create a full fluent interface as well as adhere to as many design patterns as possible.
OOP languages are not as polymorphic as some loosely typed languages. Loosely typed languages often offer runtime polymorphism in shallow syntax that static analysis can't handle.
In OOP you might see forms of repetition hard to automatically detect that could be turned into more dynamic code using maps. Although such languages are less dynamic you can achieve dynamic features with some extra-work.
The trade of here is that you save thousands (or millions) of lines of code while potentially loosing IDE features and static analysis. Performance can go either way. Run time polymorphism can often be converted to generated code. However in some cases the space is so huge that anything other than runtime polymorphism is impossible.
Problems are a lot more common with OOP languages lacking generics and when OOP programmers try to strictly type dynamic loosely typed language.
What happens without generics is where you should have A for X = [Q, W, E] and Y = [R, T, Y] you instead see [AQR, AQT, AQY, AWR, AWT, AWY, AER, AET, AEY]. This is often due to fear or using typeless or passing the type as a variable for loosing IDE support.
Traditionally loosely typed languages are made with a text editor rather than an IDE and the advantage lost through IDE support is often gained in other ways such as organising and structuring code such that it is navigable.
Often IDEs can be configured to understand your dynamic code (and link into it) but few properly support it in a convenient manner.
Hint: The context here is OOP gone horrifically wrong in PHP where people using simple OOP Java programming traditionally have tried to apply that to PHP which even with some OOP support is a fundamentally different type of language.
Designing against your platform to try to turn it into one your used to, designing to cater to an IDE or other tools, designing to cater to supporting Unit Tests, etc should all ring alarm bells because it's a significant deviation away from designing working software to solve a given category of problems or a given feature set.