Visual Studio 2005 discontinued and other changes...

Visual Studio 2005 Express Edition will disappear till tomorrow (without being the Foul Day's joke), so NaroCAD will not be suported to compile under this environment. And there is a good reason to upgrade: NaroCAD already uses Visual Studio 2008 features. SharpDevelop 3.0 or later can import nicely the NaroCAD project if you want an alternative environment!

There is a very interesting presentation about how may look the software in future by a chief designer at Adobe.
If you don't have an hour free to look to it the brief ideas are:
- use MVC (Model View Controller) as it separate the coupling and most of problems regarding your code. He said that for a simple dialog, he has 6000 lines of codes reflecting all interactions. He faces a lot the Spagetti Antipattern.
- enforce as much as you can from the language level (like using templates/constraints)
- use Pipes and Filters that makes the flow easier to be comprehensible

They succeed to do a minimalist MVC and a definition of Pipes and Filters in roughtly 2000 lines using widely templates.
The good faith makes that right now NaroCAD uses the same approaches. Accesing data from the model is done by taking the type you want, enforced by a template (we use Generics and Constraints). Without being too negative about C++, I can say that many parts of the NaroCAD code are really much concrete like:
- the Pipes and Filters system is: 350 lines of code
- the Model which is enforced is around 1000 lines of code
This means that with roughly a half of lines of code there is done more. The model knows how to do the Undo/Redo, it knows how to propagate changes, it knows how to enforce setting data in it and also it notifies also automatically.

The good point is also that the lines of code are decreasing (the assumption of him is that the lines decrease for 6 times, which may mean also that Adobe can have good drawing designers but bad software designers), but because we use specific OpenCascade code, events code which is already minimalistic in C#, etc. we gain reductions but not more than 50% of initial code size.

In weekend I've made a lot of enforcements and I finish them today. This means that all (3D) actions are ported with Inputs/Pipes. I have still problems to setup another plan and selection problems but I will fix them really soon. Today I've separated the coupling as there was in code a cast that makes presumtions about inputs. All of this are changed and data right now is sent and must be checked by the consumer. If I will find a nice way, I will try to do more on enforcing how data is send but without doing coupling.

One thing is still not fixed yet, but it will be very soon is that all 3D actions that do modify the scene, need to update the tree of objects, but they don't. Why? Because I should copy the code of updating the tree in actions. From now on, the actions will say: I need a tree view as an input, and I will say: UpdateTree. This will also make the code cleaner and adaptable. If tomorrow instead a Tree, there is a ListView, there is no problem, and at least we should not replace code more than 1 place: the action that provides the tree control.

Why coupling is very important to be avoided? In many cases developers wants code like: clicking on a button, the main window to be closed. They do at that time: Parent.Close(). Later, appears in the main menu the same option. Developers do the same code. Eventually, a toolbar action will need the same. Developer do the same.

For any reason, the application alegedly have a big start time, so the designers of the applications decide that instead closing the window, the window should be hidden and shown at a second launch. This will mean that the developer will have to replace all places of Parent.Close() with Parent.Hide(), but also, that seem to not be enough, as Parent.Show() have no sense, as Parent is coupled with the button, menu and toolbar action. Eventually the developer will separate the actions by the window, so eventually developer will call: MainWindow.Hide() and MainWindow.Show(). This doesn't seem a big deal for a 3 lines problem, (in 3 places to replace 1 line with another), but in most cases this overhead in code leads to copy/paste, and the worst of all, is hard to break the application flow easily. Coupling also leads to most programming errors in OOP programming at least: because everything knows about everything, the developer tend to break encapsulation (like putting some members of a class public) just to "simplify" the code.