I am trying to learn the decorator design pattern.
The scenario i have though for a good use and to learn coding it is as follows:
A command line output program. The decorators will wrap an outputText class and add additional ability to the output such as text colour, bold text, blinking text etc.
Would this be considered a good use of this pattern or am i missing the point of it?
I think your idea is sound. It's very similar to the text editor sample given in the GoF book.
In that book they use the example of a text editor, with classes for drawing windows, bolding text, etc. They use examples for the decorator pattern in one chapter which mimic what you describe, so I'd say you're on the right track.
so taking it further, you would have a decorator class for italic text, another for bolding text, etc. OK, one could argue that you could have a class to do this for you e.g. TextFormatter, but you just need to use what is right for your situation.
The decorator pattern allows to add features (both structural and behavioarl) by using delegation instead of inheritance. Your example is exactly one good application of it. The benefits are base on the fact that you can have a number of different decorators of a class without having to create a spaghetti graph of inheritance relationships.
This wikipedia page provides further information about this pattern
http://en.wikipedia.org/wiki/Decorator_pattern
Related
Should I put the test classes in the UML diagram? I can't find any "best practice" about this!
It depends. Firstly "the UML diagram" suggests that you are creating a single diagram. This is definitely not good practice. Create as many diagrams as needed lighting certain aspects of the model. So - test cases would be one of those aspects. That means: put them in (a) separate diagram(s).
To add a suggestion, if you want to model tests, you can look to UML testing profile ( UTP link) it provides needed elements to model tests, requirements and so on.
You can use SysML also since it integrates a part of UTP.
It definitely depends on context. Who is going to use the UML model and what will they use it for? In general I would say that adding test classes is going to clutter a UML model and make it difficult to understand - so no. But if the context is that the testing is what you want to explain, then clearly the test classes are going to be pretty important.
As Thomas Kilian points out, creating a number of diagrams from one underlying model is probably the right answer - and being able to do this is one of the reasons you would use UML rather than a simple diagram.
This is a preference. You can choose to or choose not to.
I would say it's better practice to have the tests modeled into the solution. But I wouldn't claim I always follow best practices 🙊
There are many diagrams needed in modeling a solution. I would focus on three: Analysis, Design, and Implementation. All three are class diagrams. All three define your solution at different abstractions.
In the analysis, you're closest to the requirements and the beginning of your solution. In here, you would want to have broad classes. I would not put tests in here since this diagram is still trying to get the shape of the solution from the user and their requirements. An analysis diagram would only have class names in a box, with lines which show their associations.
The design diagram would go into a little more detail on how classes would be built. The blueprint of the application would take shape in the design. This design can be given to any programmer and they write code which would build the solution. The interesting part of the design diagram is that it could also be given to a test engineer and they would write proper tests for the solution to be created.
The implementation diagram is the lowest level class diagram which is created. Most times, I would create this in retrospect. The implementation diagram should be a verbatim translation of the codebase. In the implementation diagram, I would have my test classes included for completeness.
Note, these are my views which I sometimes do not follow to the letter because of business constraints. However, in an ideal world, this is how I would prefer my modeling done.
Can someone direct me to online resources for designing and implementing abstract semantic graphs (ASG)? I want to create an ASG editor for my language. Being able to edit the ASG directly has a number of advantages:
Only identifiers and literals need to be typed in and identifiers are written only once, when they're defined. Everything else is selected via the mouse.
Since the editor knows the language's grammar, there are no more syntax errors. The editor prevents them from being created in the first place.
Since the editor knows the language's semantics, there are no more semantic errors.
There are some secondary advantages:
Since all the reserved words are easily separable, a program can be written in one locale and viewed in other. On-the-fly changes of locale are possible.
All the text literals are easily separable, so changes of locale are easily made, including on-the-fly changes.
I'm not aware of a book on the matter, but you'll find the topic discussed in portions of various books on computer language. You'll also find discussions of this surrounding various projects which implement what you describe. For instance, you'll find quite a bit of discussion regarding the design of Scratch. Most workflow engines are also based on scripting in semantic graphs.
Allow me to opine... We've had the technology to manipulate language structurally for basically as long as we've had programming languages. I believe that the reason we still use textual language is a combination of the fact that it is more natural for us as humans, who communicate in natural language, to wield, and the fact that it is sometimes difficult to compose and refactor code when proper structure has to be maintained. If you're not sure what I mean, try building complex expressions in Scratch. Text is easier and a decent IDE gives virtually as much verification of correct structure.*
*I don't mean to take anything away from Scratch, it's a thing of beauty and is perfect for its intended purpose.
We all know that classes/objects should represent things
while methods/messages should represent operations (verbs).
But how to pick the right verb?
I've heard one "rule for method naming" is to
imagine some completely different implementations and then
simply pick name that is general for all of them.
EDIT: I also know that methods should be named as closest to domain as possible.
(means after intention not after implementation)
What others do you know?
I like to try to name things so that a given line of code would make as much grammatical and syntactic sense as possible, even to a non-programmer. (One of the reasons why I love lambda so much in my .NET code. It's like making new words from Latin roots, you just keep chaining things together.)
There's a pretty good article here on naming classes and methods when building a repository, for example.
I am part of a studentproject and we are to develop a product for a company using Java EE. As "lead architect" in the project I am responsible for composing a good design which should be flexible for further extensions.
Background info: We are to develop a website with a drag and drop GUI with possibilites to connect data sources with data manipulations to perform on that specific data. The GUI should be generic and possible to integrate with upcoming products. This means that we cannot code to an implementation in the presentation layer. Instead we will use an interface to define what kind of data manipulations that are possible for all kinds of products. However, each product might also sport product specific data manipulations (thus extending the interface with more methods).
The problem I have with the scenario above is that I dont see how we could pass on these "product specific data manipulations" to the GUI and say that, in addition to the generic interface, we also possess these data manipulation actions...
Now I had a discussion with some of the more experienced programmers from the company and they told me that there is a common solution to this problem - more specifically known as the "Observer pattern". They draw something like [1] on the whiteboard and explained that it would be possible to "register" to a third party (getApplicationContext) that in turn could convey our product specific interface. This is a common problem to get rid of those nasty circular dependencies, they explained.
I have now had a look on the observer pattern and how it works and I still dont really get how I am supposed to solve the design problem. Could someone possibly try to explain how it would turn out in my specific scenario? I have no real problem understanding how it works with "subjects" and "observers".
Here is an UML diagram of the design where we are using a reference of the specific product. This is what is undesirable and something we would like to get around.
(maybe I got this all wrong...)
I am sorry but I cant change the picture to the correct one as I am a new user... Here is a link to an updated UML diagram:
It seems what you are looking for is the Model View Controller design pattern. The Observer pattern is just a part of this design pattern. There is a short description for doing this with Java Servlets and JavaServer Pages from Java EE on the wikipedia article.
I think i might be being blinded by the way I've learned OO principles. Its always taught in the manner of tangible object is a descendant of another tangible object. Anyway...
I'm trying to work out an OO approach to a conversion utility, basically it will read a text file and based on the first word(s) on the line it will go off and translate / do whatever corresponds. Would this be a case of each command is a new object or...
Its probably a simple answer but I'm struggling
Take a look at the Interpreter, and the Factory Method patterns.
I did this once for a database conversion application. I had import plugins (classes) that read data into a common model. Then the export plugins (classes) read the common model and wrote it out to a database. In my case, this was a .NET application, so I used MEF to split the importers and exporters into different assemblies. Customers could plug in whatever importers and exporters they needed, or could even write their own if they wanted to.
I would not get too caught up in OO design for something like this. OO principles should be used only if they are obvious and help you with reuse. That might not be the case here. Also, this does not sound like a large app. The pitfall people fall into is making way too many classes just to get a little bit of reuse. This quickly makes things unmanageable. Just do it the old-fashioned way and if something jumps out at you where inheritance can help for example, then use it.