Design and Architecture

Yep, its a sister pattern to the far too common Foo/IFoo pairing. Mark Churchill Director Dunn & Churchill Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.

Ok but in such case, you won't suffer from any perf problems at all if you mark your methods/props as virtual The overhead of virtual calls is non existing when you bring html rendering and database access into the picture. Lowest of the Low wrote: In relation to your type 1 mock how would you go about using an interface when the class you are attempting to mock is unique within the app? Or am I just being dense here and you would simply replace the class interface with an explict interface and implement that in the class? Even if you do this it just 'feels' wrong having to create interfaces where a concrete class would work (from an application point of view) Well if you use them as stubs because your concrete class is not yet written (kind of the purpose of stubs) Then you would create an interface, maybe not because the app absolutely needs it in the end, but because _you_ need it to be able to continue to work before the stubbed class is actually implemented... The interfaces adds value in form of testability which make you able to develop faster and you get an app that is easier to maintain, even if they don't add much value inside the executing application itself. My Blog modified on Monday, June 9, 2008 8:01 AM

Philip Laureano wrote: If the rest of the code base changes very little, wouldn't the tests themselves be a case of YAGNI? Why not simply add the tests once you do need to change the code? As you say, if it won't change then it's pretty pointless. On the other hand, you might find a bug or two in the existing code if you add tests. My Blog

wantToLearn wrote: Is this possible at all? Yes. Deja View - the feeling that you've seen this post before. My blog | My articles

Welcome to CodeProject :beer: Take some time to look through the forum list and try to find one that more specifically matches your problem. It seems your problem has nothing to do with Design or Architecture. Many of the forums are specific to languages and/or platforms and it seems that is the problem you are dealing with, how the tab control works and perhaps the IDE you are working with. led mike

I've implemented Skipjack recently on a small micro as well as in VB. I don't have the code handy, and since it belongs to my client I really couldn't share it, but a Google search for Skipjack encryption will turn up some good stuff within a page or two (if you don't mention encryption, you'll get information about boats and other stuff). I haven't seen anything to suggest that Skipjack has been "broken", though cryptosystems that are very close to Skipjack have been. I would not recommend tampering with the internal workings of Skipjack, since such tampering is apt to make it significantly weaker. If interoperability with existing Skipjack implementations is not required, however, increasing the number of rounds to 48 (from 32) might not be a bad idea. Note that if the number of rounds is reduced at all, cryptanalytic attacks become easier than brute force. By my understanding, increasing the number of rounds to 48 would improve security (an attack on a 31-round version of Skipjack has been discovered; using only 32 rounds would seem to be cutting things rather 'close').

ruben ruvalcaba wrote: think that's exactly what I'm looking for. But now I realize the challenges for creating an extensible framework, are much more than creating the core functionallity. You're welcome. Yes, creating systems like this is possible but not simple. (I'm involved in building one at work now and it's been a very long road and a lot of work involved.) ruben ruvalcaba wrote: I'm wondering I'll need to create a lot of interfaces or abstract classes to allow the interoperabilty between the different objects We are doing things with a combination of interfaces, abstract classes, and generics from the framework layers. ruben ruvalcaba wrote: In my system there is a lot of interaction between classes, they're tight coupled and I should separate them. You should look at doing this no matter what. The more tightly coupled your objects are the harder they become to maintain. Generally you want a loosely coupled but highly cohesive system. (http://en.wikipedia.org/wiki/Coupling_(computer_science)[^]). In the long run, making sure you have a solid and well-thought-out architecture is always worth it as it leads to code that is more easily maintained and extended in the future. It all depends on where you want to spend your time/effort/money - up front in the design or afterwards in the maintenance phase. Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai [Forum Guidelines] [Articles] [Blog]

HoltDan wrote: The error handling isn't much of a concern. I simplified the example: in reality, this product gets installed at various customer sites and configuring the display strings to their specifications is something that will be part of the setup. There will be error checking and it will be done infrequently and then by 'qualified' professionals The error handling should be a concern as this can lead to all sorts of unpredicatable input which will have a considerably "higher than average" chance of breaking your application. You may also want to have a look at the IFormattable[^] interface. Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai [Forum Guidelines] [Articles] [Blog]

chain of responsibility is one possibly. for your GPSPing class so that you can add new GPS inputs easily Tim Yen

Wauna, There is a ton that can be said about design and architecture and there is no way to fully answer you question here. That being said, after reading your summary a few things strike me. 1) Can you identify entities on the spreadsheet that are, or can be, represented by objects? If so, then you may need to rethink your architecture to leverage those objects instead of a spreadhseet. 2) Don't tie the UI for data entry to the layout of the report. Or perhaps a better way of saying this is, don't assume that the method off data entry must mirror the report layout or vis versa. A spreadhseet may not only not lend itself to easy validation in a web app, but it may not be the most optimal form of data entry for your end users. Just a few thoughts, take 'em or leave 'em, but there they are.

Tristan Rhodes wrote: What would you have to do to handle commands which have parameters? Or would that be a symptom of bad design? Have a class for arguments that is a parameter to the Execute method ICommandExecutor::Execute( CommandArgs& args) led mike

Pete O'Hanlon wrote: This is the Design and Architecture forum, not the mucking around in a sh!tty VBA forum. LMAO Thanks for that early Monday morning laugh Pete! led mike

AikinX wrote: But I don't think it is fully related to a "stateless server" It is definitely fully related. In the context of "a server" the definition of "stateless" does NOT change. AikinX wrote: A server is a container for applications that are ran into the one. No. It can be but the word "server" is not limited to that. In client-server architecture "server" refers to the process that services the clients. However there is a non client-server architecture use of a server process that may not service clients at all. It may not receive requests of any kind. led mike

Hmm... strange - I've been to Bolivia, but I've never seen anyone call these monkeys "helper class" over there :rolleyes: Seriously: Of course, if "helper classes" don't exist for you (because it's not a very descriptive term, or the GOF haven't written about it, or for whatever reason), this whole discussion is pointless. We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist modified on Thursday, May 15, 2008 5:20 PM

Hi Leslie, Thanks again for your comments. I did originally want to use the Visitor pattern but I will extend the application with more elements and I think that is where the Visitor pattern falls down. I did look at another pattern, a quick search on Google tells me it was called Acyclic Visitor, however, it didn't tick all the boxes either. Regards, Adam

We tend to use exceptions based on logical areas. Deja View - the feeling that you've seen this post before. My blog | My articles

Keep the analytical data in Director. Give format to your data using Builder. Builder pattern.

That is in part because the Apache web server is licensed under the Apache license - which is not very much like the GPL at all... Mark Churchill Director Dunn & Churchill Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.