Design and Architecture

Hi, you can use any protocol you like, or come up with your own; I often have. It all depends on your needs (throughput, reliability, recovery, multi-drop, etc). One not so simple example is SLIP. If you roll your own, first decision is binary versus text (compactness versus ease of communication, getting all characters through the driver/modem/...). Whatever you choose, make sure you know to locate the end of each message: either prefix the length, or set a unique terminator (CR and/or LF on text). :) Luc Pattyn [Forum Guidelines] [My Articles] The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.

Interesting topic. It is very frustrating when interfaces express very complicated dependencies between objects. Cyclic dependencies may result in endless loops and weird state control. An interface specifies a unidirectional 'control panel': You can use it to push and pull, but you have the initiative and don't want be interrupted while using the interface. However, if cycles exist between interfaces (or between objects), you may be interrupted each time you try to operate a certain object via an interface. If this happens a lot, you have spaghetti code. Our world is full of interconnected objects that control each others, so what to do about these when modeling them in software? A very simple example is a Nut and a Bolt. Sometimes the Nut turns the Bolt and sometimes the Bolt turns the Nut. Lets say an interface for both Nut and Bolt is ITurnable and it contains a turn(float angle) method. No interface cycle exists. Now, if Bolt is turned, it decides whether an attached Nut should be turned or not. Likewise, if Nut is turned, it decides whether an inserted Bolt should be turned or not. These decisions are implementation specific, and it may be that Nut and Bolt call each other recursively, but the ITurnable interface is clear about direction of control. Yes, I know. The Bolt and Nut need to be connected, if they should know something about each other e.g. friction, or if they should be able to turn each other; how could that be expressed with interfaces? A) Interface for a made up object. You can make a fictional interface that ties a Nut and a Bolt e.g. an IConnection implemented by a 3rd class e.g. Connection. If a Nut actively unscrews itself, it will direct control to the IConnection implementor that is responsible for letting the Bolt know. B) Interface for existing objects. You can implement an attach/detach interface for Nut and Bolt e.g. IConnector implemented in both classes. This interface could just have an attach(IConnector connector) and a detach(IConnector connector) method. Again the direction of control is clear, and it is specified via IConnector that Nut and Bolt can be interconnected. C) Interfaces for existing objects. You can implement attach/detach in interfaces of Nut and Bolt e.g. INut and IBolt, respectively. INut could have an attach(IBolt bolt) and a

I would say you are looking for the Composite pattern: http://en.wikipedia.org/wiki/Composite_pattern[^]. With this pattern the quick solution is to make class A the composite and class B an component. A more beautiful solution is to create an abstract Component class that just contains the functionality related to administering the tree data structure. You then create 2 implementations of this abstract class: - class B that just re-uses the methods of the abstract class and adds its own functionality, - class A that just re-uses the methods of the abstract class, but adds collection functionality and its own functionality. A very beautiful solution is to separate specification from implementation: - specify B's own functionality in an interface IB, - specify A's own functionality in an interface IA, - make an abstract class Component that contains child logic, - make an abstract class Composite that contains collection logic, - make a class B that inherits class Component and implements IB, - make a class A that inherits class Composite and implements IA. In the implementation of class B, you can now check, if the parent is of type IA, and then use the functionality of IA. In the implementation of class A, you can now check, if a child is of type IB, and then use the functionality of IB. You can even make interfaces for the Component and the Composite, if you go 100%. Hope above was a little helpful. Remember, you decide your design! Regards, Keld Ølykke

We do something similar except we use check boxes to determine whether or not to link the combos. The check boxes provide the visual feedback so that the user knows whether or not they're seeing filtered data and at the same time allows them to control whether or not they want to see filtered data. I don't know of any established patterns for this but it really doesn't take that much to implement a solution. :Badger:

Also somehow I need to have a list of possible tags, for the parsing -private- method.. Maybe another class, TagAnalyzer?

Hi, it depends on the circumstances. If the parameters are like characteristics of the objects, then data members would be alright. If they are small, then having storage allocated for them for the lifetime of the object probably is irrelevant. If they more act like operational parameters, seems to me method parameters are in order; if they are many, you may want to create a separate struct or class to hold them and pass them around easily (kind of "job ticket"). :) Luc Pattyn [Forum Guidelines] [My Articles] The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.

Thanks for the reply. This is not a real application so the classes are just "hypothetically speaking". However, if it was a real application, Category can still be a valid class because you can create, delete, modify categories as well. Then category will have more properties like id, name, description, books etc. If it is an enum then we can not accommodate the above. Nonetheless, your answer really helped me. CodingYoshi Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07

netJP12L wrote: I couldn't find any brainstorming or thought process tool. Maybe this will work[^]

I have researched the compatibility between starUML and Visio. Apparently, the standard XML for describing UML, called XMI, can be read and exported by both Visio and starUML. StarUML can import and export XMI http://staruml.sourceforge.net/en/about-2.php Visio can export to it (I assume it can read it, too) http://msdn.microsoft.com/en-us/library/aa140339.aspx I will be testing this out, probably.

Thanks. Like everything database oriented, it typically isn't treated the same as developing with oop languages. I appreciate your input.

that sounds great! could you point me to some articles on how to do that please (first solution) If at first you don't succeed Redefine success J.Hardy

http://en.wikipedia.org/wiki/Multitier_architecture[^] Or just google 3-tier architecture - 60000+ results. Regards David R

Manage It! by Johanna Rothman, published by Pragmatic Bookshelf, 2007 ISBN-10: 0-9787392-4-8 ISBN-13: 978-0-9787392-4-9 I think it's a good take on PM and covers all the bases. Regards David R

hi, this is good information regarding the database, thank you also i will don that, los angeles website design

Roger Wright wrote: The architecture is critical, and that's what I was asking about. Couple things Roger Wright wrote: user select one of the main functions - Add, Edit, Move, Service - from the main form User selects from Menus and toolbars, not forms. Roger Wright wrote: The next shot was to create forms for each function and equipment type, then walk through them depending on user selections, and updating the database through the final form in each sequence. Not only is that wasteful (having all those forms lurking about whether needed or not) but it just strikes me as awful design. There ought to be a single point of control for the data access, a separate layer that is common to all functions. The problem with that section is that you are coupling the UI design to the Code design. This is not correct. Arrive at a UI design from considering usability. The problems with code design are not related to UI design. Now let's talk about the last part of that section. Roger Wright wrote: There ought to be a single point of control for the data access, a separate layer that is common to all functions. Yes, that and many other Software Design Patterns are already common knowledge. This statement can only have us conclude that you are not yet studied enough in design and patterns to understand the solutions to these problems. Furthermore trying to cover all that ground in an internet forum reply is not an appropriate reaction. My advice is that you stop development and continue with your studies of design and patterns. As you learn well known design principles and patterns you will recognize some of them as solutions to your current problems. Well at least that's how it works for me. ;) In case you have not seen these folks ( there are many others as well) here is where they share their expertise: Martin Fowler[^] Ward Cunningham[^]

CrimeanTurtle2008 wrote: I am very confused about this. Then you need to be reading materials on the subjects rather than posting things in internet forums. I guarantee your progress will be like 10 fold faster. :-D