Can an abstract class inherits from an interface class ?I want to design and implement a class diagram for public transportation system.So i have designed something like this.
1)Limo extends (Abstract)Taxi extends (Interface)Vehicle & (Abstract)public transportation
2)Subway extends (Abstract)public transportation
3)mid-buss extends (Abstract)Buss extends (Abstract)public
transportation & (Interface)Vehicle
4)large-buss extends (Abstract)Buss extends (Abstract)public
transportation & (Interface)Vehicle
So if i want to implement these classes i have to implement the structure of interface's method in the abstract class.what do you think? is it correct to design something like above ?
Can an abstract class inherits from an interface class ?
Yes for Java. The following examples use Java syntax.
Limo extends (Abstract)Taxi extends (Interface)Vehicle & (Abstract)public transportation
public class Limo extends AbstractTaxi{...}
public abstract class AbstractTaxi extends AbstractPublicTransportation implements Vehicle{...}
public interface Vehicle{...}
public abstract class AbstractPublicTransportation{...}
Subway extends (Abstract)public transportation
public class Subway extends AbstractPublicTransportation{...}
mid-buss extends (Abstract)Buss extends (Abstract)public transportation & (Interface)Vehicle
public class MidBuss extends AbstractBuss{...}
public abstract class AbstractBuss extends AbstractPublicTransportation implements Vehicle {...}
large-buss extends (Abstract)Buss extends (Abstract)public transportation & (Interface)Vehicle
public class LargeBuss extends AbstractBuss{...}
Note, that the AbstractTaxi doesn't seem useful yet, because there is only one subclass for that abstract class. However, it's not wrong to introduce additional abstractions to become extensible .
Related
I have a problem to chose the between an abstract class without abstract methods OR a base class with an interface.
I have two implementation in my mind:
1.
Let's say I have a AbstractRenderer:
abstract class AbstractRenderer
{
protected $shape;
public function __construct(AbstractShape $shape)
{
$this->shape = $shape;
}
public function render(): string
{
return $this->shape->generate()->asArray();
}
}
and the WebRenderer would be like this:
class WebRenderer extends AbstractRenderer
{
}
2.
Have a base class and an interface like this:
Interface InterfaceRenderer
{
public function __construct(AbstractShape $shape);
public function render(): string;
}
and a base class that impediments the interface:
class BaseRenderer implements InterfaceRenderer
{
protected $shape;
public function __construct(AbstractShape $shape)
{
$this->shape = $shape;
}
public function render(): string
{
return $this->shape->generate()->toString();
}
}
again, my WebRenderer would be like this:
class WebRenderer extends BaseRenderer
{
}
I don't know which is the correct implementation, or there is a better way to implement this and what is the pros and cons of each.
Thanks
From the Renderer client’s perspective the 2 solutions are basically identical. As long as they depend on an abstract object (interface or an abstract class), you’ll have benefits of polymorphism. You’d lose those if you make them depend on WebRenderer (concrete object).
Interface’s benefits over abstract classes
doesn’t occupy inheritance
no fragile base class problem
Abstract classes provide
static methods (in many languages interface can’t have these)
protected implementation
I have two questions:
I have a Singleton class with a property Layout that I use in creating child objects of an abstract class (example below). The abstract class has an abstract method where the layout file is given as a variable. Do I connect that Singleton class to the abstract class or each child? The following example is written using pseudo-code:
public class SingletonClass
{
public static Instance;
public var[,] Layout;
}
public abstract class AbstractClass
{
public abstract void DoSomething(var[,] Layout);
}
public class ClassA : AbstractClass
{
public override void DoSomething(var[,] Layout) { some code }
}
public class ClassB : AbstractClass
{
public override void DoSomething(var[,] Layout) { some other code }
}
Is it even needed, or "cleaner", to give the Layout as variable in the method, or is it ok to just call Layout from the singleton class?
The following UML is an equivalent of your code
under the following assumptions: Instance and Layout are assumed to be attributes of analogous classes.
SingletonClass has two owned attributes (denoted by the big dots): public layout of type Layout and instance of type AbstractClass (it's abstract, hence the italics). The latter will later hold either an instance of the concrete ClassA or ClassB.
Whether or not the design is ok depends. Basically there's nothing wrong with this.
My code is rather convoluted out of necessity. I have attempted to simplify the overall layout of the object system I'm working on in order to (hopefully) make it more understandable.
abstract class BaseType {}
abstract class MixinTypeA implements BaseType {}
abstract class MixinTypeB<T extends MixinTypeA> implements BaseType {
Future<T> mixinMethod({bool argA = true,
bool argB = true,
bool argC = true}) =>
someMethodCall()
}
abstract class BaseTypeA extends BaseType implements MixinTypeA {
// declares a constructor
BaseTypeA();
}
abstract class BaseTypeB extends BaseType implements MixinTypeB {
// declares a constructor
BaseTypeB();
}
abstract class TypeA extends BaseTypeA {}
class TypeB extends BaseTypeB with MixinTypeB<TypeA> {}
In this case, TypeB will generate an error. This is because it attempts to mixin MixinTypeB<TypeA>. Because TypeB already extends BaseTypeB which implements MixinTypeB with the inferred <MixinTypeA> generic, the MixinTypeB interface is implemented twice with two different (although related by inheritance) interfaces: TypeA and MixinTypeA.
Essentially, the T generic exists to keep my code DRY. The method example in MixinTypeB is one of the various potential methods that the class could have with a specific type signature of T. I don't know how to get around the new restriction without compromising the inheritance structure of this type system.
Generally speaking, the most common solution to this is to thread the generics through the hierarchy to make the types line up. For this specific example, the following code works.
abstract class BaseType {}
abstract class MixinTypeA implements BaseType {}
abstract class MixinTypeB<T extends MixinTypeA> implements BaseType {
Future<T> mixinMethod({bool argA = true,
bool argB = true,
bool argC = true}) => null;
}
abstract class BaseTypeA extends BaseType implements MixinTypeA {
// declares a constructor
BaseTypeA();
}
abstract class BaseTypeB<T extends MixinTypeA> extends BaseType implements MixinTypeB<T>{
// declares a constructor
BaseTypeB();
}
abstract class TypeA extends BaseTypeA {}
class TypeB extends BaseTypeB<TypeA> with MixinTypeB<TypeA> {}
If you don't need to be able to mix together BaseTypeB with any other instantiations of MixinTypeB, then the following simpler approach can work as well:
abstract class BaseType {}
abstract class MixinTypeA implements BaseType {}
abstract class MixinTypeB<T extends MixinTypeA> implements BaseType {
Future<T> mixinMethod({bool argA = true,
bool argB = true,
bool argC = true}) => null;
}
abstract class BaseTypeA extends BaseType implements MixinTypeA {
// declares a constructor
BaseTypeA();
}
abstract class BaseTypeB extends BaseType implements MixinTypeB<TypeA>{
// declares a constructor
BaseTypeB();
}
abstract class TypeA extends BaseTypeA {}
class TypeB extends BaseTypeB with MixinTypeB<TypeA> {}
How can i keep class that extends FragmentActivty ?
I used -keep public class * extends android.support.v4.app.FragmentActivity
after that the class exists but when i start the application it doesn't work and i have an error that he can't find the class
suppose we have a class structure where the code is divided in two parts lets us say computer science and business, now this also further divides in terms of country also, say Indian (cs or MBA) and US (cs or MBA).
now let us consider a scenario where i created classes like
1)Education class(parent class)
2) MBA class extends Education class
3) BS (cs) class extends Education class
now in terms of country also i made the classes
4) INDIA_BS class extends BS (cs) class
5)INDIA_MBA class extends MBA class
6) US_BS class extends BS (cs) class
7) US_MBA class extends MBA class
now let us say i write code where the country is set in the classes-method which are lowest in hierarchy (i.e country classes INDIA_BS,INDIA_MBA,US_BS,US_MBA)
but the logic is similar.I pass country name and it is set.
so my questions are
1) is it wise to put the common logic in parent classes(if i do that way) and calling that method from the child class which is lowest in hierarchy).
2) if this is wrong than what are the principles of OOPS that it violate
3) does it violate SOLID principle also if yes then how ?
4) is it decreasing coherence of the child class if i am putting the common code in parent class.
please be elaborate as possible.
thanks
Your class diagram:
i see x violations:
Favor Composition Over Inheritance
Program To An Interface, Not An Implementation
Software Entities Should Be Open For Extension, Yet Closed For Modification
etc
So, i would suggest you use Abstract Factory pattern.
Code:
class Test
{
static void Main(string[] args)
{
IEducationFactory india = new IndianEducation();
IEducationFactory newYork = new USEducation();
IDiplom d1 = india.Create_BSC();
IDiplom d2 = newYork.Create_MBA();
}
}
public interface IDiplom
{
}
public interface IEducationFactory
{
IDiplom Create_MBA();
IDiplom Create_BSC();
}
public class IndianEducation : IEducationFactory
{
public IDiplom Create_MBA()
{
throw new NotImplementedException();
}
public IDiplom Create_BSC()
{
throw new NotImplementedException();
}
}
public class USEducation : IEducationFactory
{
public IDiplom Create_MBA()
{
throw new NotImplementedException();
}
public IDiplom Create_BSC()
{
throw new NotImplementedException();
}
}
And, your class diagram looks like: