I have been programming in Java for nearly two years but I am now more shifting to web programming and thus to Javascript, or in my case to Dart. For a project I'm working on I would like to have abstract base classes, just I would have in Java. I have been looking on the internet but I can't find anything on abstract classes at all for Dart. I only found this article from the dart lang site on mixins, that in an example uses the abstract keyword for a class. But I don't really understand the mixins principle.
Could somebody translate this easy Java abstract base class example to Dart so that I can have a basic understanding on how it would be done in Dart? The example covers abstract base class (ofcourse, with abstract methods), polymorphism, casting objects, method overloading (in this case it is the constructor), calling super-constructor and calling overloaded own constructor.
// Abstract base class
abstract class Vehicle {
protected final int maxSpeed;
protected int speed;
Vehicle() {
this(0);
}
Vehicle(int maxSpeed) {
this.maxSpeed = maxSpeed;
speed = 0;
}
public int getMaxSpeed() {
return maxSpeed;
}
abstract void accelerate();
abstract void brake();
}
// Subclass of Vehicle, the abstract baseclass
class Car extends Vehicle {
public final int doors;
Car(int maxSpeed, int doors) {
super(maxSpeed);
this.doors = doors;
}
#Override
void accelerate() {
if (speed>maxSpeed) {
speed = maxSpeed;
return;
}
speed += 2;
}
#Override
void brake() {
if (speed - 2 < 0) {
speed = 0;
return;
}
this.speed -= 2;
}
}
And how would this easy implementation look like?
// Polymorphism
Vehicle car = new Car(180, 4);
// Casting
int doors = ((Car)car).doors;
// Calling abstract method
car.accelerate();
I would take a look at the Language tour, there's a whole section on abstract classes
Key points:
Abstract classes in Dart have to be marked as abstract.
An abstract class can have "abstract methods", you just have to omit the body
A concrete class can mark itself as "implementing" the abstract class' contract with the keyword implements. This will force you to implement all the expected behavior on the concrete class, but it won't inherit the abstract class' provided methods' implementation.
You can extend an abstract class with the keyword extends, and the concrete class will inherit all possible behavior of the abstract class.
That's pretty much it!
Also, you might want to take a look at mixins, there's a section below the one I have you in the Language tour.
Actually it does become simpler in dart (https://dartpad.dartlang.org/37d12fa77834c1d8a172)
// Abstract base class
abstract class Vehicle {
final int maxSpeed;
int speed = 0;
Vehicle([this.maxSpeed = 0]);
void accelerate();
void brake();
}
// Subclass of Vehicle, the abstract baseclass
class Car extends Vehicle {
final int doors;
Car(int maxSpeed, this.doors) : super(maxSpeed);
#override
void accelerate() {
if (speed > maxSpeed) {
speed = maxSpeed;
return;
}
speed += 2;
}
#override
void brake() {
if (speed - 2 < 0) {
speed = 0;
return;
}
this.speed -= 2;
}
}
main() {
// Polymorphism
Vehicle car = new Car(180, 4);
// Casting
int doors = (car as Car).doors;
// Calling abstract method
car.accelerate();
}
Related
I'm trying to create a class heirachy for a game, there is an Item class which is the base class for all items in the game. The problem is that some derived items (like potion) might not implement some of the abstract methods defined by the item.
Is it ok for derived classes to implement an abstract method with "do nothing"?
Example: https://dotnetfiddle.net/jJABN1
using System;
using System.Collections.Generic;
public abstract class Item
{
public abstract void Use();
}
public class Potion : Item
{
public override void Use()
{
// do nothing
return;
}
}
public class Sword : Item
{
public override void Use()
{
Console.WriteLine("Sword used!");
return;
}
}
public class Program
{
public static void Main()
{
List<Item> items = new List<Item>();
Item potion = new Potion();
Item sword = new Sword();
items.Add(potion);
items.Add(sword);
for (int i = 0; i < items.Count; i++)
{
Item item = items[i];
item.Use();
}
}
}
One of Robert Martin's SOLID Principles - Interface Segregation Principle addresses this situation. It basically says that a client should not be exposed to methods it doesn't need.
An example of violating the Interface Segregation Principle:
// Abstraction
public abstract class Printer
{
public abstract void Print();
public abstract void Scan();
}
// Implementations
public class SomeAllInOnePrinter : Printer
{
public override void Print()
{
Console.WriteLine("Printing...");
}
public override void Scan()
{
Console.WriteLine("Scanning...");
}
}
public class SomeBasicPrinter : Printer
{
public override void Print()
{
Console.WriteLine("Printing...");
}
public override void Scan()
{
// Basic printers can't scan
}
}
This is usually solved by separating an abstract class to multiple smaller abstract classes that can optionally inherit one other:
// Abstractions
public abstract class Printer
{
public abstract void Print();
}
public abstract class AllInOnePrinter : Printer
{
public abstract void Scan();
}
// Implementations
public class SomeAllInOnePrinter : AllInOnePrinter
{
public override void Print()
{
Console.WriteLine("Printing...");
}
public override void Scan()
{
Console.WriteLine("Scanning...");
}
}
public class SomeBasicPrinter : Printer
{
public override void Print()
{
Console.WriteLine("Printing...");
}
}
Technically, there could be an edge-case (should be uncommon!) where a deriving class doesn't need to implement all the methods, in such a case I'd rather it to override and throw an error to signal the user that this method should not be used.
That said, in the provided example there is only one method, so the question is: if a derived class doesn't need this method - why do you need to inherit the abstract class to begin with? if it's just in order to provide an example that's understandable - but better improve the example to include other methods that are used in the derived class.
I'm having problems understanding the difference between the use of Interfaces and abstract classes.
For example, please see the following UML diagramm:
What is the difference between these two?
I'll provide an explanation with code and a shorter explanation. If you don't want to read, just skip to the "plain English explanation" below.
Explanation with code
In C++ terms an abstract class is a class which implement some methods but don't implement other methods. That means: you can use some of their methods, but you'll have to implement the non-implemented ones.
Interfaces are pure classes in C++, that is, a class which doesn't implement anything and you must implement everything if you want your class to be conformant to that interface.
E.g. - try this out with the link below
#include <iostream>
using namespace std;
// Shape is abstract class: some methods are already available, some are not
class Shape
{
public:
// This is already implemented and ready for polymorphism
virtual void area() { cout<<"Shape area"<<endl;}
// You MUST implement this
virtual void implement_me() = 0;
};
class Circle : public Shape
{
public:
virtual void area() { cout<<"Circle area"<<endl;}
void implement_me() { cout<<"I implemented it just because I had to"<<endl;}
};
class HalfCircle : public Circle
{
public:
virtual void area() { cout<<"HalfCircle area"<<endl;}
};
// ShapeInterface is a pure class or interface: everything must be implemented!
class ShapeInterface
{
public:
virtual void area() = 0;
};
class CircleFromInterface : public ShapeInterface
{
public:
// You MUST implement this!
virtual void area() { cout<<"CircleFromInterface area from interface"<<endl;};
};
int main() {
Shape* ptr_to_base = new HalfCircle();
ptr_to_base->area(); // HalfCircle area, polymorphism
ptr_to_base->Shape::area(); // Shape area
ptr_to_base->implement_me(); // from Circle
ShapeInterface *ptr_to_base_int = new CircleFromInterface();
ptr_to_base_int->area(); // Just the derived has it
return 0;
}
http://ideone.com/VJKuZx
Plain-English Explanation
If you want the over-simplified version:
Interfaces are usually "contracts" which you need to adhere in toto: you need to agree with everything and implement everything or it doesn't work.
Abstract classes are partial-contracts, there are some things which you must agree/implement, but there's also some other stuff which is already there and you can choose whether to re-implement it (override) or just be lazy and use the existing ones.
Abstract classes used for dealing with code duplication between subclasses, because they can share common logic and data. Interfaces just define common contract of implementors.
So, if there is no common implementation to share, then use interface (I always start with interface). If some common implementation will appear, then extract abstract base class and move common code there. But even in this case I keep interface in hierarchy, because it's easy to mock and it is more abstract, which allows other classes not depend on any implementation at all.
In your case I think Circle and HalfCircle share some implementation. So I would go with moving common code to Circle and inheriting HalfCircle from itŠ–
public class Circle : IShape
{
public double Radius { get; set; }
public virtual double Area
{
get { return Math.PI * Radius * Radius; }
}
}
public class HalfCircle : Circle
{
public override double Area
{
get { return base.Area / 2; }
}
}
If all shapes share some data or logic for calculating area, then it makes sense to declare base abstract Shape class for this common code. But if you will look at area calculation of square, there is nothing common with circle:
public class Square : IShape
{
public double Side { get; set; }
public double Area
{
get { return Side * Side; }
}
}
So IShape interface would be enough, because classes share only contract:
public interface IShape
{
double Area { get; }
}
An inheritance relationship, potentially using an abstract class, can usually be described as 'is a' and the implementation of an interface is a 'can be'. This concept can help when choosing which to use.
So if a Square 'is a' shape then inheritance would be an acceptable way of modelling this relationship.
Furthermore, an abstract class will give you the ability to provide common features. Where as an interface cannot contain any implementation.
I have a question on object-oriented programming.
If there is a attribute which has different value in sub-classes. It should create a abstract accessor in the super-class, then override it in the sub-classes. Or create a protected instance variable in base-class, and assign the default value in the sub-class constructor?
Let's see the code example code:
Choice 1:
class BaseClass {
public abstract int GetFoo();
}
class SubClass {
public int GetFoo() {
return -1;
}
}
Choice 2:
class BaseClass {
protected int _foo;
public int GetFoo() {
return _foo;
}
}
class SubClass {
public SubClass() {
_foo = -1;
}
}
Or any ideas?
I would go with the first approach of providing a getter that can be overridden in the derived classes to provide a different value, instead of creating protected members in my class which are also package-private and violate the encapsulation principle.
I was reading about SOLID and other design principles. I thought ISP was the same as "Program to an interface, not an implementation". But it looks like these are different principles?
Is there a difference?
Robert Martin has a very good explanation of Interface segregation principle (ISP), in his book "UML for Java Programmers". Based on that, I don't think ISP is about an interface being "focused" on one logical, coherent group of things. Because, that goes without saying; or, at least it should go without saying. Each class, interface or abstract class should be designed that way.
So, what is ISP? Let me explain it with an example. Say, you have a class A and a class B, which is the client of class A. Suppose, class A has ten methods, of which only two are used by B. Now, does B need to know about all ten methods of A? Probably not - the principle of Information hiding. The more you expose, the more you create the chance for coupling. For that reason, you may insert an interface, call it C, between the two classes (segregation). That interface will only declare the two methods that are used by B, and B will depend on that Interface, instead of directly on A.
So now,
class A {
method1()
method2()
// more methods
method10()
}
class B {
A a = new A()
}
will become
interface C {
method1()
method2()
}
class A implements C{
method1()
method2()
// more methods
method10()
}
class B {
C c = new A()
}
This, prevents B from knowing more than it should.
ISP is focused on the idea of each interface representing one discrete and cohesive behavior.
That is, each logical group of things an object should do would map to a single specific interface. A class might want to do several things, but each thing would map to a specific interface representing that behavior. The idea is each interface is very focused.
Assume that you have one fat interface with many methods to be implemented.
Any class, that implements that fat interface has to provide implementation for all these methods. Some of the methods may not be applicable to that concrete class. But still it has to provide implementation in absence of interface segregation principle.
Let's have a look at example code in absence of Interface segregation.
interface Shape{
public int getLength();
public int getWidth();
public int getRadius();
public double getArea();
}
class Rectangle implements Shape{
int length;
int width;
public Rectangle(int length, int width){
this.length = length;
this.width = width;
}
public int getLength(){
return length;
}
public int getWidth(){
return width;
}
public int getRadius(){
// Not applicable
return 0;
}
public double getArea(){
return width * length;
}
}
class Square implements Shape{
int length;
public Square(int length){
this.length = length;
}
public int getLength(){
return length;
}
public int getWidth(){
// Not applicable
return 0;
}
public int getRadius(){
// Not applicable
return 0;
}
public double getArea(){
return length * length;
}
}
class Circle implements Shape{
int radius;
public Circle(int radius){
this.radius = radius;
}
public int getLength(){
// Not applicable
return 0;
}
public int getWidth(){
// Not applicable
return 0;
}
public int getRadius(){
return radius;
}
public double getArea(){
return 3.14* radius * radius;
}
}
public class InterfaceNoSeggration{
public static void main(String args[]){
Rectangle r = new Rectangle(10,20);
Square s = new Square(15);
Circle c = new Circle(2);
System.out.println("Rectangle area:"+r.getArea());
System.out.println("Square area:"+s.getArea());
System.out.println("Circle area:"+c.getArea());
}
}
output:
java InterfaceNoSeggration
Rectangle area:200.0
Square area:225.0
Circle area:12.56
Notes:
Shape is a general purpose fat interface, which contains methods required for all Shape implementations like Rectangle, Circle and Square. But only some methods are needed in respective Shape childs
Rectangle : getLength(), getWidth(), getArea()
Square : getLength() and getArea()
Circle : getRadius() and getArea()
In absence of segregation, all Shapes have implemented entire fat interface : Shape.
We can achieve same output with interface segregation principle if we change the code as follows.
interface Length{
public int getLength();
}
interface Width{
public int getWidth();
}
interface Radius{
public int getRadius();
}
interface Area {
public double getArea();
}
class Rectangle implements Length,Width,Area{
int length;
int width;
public Rectangle(int length, int width){
this.length = length;
this.width = width;
}
public int getLength(){
return length;
}
public int getWidth(){
return width;
}
public int getRadius(){
// Not applicable
return 0;
}
public double getArea(){
return width * length;
}
}
class Square implements Length,Area{
int length;
public Square(int length){
this.length = length;
}
public int getLength(){
return length;
}
public int getWidth(){
// Not applicable
return 0;
}
public int getRadius(){
// Not applicable
return 0;
}
public double getArea(){
return length * length;
}
}
class Circle implements Radius,Area{
int radius;
public Circle(int radius){
this.radius = radius;
}
public int getLength(){
// Not applicable
return 0;
}
public int getWidth(){
// Not applicable
return 0;
}
public int getRadius(){
return radius;
}
public double getArea(){
return 3.14* radius * radius;
}
}
public class InterfaceSeggration{
public static void main(String args[]){
Rectangle r = new Rectangle(10,20);
Square s = new Square(15);
Circle c = new Circle(2);
System.out.println("Rectangle area:"+r.getArea());
System.out.println("Square area:"+s.getArea());
System.out.println("Circle area:"+c.getArea());
}
}
Notes:
Now individual Shapes like Rectangle, Square and Circle have implemented only required interfaces and got rid of un-used methods.
Agree with both the answers above. Just to give an example of TrueWill's code smell above, you shouldn't find yourself doing this:
#Override
public void foo() {
//Not used: just needed to implement interface
}
IWorker Interface:
public interface IWorker {
public void work();
public void eat();
}
Developer Class :
public class Developer implements IWorker {
#Override
public void work() {
// TODO Auto-generated method stub
System.out.println("Developer working");
}
#Override
public void eat() {
// TODO Auto-generated method stub
System.out.println("developer eating");
}
}
Robot Class:
public class Robot implements IWorker {
#Override
public void work() {
// TODO Auto-generated method stub
System.out.println("robot is working");
}
#Override
public void eat() {
// TODO Auto-generated method stub
throw new UnsupportedOperationException("cannot eat");
}
}
For a more complete example go here.
Here's a real-world example of this principle (in PHP)
Problem Statement:
I want various forms of content to have comments/discussion associated with them. That content might be anything from a forum topic, to a news article, to a user's profile, to a conversation-style private message.
Architecture
We will want a re-usable DiscussionManager class which attaches a Discussion to a given content entity. However, the above four examples (and many more) are all conceptually different. If we want the DiscussionManager to use them, then all four+ need to have one common interface that they all share. There is no other way for DiscussionManager to use them unless you want to your arguments to go naked (e.g. no type checking).
Solution: Discussable interface with these methods:
attachDiscussion($topic_id)
detachDiscussion()
getDiscussionID()
Then DiscussionManager might look like this:
class DiscussionManager
{
public function addDiscussionToContent(Discussable $Content)
{
$Discussion = $this->DiscussionFactory->make( ...some data...);
$Discussion->save() // Or $this->DiscussionRepository->save($Discussion);
$Content->attachDiscussion($Discussion->getID()); // Maybe saves itself, or you can save through a repository
}
public function deleteDiscussion(Discussable $Content)
{
$id = $Content->getDiscussionID();
$Content->detatchDiscussion();
$this->DiscussionRepository->delete($id);
}
public function closeDiscussion($discussion_id) { ... }
}
This way, DiscussionManager does not care about any of the unrelated behaviors of the various content types that it uses. It ONLY cares about the behaviors it needs, regardless of what those behaviors are associated with. So by giving each content type that you want to have discussions for, a Discussable interface, you are using the interface segregation principle.
This is also a good example of a situation where an abstract base class is not a good idea. A forum topic, user profile, and news article aren't even remotely conceptually the same thing, thus trying to get them to inherit the discussion behaviors leads to strange coupling to an unrelated parent. Using a specific interface that represents discussions, you can makes sure that the entities you want to have discussions, are compatible with the client code that will be managing those discussions.
This example might also be a good candidate for usage of Traits in PHP, for what it's worth.
From what I`ve learned, it is no good if you frequently use downcasting in class hierarchies.
I agree with that, but what are exceptions from this rule if any?
This is where my design of graphical editor shows thin: I have two hierarchies, where geometric figures hierarchy decoupled from graphic primitives one. Like this:
public class GeometricPrimitive {...}
public class RectangeGeometric: Geometric Primitive {...}
public class GraphicPrimitive {...}
public class Rectangle: GraphicPrimitive {
private RectangleGeometric figure;
...
}
So, every concrete graphic figure class encapsulates instance of concrete geometry class. Is that approach is the right one, or should I prefer more generical one? - unfortunately, downcasting would be used in this case:
public class GraphicPrimitive {
protected GeometryPrimitive figure;
....
}
public class Rectangle: GraohicPrimitive {
public Rectangle(Color c, TwoDPoint leftHighPoint, TwoDPoint rightLowPoint):
base(new RectangleGeometric(leftHighPoint.Point2D, rightLowPoint.Point2D), c) { }
#region Geometric Properties
public TwoDPoint LeftTopCorner {
get { return new TwoDPoint(base.color, (base.figure as RectangleGeometric).LeftTopCorner); }
}
public TwoDPoint RightBottomCorner {
get { return new TwoDPoint(base.color, (base.figure as RectangleGeometric).RightBottomCorner); }
}
While your question lacks some of the larger context about your application that would help with giving a specific answer, I'll try by giving you some ideas of how I would implement this using your code for inspiration.
I would start by inverting the relationship GeometryPrimitive and GraphicPrimitive. I see the the GeometryPrimitive hierarchy as the domain objects that make up your abstract scene graph and the GraphicPrimitive hierarchy as low level view components that translate a GeometryPrimitive into a set of pixels appropriate for drawing onto some kind of graphics context. The GeometryPrimitive subclasses hold all the state information necessary to describe themselves but no logic for translating that description into pixels. The GraphicPrimitive subclasses have all the pixel pushing logic, but no internal state. In effect, the GraphicPrimitive hierarchy represents a hierarchy of Command Objects.
In the GeometryPrimitive base class, include an abstract method called GetGraphicPrimitive(). In the GraphicPrimitive base class include an abstract method called Draw(Graphics g).
Within each GeometryPrimitive, include the appropriate GraphicPrimitive for drawing the object and an accessor method for accessing it. To draw the entire scene, walk your structure of GeometryPrimitive objects, asking each one for its GraphicPrimitive and then invoking the Draw() method.
abstract class GeometryPrimitive
{
public abstract GraphicsPrimitive GetGraphicsPrimitive();
}
abstract class GraphicsPrimitive
{
public abstract void Draw(Graphics g);
}
class RectangleGeometryPrimitive : GeometryPrimitive
{
public Point TopLeft {get; set;}
public Point BottomRight {get; set;}
private RectangleGraphicPrimitive gp;
public RectanglePrimitive(Point topLeft, Point bottomRight);
{
this.TopLeft = topLeft;
this.BottomRight = bottomRight;
this.gp = new RectangleGraphicsPrimitive(this);
}
public GraphicsPrimitive GetGraphicsPrimitive()
{
return gp;
}
}
class RectangleGraphicsPrimitive : GraphicsPrimitive
{
private RectangleGeometryPrimitive p;
public RectangleGraphicsPrimitive(RectangleGeometryPrimitive p)
{
this.p = p;
}
public void Draw(Graphics g)
{
g.DrawRectangle(p.TopLeft, p.BottomRight);
}
}
class CircleGeometryPrimitive : GeometryPrimitive
{
public Point Center {get; set;}
public int Radius {get; set;}
private CircleGraphicPrimitive gp;
public RectanglePrimitive(Point center, int radius);
{
this.Center = center;
this.Radius = radius;
this.gp = new CircleGraphicsPrimitive(this);
}
public GraphicsPrimitive GetGraphicsPrimitive()
{
return gp;
}
}
class CircleGraphicsPrimitive : GraphicsPrimitive
{
private CircleGeometryPrimitive p;
public CircleGraphicsPrimitive(CircleGeometryPrimitive p)
{
this.p = p;
}
public void Draw(Graphics g)
{
g.DrawCircle(p.Center, p.Radius);
}
}
As you can see above, no downcasting is required to draw GeometryPrimitives to the screen. With proper use of inheritance, you can also share GraphicsPrimitive objects between different GeometryPrimitives. For example, SquareGeometryPrimitive and RectangleGeometryPrimitive can both use RectangleGraphicsPrimitive if SquareGeometryPrimitive derives from RectangleGeometryPrimitive.
You don't give many details, so I can't really give my opinion about whether it is adequate to have the two hierarchies. We all know the costs of this parallelism, but only you can evaluate the advantages ...
I don't know your programming language. But a common solution to avoid the downcasting you mention, is to have a base class using parameterized types (called generics or templating). This works in Java, C++ and many modern languages.
The idea is that the precise type of the field base.figure is determined by each subclass. What you know in the base class is that it is a subtype T of GeometryPrimitive. In each subclass, you defined the precise type RectangleGeometric that replaces the T, so within this subclass the type is precise.
Java example:
public GraphicPrimitive<T extends GeometryPrimitive> {
protected T figure;
}
public Rectangle extends GraohicPrimitive<RectangleGeometric> {
// It appears in this class that the field was defined as
//protected RectangleGeometric figure;
public TwoDPoint getLeftTopCorner {
return new TwoDPoint(base.color, figure.LeftTopCorner);
}
}