Lets say I am given an object O on some method.
This object O is derived from a base Object BaseClass and as such has a part whose type is BaseClass.
How can I access this part when I am in this method, which means super wont work because I am not in the context of the object.
Thanks!
Let me re-phrase your question to make sure I understand it. You have a class O containing a method (say "test"). In that method, you want to access an instance variable belonging to the superclass BaseClass.
If this is correct, then you can already access that instance variable directly. You just need to provide the name of the variable. Your subclass has access to all of the instance variables visible to the superclass.
You should consider creating get and set methods for the variable and accessing the variable by calling those methods from the subclass, but it's optional.
Let me provide another answer, which could be useful for cases where the question refers to behavior (methods) rather than shape (instance variables.)
Assume you have two classes C and D and an instance c of C. Now assume C inherits from C' and you would like to invoke a method m defined in C' that has been overridden in C. The expression c m will activate the implementation in C rather than the one in C' because c class == C, not C'. As you said, there is no "remote" version of super that you could use from D.
If what you want is to activate the method in C', then you should move the source code of m in C' to another method, say m0, and redefine m in C' so that it just delegates to m0 (^self m0). Keep the method m in C unchanged and then call from D using m0 (c m0) instead of m (c m).
Note that the other way around will not work: if you define m0 in C' as ^self m, the expression c m0 will activate the version of m found in C, not C'.
You could also define m0 in C as ^super m and that way c m0 will activate C'>>m. However, the usage of super with a different selector is not considered a good practice, and you should chose not to do that.
Related
I'm not sure where to ask this this but I don't know how to google this. When class A inherits class B, A is child and B is Parent (or Base). If class C is composed of D(s), i.e. if C has D(s), what are the terms for C and D?
I think you are talking about either "has-a" or "use-a" relationship. for example, in simple,if C has D as class property (like embedded property in C++) then it is called as "C has D",and if C only has pointer of D as property, it is called "C uses D".
Yesterday I was asked a question in an interview:
Suppose class A is a base class, and class B is derived class.
Is it possible to create object of:
class B = new class A?
class A = new class B?
If yes, then what happen?
Objects of type B are guaranteed to also be objects of type A. This type of relationship is called "Is-a," or inheritance, and in OOP it's a standard way of getting polymorphism. For example, if objects of type A have a method foo(), objects of type B must also provide it, but its behavior is allowed to differ.
The reverse is not necessarily true: an object of type A (the base class) won't always be an object of type B (the derived class). Even if it is, this can't be guaranteed at compile-time, so what happens for your first line is that the code will fail to compile.
What the second line does depends on the language, but generally
Using a reference with the base type will restrict you to only accessing only members which the base type is guaranteed to have.
In Java, if member names are "hidden" (A.x exists and so does B.x, but they have different values), when you try to access the member you will get the value which corresponds to the type of the reference rather than the type of the object.
The code in your second example is standard practice when you are more interested in an API than its implementation, and want to make your code as generic as possible. For instance, often in Java one writes things like List<Integer> list = new ArrayList<Integer>(). If you decide to use a linked list implementation later, you will not have to change any code which uses list.
Take a look at this related question: What does Base b2 = new Child(); signify?
Normally, automatic conversions are allowed down the hierarchy, but not up. That is, you can automatically convert a derived class to its base class, but not the reverse. So only your second example is possible. class A = new class B should be ok since the derived class B can be converted to the base class A. But class B = new class A will not work automatically, but may be implemented by supplying an explicit conversion (overloading the constructor).
A is super class and B is a SubClass/Derived Class
the Statement
class A = new class B is always possible and it is called Upcasting because you are going Up in terms of more specific to more General
Example:
Fruit class is a Base Class and Apple Class is Derived
we can that Apple is more specific and must possess all the quality of an Fruit
so you can always do UPcasting where as
DownCasting is not always possible because Apple a=new Fruit();
A fruit can be a Apple or may it is not
I have an operation that I need to design. That operation takes two objects of a certain class X, and returns two new objects of the same class (I may need the originals later). The logic that dictates the selection of this object is contained in class Y. On one hand, I don't want class Y to know details about class X implementation; on the other, I don't want class X to know details about selecting the different objects to perform this operation on.
If that was all the problem, I'd just create a static method on class A. However, the methods in language I'm working on return only one object. Also, the operation needs to be robust, and calling operation two times to get C and D respectively isn't possible, as both C & D both rely on a single random number.
How should I design such operation?
Update: I'm using Obejctive C.
I decided to just modify given objects A & B with a static method. I'll have to make copies of them before calling this method, but I think it'll be not slower than creating new ones; most of the information in objects C & D is derived from A & B anyway.
(I still think it's an ugly solution, and will welcome a more qualified answer).
I got a list of Objects of class-type B (B inherits from A).
How can I downcast all the B-objects to A-objects without using a function to pull the needed information and create a new instance?
(defclass A () ( (varI :initarg :varI :accessor varI) ) )
(defclass B (A) ( (varII :initarg :varII :accessor varII) ) )
(defun generate-list-of-type-B-objects () (....does...some..stuff....))
(defvar *listoftypeA* (generate-list-of-type-B-objects) )
(I know this example is easy to rewrite, as I could make the method generate a list of type A objects, but the function is used somewhere else where type-B objects are needed, and I do not want to duplicate code)
If you absolutely must convert your instances of class B into instances of class A, you can do a one-way conversion of them with the use of CHANGE-CLASS. This is a non-reversible change of each instance.
Since I am not 100% sure what you actually want, the best suggestion I can give is "have you tried leaving them as class B and see if it works?"
Chances are that it will just work, unless you have methods of a generic function somewhere that treat instances of class B differently than instances of class A. If it's only about dropping the space that the extra slot would take, have you measured that it's actually worth it (it probably isn't, unless you have several thousands of instances of class B, where you could get by with instances of class A).
I have a class that has several properties. Some properties can be changed by other classes but some properties are dependent on other properties. For example assume that my class has three properties: A, B and C. A and B can be changed by other classes in system and C is equal to A + B. The class generate property change notification So I want when A or B changed, a notification generate for both the changed property (A or B) and a notification is generated for C too.
I have three options (any other?)
1- Create a normal C property (with backing field) and add code in setter of A and B to change C.
2- Create a normal C property and listen to property change notification of my class inside of my class and change C when A or B changes.
3- Create a calculating property for C no setter but getter is A+B, in setter of A (and B), I fire property change for both A (or B) and C.
Which one is a better design pattern (in C#)? I personally like design number 2.
Sounds like an Observer pattern might be useful here. See for example http://www.oodesign.com/observer-pattern.html. Although a search for Observer pattern will yield many results and other examples, some much simpler, and language specific.
I would probably go with a variation on 2 and 3.
You could have a calculated property (getter only) for C so that the C = A + B calculation is only in one place.
Then, as per your option 2, you could listen to property changed events within the same class... but instead of updating C when you detect a PropertyChanged event for A and B, you only need to raise a PropertyChanged event for C at that time.
2 is the purest since it keeps A,B and C separate, but it does involve a bit of overhead qith the string parsing in the property notification.
If it was a simple set of properties I'd be tempted with 1, since they are still reasonably separate but the update is much simpler. 3 is the worst IMO, since A+B are replicating code which should be separate anyway (C notifications).
The problem here is that you are trying to mix the way that things should be done with the way Microsoft forces you to do things... :)
But my rantings aside it think that option 3 sounds cleanest. Certainly not 1, that is the worst by far, and I think that subscribing to your own property change events could lead to some funky problems that would be hard to debug when some poor sap tries to maintain the code in the future...
If you think about it at a high level, what you are suggesting in 3 perfectly describes what is happening in the class:
Any time that property A is changed observers of the class should be notified that property C has also changed (because it has).