Matlab defines LinearModel and GeneralizedLinearMixedModel classes. Browsing the documentation indicates that either (i) one is derived from the other, or (ii) there is automatic conversion. These are complex objects, and I am just starting to explore them, so I apologize if their relationship is obvious, but what exactly is their relationship?
Note also that I expressed (i) and (ii) above in terms of my object-oriented background (C++), and I know there maybe be differences with the Matlab paradigm.
This question arose because the function coefTest accepts a GeneralizedLinearMixedModel object, yet the Econometrics toolbox example "Time Series Regression IX: Lag Order Selection" submits a LinearModel object instead.
Note that this this question pertains to Matlab-specific classes and the Matlab command coefTest. As such, it does not belong on "Cross Validated" Stack Exchange forum. I posted this to:
Relationship between LinearModel & GeneralizedLinearMixedModel classes
http://groups.google.com/forum/#!topic/comp.soft-sys.matlab/OHLajBEuPU0
To determine this, you can use the superclasses function:
superclasses('LinearModel')
superclasses('GeneralizedLinearMixedModel')
This will return the names of the visible superclasses for each case. As you'll see, both inherit from the abstract superclass classreg.regr.ParametricRegression.
You can also view the actual classdef files and look at the inheritances. In your Command Window, type edit LinearModel and edit GeneralizedLinearMixedModel. You will see, respectively:
classdef (Sealed = true) LinearModel < classreg.regr.TermsRegression
and
classdef (Sealed = true) GeneralizedLinearMixedModel < classreg.regr.LinearLikeMixedModel
And so on. Both LinearModel and GeneralizedLinearMixedModel are Sealed, meaning they are not allowed to be subclassed.
Why does coefTest "accept" objects both LinearModel and GeneralizedLinearMixedModel class objects?
Both LinearModel and GeneralizedLinearMixedModel have methods called coefTest: LinearModel/coefTest and GeneralizedLinearMixedModel/coefTest. Despite the name, these are entirely separate functions. Which method gets called is determined by the class of the object you pass to it. The methods of each of these classes are listed in their respective documentation, however, you can also use the methods function on an object of either class to list its public methods.
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.
I'm working on rewriting an old MATLAB package. As part of that rewrite I'm updating two classes (lets call them old_class1 and old_class2) defined using the class() function to classes defined with classdef.
The definition of old_class1 contains the line superiorto('old_class2'). This function is not allowed in a constructor defined with classdef, but I am unable to find any equivalent. How do I create functionality equivalent to superiorto() in a class defined with classdef?
superiorto is no longer available in MATLAB, but I was able to find a copy of old documentation that indicates it was used to determine which object's method was called when multiple different classes were given as function arguments. For example, given obj1=class1() and obj2=class2(), with the class1 constructor containing superiorto('class2'), would cause function(obj1,obj2) to callclass1.function, rather thanclass2.function`.
With modern classdef functionality, the same can be accomplished by setting the InferiorClasses property:
classdef (InferiorClasses = {?class2}) class1
This is my naive thought process. I appreciate when anyone points out any discrepancies.
I know that in Java it is possible to create private nested classes. But in PHP (calling itself an "OOL") no such thing is easily possible.
However, there may be an instance where I need to use a helper class within only one other class.
This naturally led me to consider using composition about which I think its supposed to actually solve this kind of a problem, for the following reason:
Wikipedia:
It is only called composite, if the objects it refers to
are really its parts, i.e. have no independent existence.
Aggregation differs from ordinary composition in that it does not imply ownership.
In composition, when the owning object is destroyed, so are the
contained objects. In aggregation, this is not necessarily true.
So since in composition the components aren't supposed to exist without the other composite object, I assume there is basically only one way of accomplishing this by using private nested classes, otherwise I will need to have the Component class visible, making it instantiable also somewhere else, violating the creation/destruction-of-components-within-the-composite-class rule.
Now I came across PHP where it is not possible at all to create nested classes (or maybe with some magic) which may lead to a question why do we need nested classes at all?
Compelling reasons for using nested classes include the following:
It is a way of logically grouping classes that are only used in one
place: If a class is useful to only one other class, then it is
logical to embed it in that class and keep the two together. Nesting
such "helper classes" makes their package more streamlined.
It increases encapsulation: Consider two top-level classes, A and B,
where B needs access to members of A that would otherwise be declared
private. By hiding class B within class A, A's members can be declared
private and B can access them. In addition, B itself can be hidden
from the outside world.
It can lead to more readable and maintainable code: Nesting small
classes within top-level classes places the code closer to where it is
used.
So in my opinion, as nested classes increase encapsulation (and thus allowing for implementation of a composite concept) it should be always possible to create a nested class in a proper OOL.
I also looked up the definition of an OOP and it only mentions the support for Encapsulation, Abstraction, Inheritance, Polymorphism concepts.
OOP
Encapsulation means that the internal representation of an object is generally hidden from view outside of the object’s
definition.
Abstraction is the development of classes, objects, types in terms of their interfaces and functionality, instead of their implementation details. (e.g. instead or creating a single sequence of commands to work with a radius and points we would abstract a concept of a circle. So we define a class Circle and a its attributes/functions in such a way that it reflects this abstract concept.)
Inheritance is supposed to be the is-a relationship between abstractions (allowing for code reuse).
Polymorphism allows for overriding and overloading methods.
A guy asked a question here which actually complies exactly with my understanding of the problem and IMHO received quite inaccurate answer, being told to be really confused and being provided with a code sample which IMO is not a proper composition, as it is not really possible in PHP. In addition someone may argue that composition isn't about inner classes.
So am I understanding something really wrong?
Those concepts like composition are generic and their implementation may vary depending on the programming language.
In the other hand, I wouldn't say that the definition of composition which includes [...] have no independent existence refers to being able to create instances or not from different scopes.
No independent existence is a more conceptual than practical rule. It means that a wheel can never be the composition root because the root is the car. That is, a wheel can't exist independently of a car.
Therefore, the conclusion is nested classes are just an implementation detail and they have nothing to do with composition. Note that objects aren't created from classes in all programming languages but composition and many other features are still possible. Would you say that object composition isn't possible in JavaScript?
var car = { manufacturer: "Ford", model: "Focus" };
// I can create the wheel after the car
var wheel = { color: "black" };
// but it'll be always tied to some car
car.wheel = wheel;
Anyway, practically all systems implement aggregation, which is a flavor of composition. Take a look at this Q&A at Software Engineering.
While a wheel is useless without being part of a car, wheels are still sold apart as one of the many mechanical pieces of which a car is built, hence a wheel can live alone yet it's useless as just a piece.
Generic definition of composition in OOP
The OP is too concerned and focused on the formal definition of composition in terms of UML: composition, association, direct association, aggregation...
BTW, the term composition in OOP has a more simple meaning which is often used, for example, when discussing when to use inheritance or when to avoid it, we talk about composition over inheritance. See for example this Q&A from 2010: What is composition as it relates to object oriented design? on which basically all answerers have a consensus about the definition of composition.
At the end of the day, the term composition is the approach to create an object graph: simple types are associated together to create more complex types.
Thus, as I've already explained in the first part of this answer, nested classes are just a programming language implementation detail and they're not crucial to implement any flavor of composition.
OP said on some comment:
But conceptually in order to implement it properly as a composition,
I'd prefer something like partial classes (as in C#) allowing me to
separate code into multiple files but restricting the instantiability
to the main class only. I know you don't agree with me, I have to
express my view somehow.
This is a wrong example because partial classes are just a syntactic sugar to glue multiple files defining the same class and later everything is the same class.
C# has nested classes:
public class A
{
public class B
{
}
}
But you need to understand that type definitions have nothing to do with objects from a conceptual point of view because an object-oriented language may or may not have a type system and classes, but yet it can support composition and all its flavors.
In wikipedia, there's also the following example of composition without using private nested classes.
class University
{
std::vector<Department> faculty; //this is composition
std::vector<People*> people; //this is aggregation
University() // constructor
{
// Composition: Departments exist as long as the University exists
faculty.push_back(Department("chemistry"));
faculty.push_back(Department("physics"));
faculty.push_back(Department("arts"));
}
};
For a true composition we don't have to make the whole class private as long as we treat instances of departments appropriately, i.e. we need to make sure that all departments will actually get deleted when the university ceases to exist.
An analogous ways of implementing different compositions in JavaScript would be as follows:
/*this is a component's "class"*/
function Text(txt){
this.txt = txt;
}
/*this is a composite's "class"*/
function Hello(begining){
/*public object*/
this.begining = begining;
/*this is like making an instance from a nested function which is a composite*/
var Middle = new (function Middle(txt){
this.txt = txt;
})(" - ");
/*private object - also a composite, even though it's made of the public class Text*/
var Ending = new Text("that's all.");
/*The use of the private property Ending*/
this.Say = function(){
var msg = this.begining.txt + Middle.txt + Ending.txt;
console.log(msg);
}
}
/*
This txt variable will be the "begining" text. It could still be a composite, but
only if it's not used in another composite when purpose is to be
"an untransferable part" and not a "visitor".
*/
var txt = new Text("Dan");
var say1 = new Hello(txt);
var say2 = new Hello(new Text("To be or not to be"));
say1.Say() /*Dan - that's all.*/
say2.Say() /*To be or not to be - that's all.*/
But even the transferability is often a neglected rule when people see "cars" having "wheels" as parts (rather then "visitors")
Instead of perhaps "neural network" and "neurons" or "forest" and "trees". Trees don't get replanted to a different forest so often.
And since the wheels can still be understood as parts of a composite, it doesn't have to differ from aggregation in code.
I am trying to understand what design pattern I am stumbling towards... please bear with me the language I am using is Matlab and the OO is a bit weak in some areas, and I am relatively inexperienced in implementing design patterns.
I have a ComplexObject in which the constructor was becoming overly complicated. To begin with my constructor allowed 0, 1 or 2 arguments, that is an "empty" ComplexObject, a ComplexObject built from a ModelObject, or a ComplexObject built from ModelObject+ConfigObject. (The ModelObject and ConfigObject are basic file parsers).
I can't overload constructors in Matlab, so I essentially switch'ed on the class type of the input arguments to the constructor, after I while I changed some of this to static methods so that the constructor was just an empty class initializer, and static ComplexObject.createFromModel and ComplexObject.createFromModelAndConfig classes produced ComplexObjects.
I then decided that my ComplexObject code was being dominated by all this construction stuff and the business logic wasnt clear, so I wrote a ComplexObjectFactory class and basically moved the static methods into that class. Now since the static methods are in fact calling more private (static!?) methods to build the ComplexObject I have run into some confusion about calling conventions of these private static methods :(
Finally, I am now trying to add some code to write part of ComplexObject back to disk. Interestingly this is actually the same disk file that is used to build a ConfigObject... so I want something like ComplexObject.writeConfigFile... or should that be ComplexObjectFactory.writeConfigFile(myComplexObject). To further complicate things I want multiple types of "config" file formats down the track.
My current classes look something like:
classdef ComplexObjectFactory
methods (Static)
function product = createFromModel(modelObj)
product = ComplexObject()
ComplexObjectFactory.helper1(product)
end
function product = createFromModelAndConfig(modelObj, configObj)
product = ComplexObjectFactory.createFromModel(modelObj)
ComplexObjectFactory.helper2(product, configObj)
end
end
methods (Private, Static)
function helper1(product)
function helper2(product)
end
end
classdef ComplexObject
methods
function self = ComplexObject(varargin)
<init>
end
end
end
classdef ComplexObject
Not sure I completely understand your question, tell me if I'm off topic here.
Just like you wrote, design pattern that creates objects is called factory. Other functionality that you mentioned, like writing to disk should be the responsibility of the object itself.
I have had trouble finding help in the matlab documentation and previous questions about using matlab inheritance and class constructors to make an interface. To make it tidy, within a package.
Instead of dragging through my code I can condense it as follows:
A package +MyPkg has a superclass Super and a few subclasses Sub1 Sub2... Most of my properties and methods are defined in Super such that Sub1 and Sub2 really only exist to use their constructors for simple routines or perhaps a few methods overloaded from Super.
So how do I go about writing the classdefs and constructors to support an interface where I can use the following calls:
a = MyPkg.Super(args).Sub1(args)
b = MyPkg.Super(args).Sub1(args).Sub1Method
In this case I want to keep arguments related to Super apart from arguments related to Sub1 for readability and organization.
Questions are welcome.
EDIT:
After considering the accepted answer below and some browsing I reached the conclusion that the interface shown above is not really in the spirit of OO and, for my data analysis application of it a more proper way to approach it would consist of a handle class with a constructor that populates an object or cell array of object properties. Because the class is a handle class one can then use the methods on it to produce desired methods. i.e. the following
% in +MyPkg\
classdef Super < handle
properties
outputArray
end
methods
function self = Super(args)
self.outputArray=load_values(args);
end
function out = do_analysis(self,params)
% do some analysis
end
end
end
Then to use this:
data1 = MyPkg.Super(args)
% Populate the outputArray
analysis1 = data1.do_analysis(params)
etc.,
Hope that helps someone else dealing with these issues
With respect to your question, you can't if you use inheritance. Only direct superclass constructors can be called from subclasses and only from the subclass can you call the superclass constructor. Ref.
Exposing the superclass like that really breaks the fundamentals of inheritance. Maybe ou should be thinking of another model, maybe composition ("has a" instead of "is a"), if you need that kind of access?