My superclass have 8 subclasses such that variables in first 4 subclasses are of a kind and remaining 4 subclasses are of another kind. Should it be right practice to declare all variables in my superclass with getter and setter method, and then access from respective subclasses? What will be advantage and disadvantage of this?
Hard to say since we don't see what the exact situation is.
For the way you describe it it would probably be best to make this 3-level subclassing
superclass
(empty)
|
--------------+--------------
| |
subclass_typeA subclass_typeB
(4 type A properties) (4 type B properties)
Then each of these sublclass_typeX has it's own 4 subclasses
PROS: readability, easier later modifications
CONS: more work for you in the beginning
EDIT: it would most definetly be the right practice to declare all properties in superclass. In that case you could use just one class with added enumerated property called classType but that has nothing to do with OOP anymore.
Related
I have a class "Vertex" with 4 attributes and a class "Vertex_" with one attribute. The one attribute in Vertex_ is also in Vertex. Is it a good design to keep the two classes or is it better to program just the class Vertex, although there will be 3 variables, which are not used, when I instantiate an object which needs just the one attribute?
Class Vertex_ is actually somewhat a duplicate of Class Vertex.
I would suggest using inheritance and having Class Vertex inherit the attribute from the parent Class Vertex_ while having the 3 other attributes Class Vertex_ does not have.
TL;DR
This is a question that deserves a very long answer.There are two reasons for inheritance and the reason for doing it can depend on the language being used. One reason is for code reuse. Without knowing anything else about your situation, it would seem you are inheriting simply to reuse an attribute (but I suspect there could be more you will be reusing). But, there are other ways of getting code reuse without inheritance, for example containment, which is often a better way.
A powerful feature of object-oriented programming is the ability to substitute one type of object for another. When a message is sent to that object, the correct method implementation is invoked according the actual type of object receiving the message. This is one type of polymorphism. But in some languages the ability to substitute one object for another is constrained. In Java I can only substitute an instance of class B for an instance of class A if B is a descendant of A. So inheritance becomes important in Java to support polymorphism.
But what does it mean to be able to substitute a B instance for an A instance? Will it work? Class A has established a contract stating what each of its methods requires before you can successfully call it and at the same time states what each method promises to deliver. Will the methods of class B live up to that contract? If not, you really cannot substitute a B for an A and expect the program to run correctly. B may be a subclass of A but it is not a subtype of A (see Liskov substitution principle]).
In a language such as Python, inheritance is not required for polymorphism and coders are more apt to use it as code-reuse mechanism. Nevertheless, some people feel that subclassing should only be used to express subtyping. So, if Vertex_ is only using one of the four attributes it has inherited, I am doubtful that an instance of Vertex_ could be safely substituted for an instance of Vertex. I would not do the inheritance unless the language were C++ and then I would use private inheritance.
Not sure if I worded this question correctly, but here's my issue: I have a base class and a subclass, and my base class should never be instantiated on its own (in other languages it would be abstract). I know abstract classes aren't a thing in Swift. I have some computed read-only properties that change what they return in each subclass; they are more or less customized constants. Firstly, are overridden computed properties the best way to handle this kind of thing? Secondly, if these variables need to get initialized, i.e. can't be nil, what should they be initialized to in the parent class? Is there a way to otherwise indicate that the parent class shouldn't be initialized on its own?
You probably should use protocol instead of base class in your case. All common implementation can be done in protocol extensions and you won't need to provide default values for constants - just specify required get methods in the protocol.
Racket's documentation only partially describe what augment and pubment do: augment makes a method that executes after the superclass's version of that method, while pubment makes a method that will implicitly have the augment property if it is defined in a child class.
The docs say absolutely nothing about overment and augride, and I can't guess what they would do based on their names. What are they, and what is the difference between them?
The relatively large family of inheritance functions for Racket's class system is, as you describe, a little confusing, and their somewhat cutesy names don't always help.
In order to understand this, Racket provides two separate mechanisms for method inheritance.
public methods correspond to the classical idea of public methods in other OO models. Methods declared with public may be overridden in subclasses, unless they're declared final, in which case they cannot.
pubment methods are similar, but they cannot be overridden, only augmented. Augmenting a method is similar to overriding it, but the dispatch calls the superclass's implementation instead of the subclass's.
To clarify the difference between overriding and augmentation, when an overridden method is called, the overriding implementation is executed, which may optionally call the superclass's implementation via inherit/super. In contrast, in an augmented method, the superclass's implementation receives control, and it may optionally call the subclass's implementation via inner.
Now, we're also provided public-final, override-final, and augment-final. These are pretty simple. Declaring a method with public-final means it can neither be augmented nor overridden. Using override-final overrides a superclass's public method, but it doesn't allow any further overriding. Finally, augment-final is similar, but for methods declared with pubment, not public.
So then, what about the two weird hybrids, overment and augride?
overment can be used to implement methods initially defined with public. This "converts" them to augmentable methods instead of overridable methods for all the class's subclasses.
augride goes in the opposite direction. It converts an augmentable method to one that is overridable, but the overriding implementations only replace the augmentation, not the original implementation.
To summarize:
public, pubment, and public-final all declare methods that do not exist in a superclass.
Then we have a family of forms for extending superclass methods:
override and augment extend methods declared with public and pubment, respectively, using the relevant behaviors.
override-final and augment-final do the same as their non-final counterparts, but prevent further overriding or augmentation.
overment and augride convert overridable methods to augmentable ones and vice-versa.
For another, fuller explanation, you might be interested in taking a look at the paper from which Racket's model was derived, which is quite readable and includes some helpful diagrams.
In my case, UIViewController B is a subclass of UIViewController A. B can surely access all the methods and variables from A, since B is subclassing from A (i.e. A is the parent of B).
However, A needs a variable from B. Is there possible to do that ?
Thanks.
Actually, if you need this type of relations - your design is wrong. I mean - you do not need inheritance relationship in you case, but something like aggregation or composition. For example your type of relations breaks The Liskov Substitution Principle.
BUT. Objective C accepts reverse relationships. You can use delegates (#protocol) to describe interfaces which can retrieve some data from unknown objects who accepts this #protocol.
So, in your case class B should conform a protocol which provide access to some properties of B. And A should be able to work with this protocol, i.e. to know getters which A needs.
Add that variable as a default in subclass A. Then it's also available in subclass B?
If that's something you don't want, then I suppose there is something wrong with your design?
If the instance variable declared in the subclass has a getter method, any method in the superclass could always ask an object of its class if it respondsToSelector: for that getter method, and if so, call it to get the value of the instance variable.
If a method is defined in both a class and a category on that class, it is undefined which implementation will be called.
But how does this interact with inheritance? Specifically:
Given a superclass category method and a regular method in the subclass, is it guaranteed that the subclass implementation will win when called on a member of the subclass?
Given a superclass regular method and a subclass category method trying to override it, is it guaranteed that the subclass category implementation will win when called on a member of the subclass?
Given a superclass category method and a subclass category method, is it guaranteed that the subclass category method will win when called on a member of the subclass?
Lets just put it this way. Don't override methods using categories, period, ever, end of answer.
If a method is defined in both a class and a category on that class,
it is undefined which implementation will be called.
That is incorrect; the category method will always win. What won't work, though, is if you have multiple categories that implement the same method, then the "which one wins" is undefined.
It is generally "last loaded wins", but that really isn't a hard rule, either.
Note that since many classes will internally have their implementation dividing across categories for code organization purposes, you can't rely on the first rule anyway.
In short, what Joshua said; Do not override methods using categories.
Beyond the inheritance reasons, you are also viciously breaking encapsulation when you do so. It isn't that a category based implementation overrides an existing method, it entirely replaces it. Thus, if you don't reproduce every last internal implementation detail, including bugs, your replacement won't quite work right and debugging it will be hard.
From what I test
Given a superclass category method and a regular method in the
subclass, is it guaranteed that the subclass implementation will win
when called on a member of the subclass? => subclass wins
Given a superclass regular method and a subclass category method
trying to override it, is it guaranteed that the subclass category
implementation will win when called on a member of the subclass? =>
subclass category wins
Given a superclass category method and a subclass category method,
is it guaranteed that the subclass category method will win when
called on a member of the subclass? => subclass category wins
Take a look at the Test category and subclass