Let's say I created Circle and Triangle classes inherited from Shape class. My question is how do I prevent code from creating instances of the Shape class?
You make the Shape class abstract. That means it is an unfinished class serving as base for other classes that supply the additional functionality.
For instance, if you have sever classes that load data, you could have an abstract class DataLoader and concrete classes DatabaseLoader, XmlLoader ...
Give Shape a protected constructor. Circle and Triangle can still call those from their own constructors. But others cannot.
Dante Jinag is ofcourse right for Java, I was assuming C++
You can make Shape class as abstract.
public abstract class Shape {
//your code
}
What programming language you're using?
In general object creation is memory allocation for it members and call of constructor. If your Shape class didn't have a members - no memory will allocated. And if it has empty constructor - also nothing will happend at this step.
Related
Say I have an interface Interface and a concrete class ConcreteClass that implements Interface. Now consider a third class MyClass. If instances of MyClass hold a reference to ConcreteClass:
Interface ref = new ConcreteClass();
then should I associate MyClass with Interface or ConcreteClass in UML class diagram?
Thanks
That depends on what the public interface of MyClass defines.
If the public interface makes an Interface available, then you should link to that on the diagram. This would be the usual approach as the Interface is the general type and specifies the contract. Unless you have a reason to limit to ConcreteClass, don't.
If the public interface makes a ConcreteClass available, then you should link to that on the diagram.
The fact that at runtime a variable of type Interface actually holds an instance of ConcreteClass is beside the point. The diagram represents the relationships.
Solely with the Interface. The point is that you want the behavior of the interface. Whatever the implementation is of that interface is for the picture of no importance. MyClass has a relation with the interface, not with the implementation of the interface.
This principle is called Design By Interface. In the answer given by nakosspy is it his first picture. But it would even be better to leave the implementation of ConcreteClass out of the picture. The implementation is of no importance at that conceptual level. If there is a variable pointing to an interface, then is it obvious to the educated reader that there should be a concrete implementation as well.
If you would make a reference to the ConcreteClass then would you have to change the diagram everytime you change the implementation of the interface. That is not what you want. It is bad coding practice and bad uml practice.
It is good coding practice to separate the declaration of the relationship between MyClass and the Interface and the practical implementation of the Interface. By example:
Interface ref = new ConcreteClass();
should never happen in the class MyClass.
You should have something like this instead:
class MyClass
Interface ref;
setRef(){
ref = InterfaceImplementation();
}
}
This way can you change the implementation of Interface without changing one line of code in MyClass. Altough this might look much ado when you write one class, think of it when you are managing hundreds of classes.
So: it depends.
It's equally legal to associate MyClass with ConcreteClass or Interface. You won't find the answer to your question in the UML spec. Why? Because the answer lies in your problem domain, not the modelling language.
Consider two contrived examples to illustrate the point.
Example 1: Association between Classes
Substitute:
ICanBark for Interface
Dog for ConcreteClass
Trainer for MyClass
Let's assume the association we want to capture is Trains, i.e.
Each Trainer trains many Dogs
Each Dog is trained by at most one Trainer
In this case the association exists because of the 'Dogginess', not the 'Barkiness'. So it properly exists between the two classes.
Example 2: Association between Class and Interface
Substitute:
ILogger for Interface
FileLogger for ConcreteClass
Application for MyClass
In this case the relationship is about the 'Logginess', not the 'Fileness'. Application shouldn't care how the interface is implemented; it just wants a way to log messages. So the Association exists between the Class and the Interface
Summary
As is nearly always the case with Associations, the key to solving the problem lies in the problem domain itself - not the modelling language.
hth.
There are 2 ways to present the ref variable of MyClass: You can present it as attribute or as association. Then there are two alternative notations for the Interface interface: Square with the interface stereotype or circle. This makes 2*2=4 alternatives.
Show ref as association and use square interface notation.
Here you can't show the initial value that ref takes. That's because you can't show default values in associations.
Show ref as association but use the circle notation for the Interface.
As it was with the previous alternative, again here you can't show the initial value.
Show ref as attribute and use square interface notation.
Here you can show the default value, because you can do that for attributes. The relationship between MyClass and Interface is presented as a dependency. The same happens for the dependency between MyClass and ConcreteClass.
Note that this dependency (MyClass depends on ConcreteClass) can be presented also in the alternatives 1 and 2, you can add a dependency arrow (dashed) pointing from MyClass to ConcreteClass.
Show ref as attribute and use circle interface notation.
Again here you can show the default value.
If we count also the alternatives derived from presenting or not the dependencies, then there are at least 6 ways to present the same thing. Now the question is which to chose.
It depends on what do you want to visualize with the diagram and for whom the diagram is intended. In this case if the initialization of ref is the message, then you should use an alternative that presents it. If it's less important, then you might prefer a diagram that shows ref as association.
In a real problem you have more elements, so it makes much more alternatives. It's always up to you to decide what to present and how.
EDIT: Some references to help you understand the notation of interface implementation.
According to wikipedia:
A realization is a relationship between classes, interfaces,
components, and packages that connects a client element with a
supplier element. A realization relationship between classes and
interfaces and between components and interfaces shows that the class
realizes the operations offered by the interface.
You can find some quick reference examples and a lot of information at uml-diagrams.org.
This excellent answer Explanation of the UML arrows will help you with more examples.
Here you can also find some more info on realization.
You can define reference to concrete class as:
Attribute typed as Interface (or ConcreteClass) defined in MyClass, or
Association between MyClass and Interface (or ConcreteClass).
no more options are avialable
Not to sound like a koan, but just wondering if there are definite rules about classes and objects. I used to think classes as blueprints, and objects as the creation from them. But if a combination of blueprints creates another blueprint, does the latter blueprint become an object as well?
Your question seems a bit philosophical... :) "object" and "instance" are quite synonymous in OOP.
If I understood your question correctly, your doubt is: "an object is still an object also if created by another class that is not the same that define its type?"
The answer is "yes", an instance is an object created following the "model" defined by its class, but for many reasons you could instantiate a class in an indirect way, for example a static method (factory method of a factory class, for example) and not directly using new statement.
If you want to see some come, an easy example in Java could be:
public class MyClass {
public MyClass(){}
}
public class MyClassFactory{
public getInstance(){
return new MyClass();
}
}
In this case the instance is not returned directly by MyClass, but from its factory class. however it's an object as well...
In just about every OO environment I know, an instance is the same as an object.
It doesn't matter whether the object/instance is created by the client (such as with new) or by the class (such as with singletons or factories).
If you're talking about blueprints in the context of classes, then creating blueprints from blueprints is inheritance, not instantiation.
I have to implement a small graph library for my small Scala + JMonkey Engine game. Library will deal with shortest path caching for further queries. I will have to attach additional user data (like reference to another object) to my Vertexes and Edges. How to implement this behavior?
With:
1. parameterized class class Graph[A, B] {...}, or
2. provide abstract class Graph {...} and implement user data variables later, or
3. provide abstract class Graph {...} and define type A inside the class?
Or maybe I'm missing something else?
Here's a good article on this topic
There are also traits which are mix between interface and concrete implementation.
I've been reading a lot about interfaces and class inheritance in Java, and I know how to do both and I think I have a good feel for both. But it seems that nobody ever really compares the two side by side and explains when and why you would want to use one or the other. I have not found a lot of times when implementing an interface would be a better system than extending a superclass.
So when do you implement an interface and when do you extend a superclass?
Use an interface if you want to define a contract. I.e. X must take Y and return Z. It doesn't care how the code is doing that. A class can implement multiple interfaces.
Use an abstract class if you want to define default behaviour in non-abstract methods so that the endusers can reuse it without rewriting it again and again. A class can extend from only one other class. An abstract class with only abstract methods can be as good definied as an interface. An abstract class without any abstract method is recognizeable as the Template Method pattern (see this answer for some real world examples).
An abstract class in turn can perfectly implement an interface whenever you want to provide the enduser freedom in defining the default behaviour.
You should choose an interface if all you want is to define a contract i.e. method signatures that you want the inheriting classes to implement. An interface can have no implementation at all. The inheriting classes are free to choose their own implementation.
Sometimes you want to define partial implementation in a base type and want to leave the rest to inheriting classes. If that is the case, choose an abstract class. An abstract class can define method implementations and variables while leaving some methods as abstract. Extending classes can choose how to implement the abstract methods while they also have the partial implementation provided by the superclass.
One extreme of abstract classes is a pure abstract class - one that has only abstract methods and nothing else. If it comes to pure abstract class vs. an interface, go with the interface. Java allows only single implementation inheritance whereas it allows multiple interface inheritance meaning that a class can implement multiple interfaces but can extend only one class. So choosing a pure abstract class over the interface will mean that the subclass will not be allowed to extend any other class while implementing the abstract methods.
Use an interface to define behavior. User (abstract) classes (and subclasses) to provide implementation. They are not mutually exclusive; they can all work together.
For example, lets say you are defining a data access object. You want your DAO to be able to load data. So put a load method on the interface. This means that anything that wants to call itself a DAO must implement load. Now lets say you need to load A and B. You can create a generic abstract class that is parameterized (generics) to provide the outline on how the load works. You then subclass that abstract class to provide the concrete implementations for A and B.
The main reason for using abstract classes and interfaces are different.
An abstract class should be used when you have classes that have identical implementations for a bunch of methods, but vary in a few.
This may be a bad example, but the most obvious use of abstract classes in the Java framework is within the java.io classes. OutputStream is just a stream of bytes. Where that stream goes to depends entirely on which subclass of OutputStream you're using... FileOutputStream, PipedOutputStream, the output stream created from a java.net.Socket's getOutputStream method...
Note: java.io also uses the Decorator pattern to wrap streams in other streams/readers/writers.
An interface should be used when you just want to guarantee that a class implements a set of methods, but you don't care how.
The most obvious use of interfaces is within the Collections framework.
I don't care how a List adds/removes elements, so long as I can call add(something) and get(0) to put and get elements. It may use an array (ArrayList, CopyOnWriteArrayList), linked list (LinkedList), etc...
The other advantage in using interfaces is that a class may implement more than one. LinkedList is an implementation of both List and Deque.
No one?
http://mindprod.com/jgloss/interfacevsabstract.html
EDIT: I should supply more than a link
Here's a situation. To build on the car example below, consider this
interface Drivable {
void drive(float miles);
}
abstract class Car implements Drivable {
float gallonsOfGas;
float odometer;
final float mpg;
protected Car(float mpg) { gallonsOfGas = 0; odometer = 0; this.mpg = mpg; }
public void addGas(float gallons) { gallonsOfGas += gallons; }
public void drive(float miles) {
if(miles/mpg > gallonsOfGas) throw new NotEnoughGasException();
gallonsOfGas -= miles/mpg;
odometer += miles;
}
}
class LeakyCar extends Car { // still implements Drivable because of Car
public addGas(float gallons) { super.addGas(gallons * .8); } // leaky tank
}
class ElectricCar extends Car {
float electricMiles;
public void drive(float miles) { // can we drive the whole way electric?
if(electricMiles > miles) {
electricMiles -= miles;
odometer += miles;
return; // early return here
}
if(electricMiles > 0) { // exhaust electric miles first
if((miles-electricMiles)/mpg > gallonsOfGas)
throw new NotEnoughGasException();
miles -= electricMiles;
odometer += electricMiles;
electricMiles = 0;
}
// finish driving
super.drive(miles);
}
}
I think that interfaces work best when you use them to express that the object has a certain property or behavior, that spans multiple inheritance trees, and is only clearly defined for each class.
For example think of Comparable. If you wanted to create a class Comparable to be extended by other classes, it would have to be very high on the inheritance tree, possible right after Object, and the property it expresses is that two objects of that type can be compared, but there's no way to define that generally (you can't have an implementation of compareTo directly in the Comparable class, it's different for every class that implements it).
Classes work best when they define something clear, you know what properties and behaviors they have, and have actual implementations for methods, that you want to pass down to the children.
So classes work when you need to define a concrete object like a human, or a car, and interfaces work better when you need more abstract behavior that's too general to belong to any inheritance tree, like the ability to be compared (Comparable) or to be run (Runnable).
One method of choosing between an interface and a base class is the consideration of code ownership. If you control all the code then a base class is a viable option. If on the other hand many different companies might want to produce replaceable components, that is define a contract then an interface is your only choice.
I found some articles, particularly some who describe why you should not use implementation inheritance (i.e. superclasses):
Why extends is evil
Inheritance of implementation is evil
Implementation inheritance
Implementation inheritance
Java inheritance FAQ
I guess I'll give the classic car example.
When you have a car interface, you can create a Ford, a Chevy, and an Oldsmobile. In other words, you create different kinds of cars from a car interface.
When you have a car class, you can then extend the car class to make a truck, or a bus. In other words, you add new attributes to the sub classes while keeping the attributes of the base or super class.
You can think of extending from a super class if the derived class is of the same type.I mean that when a class extends an abstract class, they both should be of the same type, the only difference being that the super class has a more general behavior and the sub class has a more specific behavior. An interface is a totally different concept. When a class implements an interface, its either to expose some API(contract) or to get certain behavior. To give an example, I would say that Car is an abstract class. You can extend many classes from it like say Ford, Chevy and so on which are each of type car. But then if you need certain specific behavior like say you need a GPS in a car then the concrete class, eg Ford should implement GPS interface.
If you only want to inherit method signatures (name, arguments, return type) in the subclasses, use an interface, but if you also want to inherit implementation code, use a superclass.
If I have an abstract class and derived classes of that class, am I correct that, according to good and practical design practice, that the derived classes should not provide extra public methods (they should only implement abstract classes and optionally override parent methods)?
Furthermore, is it acceptable practice to have a different constructor method signature for each derived class?
Personally, I see no problem with either.
As for extra public methods on derived classes:
There is limited usefulness in this, in many cases. The extra methods will not be usable when the class has been cast or set to an reference to the base class, which severely limits usefulness of this practice. That being said, there isn't anything particularly wrong with this approach. Subclasses are meant to add specific behavior - sometimes, in a class hierarchy, there is new behavior in a subclass that isn't appropriate for the base class. If the subclass is going to be used frequently on its own, it seems perfectly reasonable for the extra behavior to be modeled in the methods.
As for constructor signatures -
I see no problem with this either. Subclasses often need more information to be put into a usable state than the abstract class. That being said, I typically make sure to implement every constructor in the base class, plus add the new parameters required for the subclass.
That being said:
Unless there is good reason, I'd avoid having a subclass constructor with fewer parameters than the base class ... why would I be able to specify something on a more generic case and not the specific case? I find that it's usually confusing when subclasses have completely different construction options than their base classes.
This is the beauty of derived classes.
While a Pen class might have a write() function, a RetractablePen class which extends Pen might also have a retractPoint() function.
When you extend a class it means -- literally -- extending the functionality of it.
It's fine in general.
What you want to avoid is using the specific in the generic. i.e.
foreach(Animal a in myFarm.Animals)
{
a.Feed();
// this is a bit grim
if( a is Horse )
{
((Horse)a).CleanStable();
}
}
So it's not the act of adding the public method but rather where you call them from.
It's perfectly acceptable to add additional public methods to your derived classes. It's also perfectly acceptable to give them different contructors. (In fact, this is quite common.)
No, it's perfectly reasonable (and sometimes very necessary by design) to add additional public methods. Consider the (completely contrived) situation of a Shape abstract base class that has a Location member and a Size method. When you derive Polygon from Shape, for example, you may want to add a public method called GetNumberOfSides(), for example; but you don't want to have that when you derive Circle from Shape.
In the same way, the derived types may have very different construction requirements; it's not really possible to know what all the requirements may be when defining the abstract base class, so feel free to have differing signatures. Just because your dervied types will be polymorphic to the abstract base class doesn't mean that that base class imposes strict limitations on how you can implement the abstractions defined in that base class; you're free to pretty much do it however you want.
If you respect the Liskov substitution principle, you can do what you want.
Of course, add a method to a derived class doesn't violate the principle at all.
the derived classes should not provide extra public methods
Can a dog do things that an animal can't?
Furthermore, is it acceptable practice to have a different constructor method signature for each derived class?
There's no problem here. Derived types are not required to match constructor signatures of their siblings or parents.
It is not only acceptable, it is often necessary for the constructors to be different. For example, if we have an (immutable) Rectangle class and extend it with an (immutable) Square, the constructor of Square should be (to use Java for the moment)
public Square(double size)
while the constructor of Rectangle would be
public Rectangle(double width, double height)
What does need to happen is that the subclass constructor should call some appropriate superclass constructor.
As to extra public methods, it may depend on the use. For the Square case, I would not add any extra methods. In Java, however, there is a subclass PrintWriter of Writer
whose purpose is to add some convenience methods. In this case I think it okay (Java certainly has some bad examples but I don't think this is one of them). I would also expect the possibility of some extra methods for container/subpart types.
What you shouldn't do is change the super classes methods in a way that violates the expectations of the super class.