This question already has answers here:
How to implement multiple inheritance in delphi?
(10 answers)
What are the pros and cons of using interfaces in Delphi?
(9 answers)
Closed 2 years ago.
I need to use an external library which has a class hierarchy, TC1 base, TC2 which derives from TC1, TC3A and TC3B which derive from TC2. I need to extend each class of this hierarchy with some attributes and methods, which will obviously need to be inherited from the derived classes. I don't want to change the library code. I can't use class helpers because I also have attributes to add. And Delphi doesn't support multiple inheritance. The use of encapsulation instead of inheritance seems to me not applicable in this case. How can I solve the problem?
Related
This question already has answers here:
Can I extend a class using more than 1 class in PHP?
(18 answers)
Closed 2 years ago.
We know that PHP5 or later allow OOP but not support multiple inheritance like C++
Does PHP7 supported Multiple Inheritance?
From the manual:
A class can inherit the methods and properties of another class by
using the keyword extends in the class declaration. It is not possible
to extend multiple classes; a class can only inherit from one base
class.
I believe traits are a compromise to do things you'd usually do via multiple inheritance.
Traits are a mechanism for code reuse in single inheritance languages
such as PHP. A Trait is intended to reduce some limitations of single
inheritance by enabling a developer to reuse sets of methods freely in
several independent classes living in different class hierarchies. The
semantics of the combination of Traits and classes is defined in a way
which reduces complexity, and avoids the typical problems associated
with multiple inheritance and Mixins.
http://php.net/manual/en/language.oop5.traits.php
Or in a less nicer way, one class can keep extending another class which implements what you want Class B extends A {}, Class C extends B {}, etc
This question already has answers here:
Creating an abstract class in Objective-C
(21 answers)
Closed 7 years ago.
I've realized there's no abstract classes in Objective-C. Is there any way to achieve the same functionality in some other way (a class that can't be instantiated, or methods that MUST be overridden by their subclass)?
It depends exactly what you want. If you would just use the class as an interface with no implementation then using a protocol instead is best. If you need some base or default implementation then you either document that the class shouldn't be instantiate do directly (common nowadays I think) or you implement the class to throw exceptions if it is instantiated directly (uncommon nowadays). Also throw exceptions in any methods that should be implemented by a subclass and are called on the superclass.
Unless you're creating a framework that will be delivered to other developers it's generally not worth the effort to implement, just document.
This question already has answers here:
What exactly is a so called "Class Cluster" in Objective-C?
(5 answers)
Objective C - How can I create an interface?
(4 answers)
Closed 7 years ago.
Problem: Suppose I have a class (call it cA), which has a reference to a helper class (call it HelperBase). The Helper class can be extended for specific implementations (call those HelperA, HelperB, etc.). However, I don't want cA to have any knowledge of the specific implementations either HelperA, HelperB, etc; I just want cA to call whatever methods are in Helper. Is there a way to do that? Is there a term for this? I'm also not sure what the terminology is for this kind of design (if there is one).
Examples in objective-c would be greatly appreciated. Thanks!
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 question already has answers here:
What is the best way to solve an Objective-C namespace collision?
(13 answers)
Closed 8 years ago.
However, I have not met with any issues yet, but sometimes it might happen when we are using two completely independent frameworks, which might have two classes of common name. So, to resolve compiler ambiguity, how to specify that this class refers to this framework and this belongs to that framework. Like in Java, we can specify fully qualified class name like java.pkg.Class.
I know that all the classes are preceded by some characters those might identify the framework (like NS, SK, MK, etc.), but it still can happen. Is there any mechanism that I am missing? I have never heard of fully qualified class name in Objective C.
Objective-C does not have namespaces for its classnames. The class name (e.g. NSString) is the fully-qualified class name; that's as qualified as it gets.
Obviously, this can lead to collisions. Some developers have filed bugs asking for namespaced classes in Objective-C, but as of this writing, nothing has been done in response to those requests.
So no, there is no mechanism that you're missing.