Does open-for-extension and closed-for-modification mean code-to-an-interface?
If I code to an interface so that future concrete implementations can be introduced by implementing the interface, and we create new classes without touching existing logic, does it achieve the same goal we try to address using the open-for-extension and closed-for-modification SOLID principle?
I would say that code-to-an-interface solves the open-close-principle (OCP) but there are other ways to code-to-an-interface.
Code-to-an-interface could also mean to code to an abstract-class like InputStream.
Also the use of CDI could allow beans to be closed-for-modification and open-for-extensions.
This means that you must not use interfaces but you can in order to use OCP.
If I code to an interface (...) does it achieve (...) SOLID principle?
Yes, you follow the SOLID principle. But implementors of the interface might not.
Usually the interface is separated into a method-signature and the javadoc. The method-signature specifies what you technically could do and the javadoc should specify what the implementation should do. Both ways, signature and doc are hard facts and a implementation that violates either the signature or the javadoc mostly should reported as a bug.
So you can either use a existing interface for common requirements or a new interface for specific requirements. If you create a new interface you might think about the interface-segregation-principle what also is part of the SOLID-principle-collection.
If you design this interface you must be open for requirements of the implementor. In example if the interface is like this:
Date readDate(InputStream in);
There might be some requirements from the implementors you could never have foreseen:
You should add a IOException in the case the stream is closed.
You should add a Charset-Parameter because the charset is ASCII what means the bitlength is 7 bit, not 8 bit.
You should add a Timezone because Date use the timezone of the server whearat the stream sources from a different timezone.
You should add Locale because the year/month/day format (UK) could be year-month-day format (GER) in a different locale.
Theese requirements might appear after you coded-to-an-interface. I would say those requirements to the interface forces you to modify your code-to-an-interface that are closed. You could say, yes this is a modification that violates against closed-for-modifications. But none of theese "requirements to the interface" really need to modify the behaviour of your code-to-an-interface.
Related
I know how i can realize a implementation of a class with the policy based design pattern from c++ with Interfaces. I don't know how to do the same with class mixin's.
This would be useful if you want to squeze the last performance out of your code because it is easy inlinable and the "border" of the virtual calls for the interfaces is not there.
I wrote a blog post which might be relevant: Low-overhead components. It discusses using mixins as building blocks for creating flexible, configurable and high-performance components, and the associated caveats.
You mean C++-style policy based design pattern (as explained in Modern C++ Design)? In D you can use static if instead which is simpler.
I am pretty aware of the benefits of interfaces and how it helps aggregate common functionality of similar types of objects. However I believe people have taken this 'always program to an interface' a bit too far.
a) People starting off by ALWAYS defining an interface and then implementing it in a class even if that interface is too specific to be implemented by any other class. - Am I the only one who thinks that this serves no useful purpose?
b) Forcing all 'related' interfaces to derive for a common (useless) interface because it is now 'extendable' - What?
c) What do you do in scenarios where two or more objects seem related but it is very difficult to define common interface methods because of its underlying differences?
Lets say for example, an interface named IConnection with a Connect() method. (this is how most examples trivialize interfaces). The problem is, different type of classes that implement the IConnection interface might require different data for establishing the connection, some might require a user name and password, some might require some kind of special connection key, some might require nothing at all. The Connect method as a contract is perfectly valid as each class will need some way of establishing a connection but the data they need is different.
Is an interface required in this case? If it is, how do you define the Connect method? If not, how do you prove that your concrete classes are still 'extendable'?
Sorry for the long rant, this has been bugging me for quite some time now. Most people after reading the famous design patterns book try to implement every possible pattern in everything they do without bothering to figure out whether it helps. I believe the pattern should be brought into play when you are faced with a problem not just for the heck of it.
In your IConnection example you're basically describing an abstract Connect() method, since each class will have to implement its own version. Usually (always?) abstract methods can only be defined with the same parameters, so Connect(username, password) and Connect(key) couldn't be implementations of the same Connect() method from an interface.
Now, at this point, you could define it as IConnection::Connect(SomeConnectionData) and derive UsernamePasswordConnectionData and KeyConnectionData, etc., etc. from that SomeConnectionData class but all this would be so hard to explain and implement that its pretty good clue that interfaces and inheritance aren't helping the situation.
If it makes programming it and using it harder, don't do it. If something is made "extendable" by becoming too complex to understand, no will extend it anyway. It's perfectly okay to define a bunch of classes, each with their own Connect() methods just as a convention.
From a design point of view, can I say that Interfaces are used to produce flexible code open for future easy maintenance. Referring to the case study, am I right to say:
Interface in this example is used because both Professor and HeadofDept class have the power to employ people. Assuming that we might add other people who might be given the right to employ people in the near future.
Thanks for your attention.
Interface will allow your code to call methods like employPeople() on the base type i.e EmployerProfessor. So you pass around EmployerProfessor objects and code need not know what the exact implementation is, it just knows that it can call employPeople(). So it allows for dynamic dispatch of method calls. Using some compiler implementation (vtable etc) it will call the correct method for you.
Interfaces are not always so flexible, its difficult to go and just change an interface since current code in the wild may be affected. An interface provides a contract, it tells the class implementing it, that you must provide the following methods.
Trying to code to an interface so that unit testing and design are better. Some things that I am coding doesn't seem to have any other implementation other than the obvious one. Is there a naming convention for this?
If you've only got one implementation, why not name your interface after it? You can always refactor the name later, if a second implementation comes along.
Most of the time, we do name our interfaces after the implementation that inspired them. If we then find that we get a second implementation of that interface, we'll either rename the original implementation to be more specific or rename the interface to be more general.
Often when I create new classes, I first create a new interface. I name the methods of my interface exactly as I would like them to behave. A colleague of mine prefers to have these method names being more abstract, ie: areConditionsMet(). The reason, he wants to hide the 'implementation details'.
IMO implementation details are different from the expected behavior. Could anyone perhaps give more insight. My goal is to reach a common ground with my colleague.
Your method names should describe what the method does, but not how it does it. The example you gave is a pretty poor method name, but it's better than isXGreatherThan1AndLessThan6(). Without knowing the details about what it should do, I would say that it should be specific to the problem at hand, but general enough that the implementation could change without affecting the name itself, i.e., you don't want the name of the method to be brittle. An example might be isTemperatureWithinRange() - that describes what I'm checking but doesn't describe how it's accomplished. The user of the method should be confident that the output will reflect whether the temperature is within a certain range -- whether this is supplied as an argument or defined by the contract of the class, is immaterial.
Interfaces should represent some behavior or capability and not the way it is to be accomplished. Users of interfaces should not be interested in the way a target is achieved, they just want to know its done.
Implementation issues should not be included within the name of methods for that exact reason. The name of the table updated as a result of this method or the technology used has nothing to do in your domain object's method's name.
However from your question it is hard to say what is the exact case at hand.
If you could provide more details perhaps i could provide an additional help.
The names of your interface methods should leave the user of the interface in no doubt about what the method proposes to do from a functional perspective. If the implementation matches that, well and good.
Based on your updated comments:
Sounds to me like you need two methods: isModified() and hasProperties(). Leave it up to the user (or higher layer) of the domain object to determine if a particular criteria is fulfilled.
An interface should also be designed with the view that after it is released it will never be changed. By saying isDomainObjectModifiedAndHasProperties() you are setting in concrete that this is the criteria of fullfilment (regardless of any future unforseen implementation).