I have a class called MVC which provides separation and acts as a broker between wxFrame/UI and the Model Data.
class diagram
To keep things simple, MVC was made a member variable of wxFrame.
class MAIN_FRAME: public wxFrame
{
public:
MAIN_FRAME();
public:
MVC MODEL;
};
wxFrame implements a 'virtual wxListCtrl' to request the list data from MVC.
However, I'm not clear on the best way for the 'virtual ListCtrl' to access the MVC, specifically in the overloaded function which requests the list data. The problem being that MyVirtualListCtrl is separate from wxFrame so doesn't have scope to access wxFrame member variable MVC:
wxString MyVirtualListCtrl::OnGetItemText( long item_, long col_ ) const
{
// If no data then populate list cells with "Empty".
if( this->MVC.empty() )
{
return _( "Empty" ) ;
}
// Use item and column to return the correct data for that particular cell.
// mock solution
>>wxString s = MVC.get_data( item_, col_ );<<
>>return s;<<
}
When constructing your MyVirtualListCtrl class, you can give it a reference to the MAIN_FRAME or, arguably better, directly to its MODEL and then just use it. As you can safely assume that MAIN_FRAME (and hence its model) will outlive MyVirtualListCtrl, because the frame children are destroyed when the frame itself is, this is safe from the object life-time point of view.
Related
As title, is there any way to iterate or display Apache velocity template attributes?
for example, I have following code :
<code>
${ctx.messages.headerMessage}
</code>
And I want to know how many other attributes the variable ${ctx} has
It's only possible to discover and to loop on an object properties (that is, the ones with getters and/or setters) if you can add a new tool to your Velocity context. If you can't, you're rather stuck.
There are several ways to do this, I illustrate below how to do this with commons-beanutils.
First, add Apache commons-beanutils in your class path, and add it to your Velocity context from Java:
import org.apache.commons.beanutils.PropertyUtils;
...
context.put("beans", new PropertyUtils());
...
One remark: if you do not have access to the Java part, but if by chance commons-beanutils is already in the classpath, there is one hakish way of having access to it: #set($beans = $foo.class.forName('org.apache.commons.beanutils.PropertyUtils').newInstance()).
Then, let's say that I have the following object:
class Foo
{
public boolean isSomething() { return true; }
public String getName() { return "Nestor"; }
}
which is present in my context under $foo. Using your newly $beans properties introspector, you can do:
#set ($properties = $beans.getPropertyDescriptors($foo.class))
#foreach ($property in $properties)
$property.name ($property.propertyType) = $property.readMethod.invoke($foo)
#end
This will produce:
bar (boolean) = true
class (class java.lang.Class) = class Foo
name (class java.lang.String) = Robert
(you'll need to filter out the class property, of course)
One last remark, though. Templates are for coding the View layer of an MVC application, and doing such a generic introspection of objects in them is rather inadequate in the view layer. You're far better of moving all this introspection code on the Java side.
I have a parent bean having one instance variable like below :
public Class ParentBean {
protected boolean show; // this variable will be used to show some UI component
public void action() {
// update show variable here
}
public boolean isShow() {
return show;
}
}
Is it a good design if I want to reuse the "show" variable in a child bean (to show other UI component specific to child bean ) as shown below :
public Class ChildBean extends ParentBean {
// override the action method from parent bean
public void action() {
// update show variable here
show = true /false;
}
}
In effect , show variable is being updated by "childBean" by overriding action() method.
Is this a good design practice ? Otherwise same thing has to be repeated in ChildBean to get this work done.
If you use the show variable for the same purpose in the subclass, as you seem to be doing in this example, then obviously you should reuse it, because otherwise you just end up writing the same code twice, which is contrary to the point of OOP.
In general, in OOP, it is common to override superclass methods in subclasses, as well as modifying superclass instance variables, as long as you know what the variable you are modifying is being used for (you don't want to be randomly changing instance variables in classes that you don't completely understand, or don't have access to the source of, because you don't want any unfortunate side effects), so when it's your own code, this is absolutely fine.
As a general guideline, if your options are either to copy and paste a massive hunk of code and use it unchanged, or subclass and use the superclass' instance variables or functions, it's better to subclass. Otherwise, you're missing out on the point of OOP.
Changing the value in subclass will not affect superclass variable
This is fine with respect to the design. When a subclass object is instantiated, it will have a different copy of variable. and If superclass object is instantiated it will have different copy.
It is. Having a protected variable means you are allowed to modify it into parent or children classes (remember every single instance of each class has its own property values). So, if you have some generic functionality which is valuable for all the children:
Parent class:
public void action(){
//update show variable here
show = true;
}
Appart from that, if you want to add some extra functionality in a specifical child:
Child class:
#Override
public void action(){
super.action();
//Extra functionality goes here
//You can also access parent's 'protected' fields
if (show){
System.out.println("Shown");
}
}
An example of the use:
Parent p = new Parent();
p.action();//Prints nothing
Child c = new Child();
p.action();//Prints 'shown'
I am learning Symfony2, and part of the documentation on controllers states that the methods on the controller object are actually the controllers, whereas the object is more of a controller container.
Which part specifically is referred to as the controller(s)? I'm new to MVC and OOP, so I'm just trying to make sure I have it right.
the page describes actually a convention endorsed by Symfony2 creators.
in some MVC frameworks (esp. in Java) controllers are implemented by one-class-per-controller convention, e.g.:
class ListContactsController {
public function start() {
// query db...
return ...;
}
}
class AddContactController {
public function start($name, $details) {
// insert into db...
return ...;
}
}
note that every controller-class has one method start() that defines what the controller actually does
in other MVC frameworks (like Symfony2 or cake-php) controllers are implemented by one-method-per-controller convention, grouped together for convenience, e.g.:
class ContactsController {
public function list() {
// query db...
return ...;
}
public function add($name, $details) {
// insert into db...
return ...;
}
}
here the convention assumes every controller is implemented as a method rather than a separate class with a particular method like start()
EDIT: another way of thinking about this difference is this:
one-class-per-controller assumes there is one controller instance (might hold internal state) and when user interacts with the view, view is communicating with that controller instance via callbacks i.e. methods in controller's class.
one-method-per-controller assumes any state is contained within parameters that are passed to methods, and when user interacts with the view, view is communicating with separate controllers/actions. those controllers are seen as independent concepts.
In the example page you shared, the "class HelloController" is the Controller and its' functioned are Controller "Methods".
Okay, they are referring to the default method, indexAction() as the Controller.
In this MVC architecture (and most others, if not all) the "index" method is the default method (function) called when that controller is requested.
I have this problem at hand and wanted some inputs on best way to approach it -
In my application, i have different set of objects and each object has some properties associated with them.
For eg: objects like, say, shapes , which has some common properties like color and specific properties ( for eg: circle has radius and center has its specific property )
The user can change object properties through a property inspector.
Currently, the PI holds a object ID and uses that to talk to DOM for anything related to object it currently refers. like say, if it wants to change the property of object it will call DOM Api
ChangeObjectProperty(objectID , *);
(I hope using object ID to refer to objects inside the DOM is right way. (is there a better way to do this ?))
What should i pass as the second argument ?
Should it be a single opaque object ( say, IObjProps) where each objects provides its own structure ?
For example the circle will have following structure of its own -
class CircleProps extends CommonProps
{
public var radius:Number;
public var center:Point;
}
class CommonProps extends IObjProps
{
public function clone();
public var color:Number;
}
The DOM will pass on this structure to the object and object takes care of applying the change.
So ChangeObjectProperty(objectID , *); function will be implemented as -
function ChangeObjectProperty(objectID , props:IObjProps)
{
var object:Object = GetObjectFromID(objectID);
object.SetProperty(iObjProps)
}
The problem with the above approach is that - its kind of difficult to know what specific property changed since its a single structure -
The alternative is to have property dictionary - the client inserts only the properties which got changed into the dictionary.
I wanted to know what is design pattern followed for such use cases.
Adding more info - this is actionscript -
Can a class return an object of itself.
In my example I have a class called "Change" which represents a change to the system, and I am wondering if it is in anyway against design principles to return an object of type Change or an ArrayList which is populated with all the recent Change objects.
Yes, a class can have a method that returns an instance of itself. This is quite a common scenario.
In C#, an example might be:
public class Change
{
public int ChangeID { get; set; }
private Change(int changeId)
{
ChangeID = changeId;
LoadFromDatabase();
}
private void LoadFromDatabase()
{
// TODO Perform Database load here.
}
public static Change GetChange(int changeId)
{
return new Change(changeId);
}
}
Yes it can. In fact, that's exactly what a singleton class does. The first time you call its class-level getInstance() method, it constructs an instance of itself and returns that. Then subsequent calls to getInstance() return the already-constructed instance.
Your particular case could use a similar method but you need some way of deciding the list of recent changes. As such it will need to maintain its own list of such changes. You could do this with a static array or list of the changes. Just be certain that the underlying information in the list doesn't disappear - this could happen in C++ (for example) if you maintained pointers to the objects and those objects were freed by your clients.
Less of an issue in an automatic garbage collection environment like Java since the object wouldn't disappear whilst there was still a reference to it.
However, you don't have to use this method. My preference with what you describe would be to have two clases, changelist and change. When you create an instance of the change class, pass a changelist object (null if you don't want it associated with a changelist) with the constructor and add the change to that list before returning it.
Alternatively, have a changelist method which creates a change itself and returns it, remembering the change for its own purposes.
Then you can query the changelist to get recent changes (however you define recent). That would be more flexible since it allows multiple lists.
You could even go overboard and allow a change to be associated with multiple changelists if so desired.
Another reason to return this is so that you can do function chaining:
class foo
{
private int x;
public foo()
{
this.x = 0;
}
public foo Add(int a)
{
this.x += a;
return this;
}
public foo Subtract(int a)
{
this.x -= a;
return this;
}
public int Value
{
get { return this.x; }
}
public static void Main()
{
foo f = new foo();
f.Add(10).Add(20).Subtract(1);
System.Console.WriteLine(f.Value);
}
}
$ ./foo.exe
29
There's a time and a place to do function chaining, and it's not "anytime and everywhere." But, LINQ is a good example of a place that hugely benefits from function chaining.
A class will often return an instance of itself from what is sometimes called a "factory" method. In Java or C++ (etc) this would usually be a public static method, e.g. you would call it directly on the class rather than on an instance of a class.
In your case, in Java, it might look something like this:
List<Change> changes = Change.getRecentChanges();
This assumes that the Change class itself knows how to track changes itself, rather than that job being the responsibility of some other object in the system.
A class can also return an instance of itself in the singleton pattern, where you want to ensure that only one instance of a class exists in the world:
Foo foo = Foo.getInstance();
The fluent interface methods work on the principal of returning an instance of itself, e.g.
StringBuilder sb = new StringBuilder("123");
sb.Append("456").Append("789");
You need to think about what you're trying to model. In your case, I would have a ChangeList class that contains one or more Change objects.
On the other hand, if you were modeling a hierarchical structure where a class can reference other instances of the class, then what you're doing makes sense. E.g. a tree node, which can contain other tree nodes.
Another common scenario is having the class implement a static method which returns an instance of it. That should be used when creating a new instance of the class.
I don't know of any design rule that says that's bad. So if in your model a single change can be composed of multiple changes go for it.