I am trying to determine that if (before I start) on a new project I can pick some suitable patterns which will help with development as the project gets more complicated.
The Scenario
To have an application that draws 'simple' lines on the screen. Ideally encompassed into a 'Render Engine' which I can package into Silverlight, WPF demo applications etc.
I also require editor application that uses the render engine to do the bulk of the displaying, however provides additional functionality like control points for moving the lines about the screen & Dialogs for changing the colours of the lines etc.
The Goal
To keep the render engine specalised and efficient. The editor should be able to 'inject' the additional functionality (i.e. display of control points) into the objects used by the rendering engine, or into the render engine itself. I don't want to code any editor specific code into the render engine.
My thoughts so far
I'm thinking of using an encapsulation/template pattern for the objects that will be used by the rendering engine, somehow allowing the editor application to supply a class to the object which 'tacks on' the functionality for the control points (and for example the event handling for moving of the control points).
My reason behind liking this idea is that the rendering engine never need know about the environment in which it is working. The editor can be changed extensively without ever having to change the rendering engine (hopefully).
But....
I may be wrong, if anyone can see any pitfalls, or has experience of better ways to tackling this problem I would love to hear them!
I agree with Charlie that you should start with a simple design prototype and extend it as needed (that's how I started with my map rendering engine). I can give you a few suggestions though:
Separate the drawing engine from the rest of the code (here's an example how). By the drawing engine I mean the code that actually draws something on the screen/bitmap. It should consume drawing primitives, not some higher-level entities. This way you'll be able to switch the drawing engine easily (example: SVG, PDF, GDI, WPF...)
If you want to have an editor, one of the patterns that are useful is the State pattern
Well shoot, that's an impressive amount of forethought.
My philosophy has always been, use a design pattern when you need to use one. Otherwise you may become an architecture astronaut, designing grand schemes all for naught. It's good that you're thinking about design before development, but really, how much can you possibly know about the project before any code has been written? Just about nothing. And if you force yourself into a pattern before any code has been written, you may end up jamming a square peg into a round hole for the entire lifecycle of the application.
My advice to you: write a prototype first. Quick and dirty. No real design; just make a skeleton that walks. Learn from it. If you thought of a better way, scrap the original and redesign a new one. Use design patterns that make sense as you add functionality, not for the sake of adding functionality.
Related
I am good at C# programming and I want to know if is possible to make objects from another DirectX program about fifty persents tranpanent, so I can see behind them? I will be happy if you provide some working example or link to some tutorial to take me to the right direction.
I don´t care about DirectX version but it will be great if it work on version 9 and up.
I don´t know anything about patching DLLs, so it will be great if it only use some C# hooks without dll editing.
If it isn´t possible with C# it is possible with C++?
It is possible with both C# and C++ Although I prefer c++ for such things, I can recommend C# hook solutions like EasyHooks: https://easyhook.github.io/. With DX9 you might need to hook BeginScene function and apply transparency state, but iut might be too early. You have to do a lot of test. You might also need to modify the object's vertex declarations prior to Present (dx10/11) or EndScene (dx9). IT depends on how the objects are drawn in each application.
You can also check Direct3DHook on GitHub: https://github.com/spazzarama/Direct3DHook
You can look at #VuVirt answer for the hooking portion, but the challenge reside in the translucency portion, here a little list of the things you may have to consider depending on the application you want to hook to:
Depth testing : If objects are not render back to front, you have to disable depth testing to see them.
Depth Prepass : If an engine do a pre-pass to fill the depth, you won't be able again to see thought unless you disable that pass fully.
Translucency need a back to front order to look correct.
Deferred rendering : Opaque are rendered in multiple render-target and lit in screen space, tweaking the translucency here would be meaningless and pure wrong.
Occlusion culling : If an application do occlusion culling, the object you wanna see may not even be sent to DirectX.
Various post process may need to be opaque to copy surface around.
Way many other obstacles in the way.
I'm sorry to ask such a localized question but until I get confirmation I don't feel confident moving on with my project.
I have read lots about the template pattern, Wikipedia has a good example.
It shows that you create the basic virtual methods and then inherit the base class and override where you want. The example on the site is for Monopoly and Chess which both inherit the base class.
So, my question is, if you had an application which was only going to be Chess and never anything else, would there be any benefit in using the template pattern (other than as an education exercise)?
No, I think that falls under the category of "You Ain't Gonna Need It."
To be more specific, design patterns exist to solve a particular problem, and if your code doesn't need to solve that problem, all they do is add lines of code without having any benefit.
No. Expressed in a very simplified and superficial way, the template pattern is just worthwhile starting at a certain relationship between total code size and templated code size. In your example, the chess game is going to be the entire program, so there'll be no need to use the template pattern here.
The template pattern is used in specific situations. It is used when you want to sketch out an algorithm but let the specific steps differ.
This could be useful in a Chess application. However, you should not start developing an application with the idea 'I'm going to use this pattern and that one and..'. Instead, you develop the code and you discover that you need certain patterns.
This is where a Test Driven Development approach is really handy. It allows you to refactor your code each step of the way.
A nice book that explains this is Refactoring To Patterns.
I would suggest writing your chess game and then if in the future coming back and changing things to fit monopoly too. But its something totally different if you want to use the pattern to learn the pattern, in that case its good to start simple so the complex is easier to understand.
It really depends on the parts of the program. The whole idea of Template is to have an algorithm that never changes and to be able to add or edit certain steps of that algorithm.
It may well be that you never change, however, this is the issue with design principles, it IS good practice and you may later wish you'd implemented them. I would say though that if you are 100% sure then you can leave it out as it usually saves time and lines of code. Depends if you want to learn Template usage or not.
Also the GOF principles website is quite good:
I'm working on an XNA project, for the Xbox 360.
For this I have built an extensive UI library, all with relative positions, dozens of controls and stuff like that.
At the moment of speaking, all the design elements are created in page classes, which is a lot of code (think of margins, aligns, labels, and so on).
So I was thinking, shouldn't it be possible, to create a file, like a XAML file for example, and using C#, parse it to objects?
XNAML uses this kind of approach (I think), so I know it must be possible, I'm just wondering how. I could go with the approach of parsing the file manually line by line, and creating every object, but I think this would be pretty complex & nasty code, considering the amount of different objects. Any input is greatly appreciated!
F.Y.I., XNAML is deprecated (I even think it never went live)
I need to visualize a graph. I don't know how to name it (by the way, if you know - I'll appreciate if you tell me). It would be ideal for graph elements to be clickable (so that when user clicks on a block, I can handle an event with the element id specified) but I can survive even without any interactivity. I may like to be able to focus on a particular node and layout all others to view from its perspective. Are there any components available good for this task? If no, what should I look for to help me to develop an algorithm for drawing such a graph with visually-comfortable layout?
Practical nature of this graph is pretty common: each block represents a derivation from 2 operands. Orange circles are references to 2 operands, green circles are connection points to consumers. It can be significant to distinguish an operand position (left or right), for example if a derivation represents a mathematical operation of difference or division (in this particular case a block can be triangular, but in other cases an operand itself can make use of being aware of for what blocks is it a left operand and for what blocks is it a right). Another common application is intersecting sets with complex relations.
You could take a look at Graph#, but I'm not sure how well it'll handle composite nodes like that. It could be a good starting point though.
I also would like to point you to graphviz. It is not a .NET solution but you can feed it files that are easy enough to write in order to create graphs. I don't think layouting is a very simple thing to do, especially with increasing node count, so it should be a good thing to find some tool for that.
As It seems Microsoft itself has done a really good job on graph visualization called automatic-graph-layout.
Here's the link https://github.com/microsoft/automatic-graph-layout.
Well, you first need to represent it somehow in memory, there are many ways, like adjacency list. Then you need to draw it. While generally drawing a graph is simple, it's not that simple if you need to layout it. Looks like in your case, that's exactly what you need to do to come to that nice representation. It ain't going to be easy.
EDIT: Interesting, there seems to be a library made by Microsoft Research.
I don't know how useful it will be in this particular scenario, but you might want to take a look at http://quickgraph.codeplex.com/
Graphviz4Net provides WPF component for graphs visualization. It depends on GraphViz (open source command line graph visualization tool).
I can not find this component and i decided writen my own control, line and head, and use them to visualization my graph's
If the needed your i can give it's component and program to demonstrate him/
I writen component and program's in visual studio 2008 language C#
This is a fairly new and maintained .NET wrapper for Graphviz: https://github.com/Rubjerg/Graphviz.NetWrapper
(Disclaimer: I'm the author)
This wrapper works differently from other wrappers, since it makes direct function calls to the native Graphviz code. This means you can not only programatically construct your graph in C# code, but also read the layout attributes back out in C# code and render it any way you want. The latter sounds specifically like something you would be interested in.
A quite good looking one is the Diagram tool from Nevron. But it's not for free!
I'm currently using the charts and user interfaces from them and they work quite good.
Have used this commercial product with success: GoDiagram
It support the multiple ports on the nodes like you have shown.
If it is possible to auto-format code before and after a source control commit, checkout, diff, etc. does a company really need a standard code style?
It feels like standard coding style debates that have been raging since programming began like "put the bracket on the following line" or "properly indent your (" are no longer essential.
I realize in languages where white space matters the diff will have to consider it but for languages where the style is a personal preference is there really a need to worry about it anymore?
Auto-format can really only address whitespace.
It wont address developers giving variables bizarre nonsensical names.
It won't address some developers having functions return null on an error vs throwing an exception.
I'm sure others can think of more examples.
This is what we do at my work:
We all use Eclipse. We don't have a policy for using Eclipse but somehow none of us is an IDEA/IntelliJ guy. We also think our code should be written with legacy in mind. This means our code has to be readable in a certain way even years after (#1) no matter who wrote it and if that person even is in the company anymore.
Eclipse has couple handy features, automatic format on save and a specific Formatter tool. As you can see from the linked screenshot, it can be configured with XML. Thus there's a bunch of premade XML:s available for every worker in our company so that when a new guy comes in, we walk him through of the whole process and configure their Eclipse for them (yes, it's slightly evil thing to do) so that it actually uses those formatting XML:s we have provided. We do not enforce automatic format on save, we don't want to be completely intrusive, we just want to push all our developers into the right directions. For even increased compatability, we mostly use rules defined in JCC.
Next comes the important part, the actual builds. We are those who embrace automatic builds and for that we use Hudson Continuous Integration Server. There's two important parts in our configurations beyond this:
We use CVS loginfo to trigger builds whenever something is committed.
We utilize several plugins available for Hudson, including Continuous Integration Game in conjuction with the most important one, Checkstyle.
The Checkstyle Plugin is the magician in our code style enforcement guide line:
After commiting code to CVS, Hudson build is triggered
After build has been completed succesfully (all unit tests pass etc.), Checkstyle inspects the actual source files
Checkstyle ranks the code based rules we have defined for it
Continuous Integration Game sees the result of Checkstyle and awards/takes away points for the person who has the ownership for the relevant part of the code
Leaderboard shows total points for every commiter in system
Basically this means that when anyone commits ugly code into our CVS, our build server automatically reduces that person's points.
This means that eventually any one of us can be ranked on the Leaderboard based on the general code quality in both look and OO principles such as Law of Demeter, Cyclomatic complexity etc. etc. Naturally this isn't a completely serious statistic, but it's a good indication you're doing something wrong when causing a build to be initiated in our CI won't reduce your points - most of our commits are worth between 1 and 5 points.
And is it working? Sort of, I don't think anyone of us at my work writes ugly or unmaintainable code and personally I love to hunt all kinds of scores so it's definitely motivating me to make code that looks nice and follows all the OO paradigms I know of.
And do we as a company really need it? I think we do as you should see from reading this entire answer, it can be considered a good practice for the advancements it brings.
#1: in a related note, I refactored legacy code from 2002 today which used those standards, didn't look "bad" at all even in its original form and certainly not worse in its new form
No, not really.
If you can actually get it to work consistently and not make it flag code has changed due to a different style of laying the code out.
However, this is just a small part of coding standards. It won't cover multiple return statements, the use or not of ternary operators, etc.
It is always nice if the coding style that the shop uses is the same one that is also followed by the development tools.
Otherwise, if there is a large body of code that already follows a shop standard which is NOT the same as that of the tools you have two choices:
Modify all of the code to follow the tool standard, or
Maintain the existing shop standard.
Many shops do the latter. Regardless, there does need to be some kind of standard, and it does need to be followed.
Some development tools allow you to tweak their standard. In some cases you may be able to bring the tools in alignment with the shop standard.
It probably doesn't matter that much anymore if you can ensure that everybody in the team sees the source code "correctly" formatted, whatever they think it is. However I've not seen a system that can do that - you can do parts of it (say, reformat before and after checkin/checkout) but these days you also have to consider web interfaces into the version control, external code review systems that interact directly with the version control system etc.
The main purpose of a standard code style is (IMHO) to ensure that you can read other team members' code easily without having to start reverse engineering it because all the code is written using the same sort of guiding principles. Indenting and parentheses placement seem to be a major hangup on this but they are only a very small and in my opinion, somewhat overblown and not very important part of the need to make code consistent.
Unfortunately I'm not aware of any tools that can automatically apply consistent coding principles to source code...
Yes, coding styles are needed if there is a desire to have a homogeneous code base. Such a code base can be useful in preventing individual ownership of parts of the code base, which can cause problems when people leave the team. If you can't imagine having wildly different styles and problems understanding all of it, just look at all the different ways English text can be organized in various communications, all written but quite different such as tweets, e-mail, text messages, IM, message board posts, etc. and changes in fonts, capitalization, decorations, etc.