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.
Related
I already know that you create an Interface within VB6.
Classes that implement an interface must implement ALL routines.
Is there a way to create something like an abstract class that may implement some routines.
Derived class must implement the abstract routines and may override the routines already implemented by the abstract class.
Please notice that we're talking about VB6 and not VB.NET or whatsoever.
Thank you
One work-around I use is to have an instance of the base class as a private member:
Implements Shape
Dim base as Shape
Dim radius as Single
Public Function Shape_Area() as Single
Shape_Area = pi*pi*radius
End Sub
Public Function Shape_PenColour() as Long
Shape_PenColour = base.PenColour() ' let the base do its thing
End Function
You could work up a hierarchy like that (for Square):
Implements Shape
Dim base as Rectangle
Public Function Shape_Area() as Single
Shape_Area = base.Area() ' which is Rectangle.Shape_Area which then calls the Shape.Area
End Sub
It does means that each class has to really know about the one it derives from. That may or may not be an issue for you. I have used it and it works well.
It does mean you have to do more work and each class explicitly
Visual Basic 6 does not support implementation inheritance, only interface inheritance. You can read more about it Here. There's a nice article here about interfaces and inheritance in VB6 that may lead you to a solution to your problem within VB6 capabilities.
A work-around (not a solution):
An interface, for instance, specifies routine A and B, implementing the second one.
A derived class has a private member being an instance of the interface.
The implementation of the routine B simply invokes that method on its private member.
Of course, we're dealing with 2 different objects but in some cases this may be good enough.
Implementation inheritance is over-rated and almost always ends up with complicated designs.
What you want to do achieve (provide base impl, reduce repeating code in derived classes, etc) can be done with composition and events
Consider interface IBase
Public Function GetArea() As Double
End Function
interface IDerived
Property Get Base() As IBase
End Property
Common implementation StdBaseImpl of IBase
Implements IBase
Event CustomizeArea(Value As Double)
Public Function GetArea() As Double
GetArea = 42
RaiseEvent CustomizeArea(GetArea)
End Function
Private Function IBase_GetArea() As Double
IBase_GetArea = GetArea
End Function
Then for derived classes you use composition and choose which base events to implement
Implements IDerived
Private WithEvents m_oBase As StdBaseImpl
Private Property Get IDerived_Base() As IBase
Set IDerived_Base = m_oBase
End Property
Private Sub m_oBase_CustomizeArea(Value As Double)
Value = Value + 10
End Sub
You can design bases with BeforeXxx + Cancel and AfterXxx events. You can sink multiple bases and coordinate them.
While going through one of my code, I am stuck on one statement which is as below.
TMyObjectClass = class of TMyObject;
I am a bit confused, and wondering what is the meaning of this statement.
As TMyObjectClass has no declaration above the statement.
and TMyObject is having declaration as below:
TMyObject = class(TObject)
private
//some private member declaration
Public
// some public variables
end;
So, my question is what is the meaning of the statement
TMyObjectClass = class of TMyObject;
and How TMyObjectClass works?
I am a bit new to Delphi, so please help me to get some idea about these type of declaration and there workarounds.
This is a Class Reference.
They are used to work with meta classes. The canonical example is the Delphi streaming framework which uses
TComponentClass = class of TComponent;
This allows for dynamic binding to virtual constructors. The TComponent constructor is virtual. The streaming framework needs to instantiate classes derived from TComponent. It does so something like this:
var
ComponentClass: TComponentClass;
Component: TComponent;
....
ComponentClass := GetComponentClassSomehowDoesntMatterHow;
Component := ComponentClass.Create(Owner);
Now, because TComponent.Create is virtual, this is bound in a polymorphic fashion. If TComponentClass is TButton, then TButton.Create is called. If TComponentClass is TPanel, then TPanel.Create is called. And so on.
The most important thing to realise is that the class that is constructed is determined only at runtime. Note that many languages lack this capability, most notably C++.
In an abstract class, I wish to define static methods, but I'm having problems.
In this simple example
abstract class Main {
static String get name;
bool use( Element el );
}
class Sub extends Main {
static String get name => 'testme';
bool use( Element el ) => (el is Element);
}
I receive the error:
function body expected for method 'get:name' static String get name;
Is there a typo in the declaration, or are static methods incompatible with abstract classes?
Dart doesn't inherit static methods to derived classes. So it makes no sense to create abstract static methods (without implementation).
If you want a static method in class Main you have to fully define it there and always call it like Main.name
== EDIT ==
I'm sure I read or heard some arguments from Gilad Bracha about it but can't find it now.
This behaviour is IMHO common mostly in statically typed languages (I don't know many dynamic languages). A static method is like a top level function where the class name just acts as a namespace. A static method has nothing to do with an instantiated object so inheritance is not applicable. In languages where static methods are 'inherited' this is just syntactic sugar. Dart likes to be more explicit here and to avoid confusion between instance methods and static methods (which actually are not methods but just functions because they don't act on an instance). This is not my primary domain, but hopefully may make some sense anyways ;-)
Looks like you are trying to 'override' a static method. I'm not sure what you are trying to achieve there. I'm not aware of any OO languages that support that (and not sure how they could).
A similar question in Java might help clarify Polymorphism and Static Methods
Note also that it is considered bad practice to refer to statics from an instance of the class in Java (and other OO languages). Interestingly I noticed Dart does not let you do this so is in effect removing this bad practice entirely.
So you couldn't even fool yourself into thinking it would behave polymorphically in Dart because you can't call the static from the instance.
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?
In Programming in Scala: A Comprehensive Step-by-Step Guide, the author said:
One way in which Scala is more
object-oriented than Java is that
classes in Scala cannot have static
members. Instead, Scala has singleton
objects.
Why is a singleton object more object-oriented? What's the good of not using static members, but singleton objects?
Trying for the "big picture"; most of this has been covered in other answers, but there doesn't seem to be a single comprehensive reply that puts it all together and joins the dots. So here goes...
Static methods on a class are not methods on an object, this means that:
Static members can't be inherited from a parent class/trait
Static members can't be used to implement an interface
The static members of a class can't be passed as an argument to some function
(and because of the above points...)
Static members can't be overridden
Static members can't be polymorphic
The whole point of objects is that they can inherit from parent objects, implement interfaces, and be passed as arguments - static members have none of these properties, so they aren't truly object-oriented, they're little more than a namespace.
Singleton objects, on the other hand, are fully-fledged members of the object community.
Another very useful property of singletons is that they can easily be changed at some later point in time to not be singletons, this is a particularly painful refactoring if you start from static methods.
Imagine you designed a program for printing addresses and represented interactions with the printer via static methods on some class, then later you want to be able to add a second printer and allow the user to chose which one they'll use... It wouldn't be a fun experience!
Singleton objects behave like classes in that they can extend/implement other types.
Can't do that in Java with just static classes -- it's pretty sugar over the Java singleton pattern with a getInstance that allows (at least) nicer namespaces/stable identifiers and hides the distinction.
Hint: it's called object-oriented programming.
Seriously.
Maybe I am missing something fundamentally important, but I don't see what the fuss is all about: objects are more object-oriented than non-objects because they are objects. Does that really need an explanation?
Note: Although it sure sounds that way, I am really not trying to sound smug here. I have looked at all the other answers and I found them terribly confusing. To me, it's kind of obvious that objects and methods are more object-oriented than namespaces and procedures (which is what static "methods" really are) by the very definition of "object-oriented".
An alternative to having singleton objects would be to make classes themselves objects, as e.g. Ruby, Python, Smalltalk, Newspeak do.
For static members, there is no object. The class really just is a namespace.
In a singleton, there is always at least one object.
In all honesty, it's splitting hairs.
It's more object oriented in the sense that given a Scala class, every method call is a method call on that object. In Java, the static methods don't interact with the object state.
In fact, given an object a of a class A with the static method m(), it's considered bad practice to call a.m(). Instead it's recommended to call A.m() (I believe Eclipse will give you a warning). Java static methods can't be overridden, they can just be hidden by another method:
class A {
public static void m() {
System.out.println("m from A");
}
}
public class B extends A {
public static void m() {
System.out.println("m from B");
}
public static void main(String[] args) {
A a = new B();
a.m();
}
}
What will a.m() print?
In Scala, you would stick the static methods in companion objects A and B and the intent would be clearer as you would refer explicitly to the companion A or B.
Adding the same example in Scala:
class A
object A {
def m() = println("m from A")
}
class B extends A
object B {
def m() = println("m from B")
def main(args: Array[String]) {
val a = new B
A.m() // cannot call a.m()
}
}
There is some difference that may be important in some scenarios. In Java you
can't override static method so if you had class with static methods you would not be able to customize and override part of its behavior. If you used singleton object, you could just plug singleton created from subclass.
It's a marketing thing, really. Consider two examples:
class foo
static const int bar = 42;
end class
class superfoo
Integer bar = ConstInteger.new(42);
end class
Now, what are the observable differences here?
in a well-behaved language, the additional storage created is the same.
Foo.bar and Superfoo.bar have exactly the same signatures, access, and so on.
Superfoo.bar may be allocated differently but that's an implementation detail
It reminds me of the religious wars 20 years ago over whether C++ or Java were "really" Object Oriented, since after all both exposed primitive types that aren't "really" objects -- so, for example you can't inherit from int but can from Integer.