<div class="gmail_quote">2009/4/10 Mikael Hansson <span dir="ltr"><<a href="mailto:forums@deadmengods.com">forums@deadmengods.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

To what extent do you use UML in your coding? (none, planning,<br>
documenting, codegeneration...)<br>
</blockquote><div><br><br>The least amount I can get away with for documentation purposes, which is usually activity diagrams, entity relationship diagrams, and whatever else is needed to properly document a system for other people (and no, the code does *not* speak for itself, especially my code). If I really can't help it, it would include use case diagrams.<br>
<br>The people on this list who claim it's useless or that they don't use it or that it attracts the wrong kind of people or that it will bring the Antichrist in our mids have never done a proper course of designing with UML, starting with stakeholder interviews and ending with a full design, from which tools can generate skeleton code for you.<br>
<br>It *is* indeed very powerful, especially if you're not very good or not very experienced at programming. In my case, I can just see the design in my mind, draw a few boxes and arrows on paper, and know what interfaces and classes to write. This is not what they teach you to do, but I'm not your average kind of guy when it comes to programming.<br>
<br>This is not to say that I'm incredibly good (just quite good and quite a bit too lazy), or that I wouldn't make mistakes (make them all of the time, and I keep rewriting my classes and interfaces as the development progresses), but it works for me, and my colleagues seem to think that I'm God's gift to their programming department - when it comes to writing code, that is, let's not go into all the rest. :)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Any hints of what to think of when making a program with an<br>
easy-replacable user interface. I'm supposed to make a Library DB<br>
application with the option to add and remove different items, search<br>
for them with different keys, borrow and return by itemid.<br>
<br>
I'm supposed to do two interfaces, one textbased and one with Qt and the<br>
underlying code should be the same for both. The plan is to make an<br>
abstract LibInterface, which the other inherits from.<br>
<br>
How would you set up the connection between the app and the UI?<br>
</blockquote><div><br>Ah, that's simple. You have your set of data, and you have operations that you can perform on that data. These operations can be expressed as a couple of methods, and those methods you can put in an interface. In C++ speak, these would probably be pure virtual methods, or something like that.<br>
<br>In my view, the prescribed design is kinda stupid, because it appears that they want to share code between the various interfaces, which sorta defeats the whole scope of having different interfaces in the first place.<br>
<br>I was going to write something about events and listeners, but really, inheriting both interfaces from some sort of base just won't work. It's really trying to force a procedural way of thinking into an object-oriented design. The interfaces trigger events, the events cause methods in the interface that I mentioned before to be called.<br>
<br>If you really must stick to the design with an abstraction for both text and GUI, you could consider abstracting the event model, but it would not be a design that I would look kindly upon. Could you clarify this with your teacher(s)?<br>
<br>- Peter<br></div></div>