Design and Architecture

In that case i feel it depends on the nature of the class The constructor approach should be used if: - Class A is logically a component of class B (e.g. A = Engine, B = car), although in this case i would prefer an instance of class A within the state of class B rather than copies of its state values being placed into the state values of class B - The information in class A is (in part) mandatory for the creation of class B The instance method approach should be used if: - The logical functionality of the entity represented by class B is such that it would be expected to replace its state with that of class A (e.g. A = location, B = car, B.DriveTo(A) sets common 'lat/long' properties) The static method should be used in other cases Thats my view at least :D

Have to disagree I'm afraid. Software that 'works' is not good enough. Good software meets the following criteria - Performs its function with minimal bugs - Code Easy to understand by any average developer that may work on it in the future (if advanced techiniques are used that the average developer would not understand they should be commented to at least provide a jumping off point to learn that technique) - Designed in such a way that changes to requirements can be applied with minimal impact (loose coupling) - Designed in such a way that any single modification need only be made in a single location (DRY principle) - Designed in such a way that any fairly generic bit of functionality can be re-used without too much hassle - Exhibits reasonable performance in terms of speed and memory usage (according to requirements) - Future proof to a fair degree (in terms of scalability and according to requirements) and thats not to mention the little nuances such as naming conventions and comment styles

I generally go with whatever is more readable (if its a long string and i use it inline then it pushes the rest of the method off the screen) and easiest to debug. One thing to consider though, if you have a string that is potentially being declared inline then that string is a constant, why not make it a constant? As part of my 'final tidyup' i generally go through my code looking for " characters and numbers, if i find any i ask myself why they aren't constant, 9 times out of 10 they should be :D

Seems a fair way to go about it, but as a pondering point, might i propose an alternative: Strategy pattern have a single concrete MSWord class that calls out to strategies for each 'area' of logic (e.g. Import strategy, export strategy, gui embedding strategy, etc) Then provide strategy classes for each variation of each logic area Wrap the whole thing up in a factory pattern which decides which strategies to stick into the MSWord class when it is created. The advantage of this is that its more flexible should microsoft ever decide to revert functionality (so that, say version 3 has the same functionality as version 1 in some logical area but different from version 2) hope that makes sense

I am an almost religious advocate of the DRY principle (I have broken it a few times but either through extreme need or the decision wasn't mine to make.. and believe me, in that case, i fought it bitterly) In my experience, there are a LOT of developers out there happy to throw the DRY principle away and they cite the following excuses: - Time constraints - Budget constraints - Too high impact on existing (flawed) design - Inexperience (excuse usually given by someone else on their behalf) Personally i find i generally design a system in my head, then as I'm coding it spot areas where I'm in danger of breaching the DRY principle and, in rooting these out, a better design surfaces. I guess there are two types of developer, the first measures their success in designing and building an application by the elegance of the end design and its adherence to good coding practice, the second measures their success by meeting performance targets. I have worked in environments where some developers were bringing in unmaintainable messes early and under budget and were praised by the PHBs as examples for the rest of us coders (scraping by the budgets with elegant solutions) Sloppy coding can give you a short-term gain, but its gonna bite you in the arse eventually IsRanting = false; ;P

Do not cross post. You've already asked this question in C# forum. Please have patience while someone answers your question there.

Mycroft Holmes wrote: f***ing ETL, whoever put the transform in ETL should be taken out and shot. LOL, Tell us how you really feel :) Not that I disagree, the tools I've seen in action make Access loook like a rockstar (tibco and something from oracle) Common sense is admitting there is cause and effect and that you can exert some control over what you understand.

Member 3906718 wrote: call to the windows function ExitWindowsEx. Restarting the machine? From a command prompt (or using [Windows-Key]-[R] to launch the "run" dialog) shutdown /s /t 0 /f Bastard Programmer from Hell :suss:

Oh no, stupidity sucks!!!! I know a top seo if by any chance you'll be looking for one just message me.thanks! Topseos and Topseos and Topseos and Topseos and Topseos and Topseos

Rephrasing to be sure that I understand the question. You have a class A which takes a set of parameters. You have a class B which produces a set of parameters. You want ideas on how to move the data from B to A. If that is your question... You use another class which contains the parameters. Call it C. Class B creates an instance of C and returns it. Then that is passed to A. In terms of implementation of C there are various ways to do it depending on exactly what the parameters consist of. The easiest is to just use properties. A more complex implementation would use a Dictionary. A Dictionary can be used to implement a multi-level structure as well.

capsulez wrote: secret people keep hiding even from other Nope. You can buy many books that show you how to paint. But that will not make you an artist. The difference - experience. And there is no way to teach it. Probably because it requires a great deal of knowledge. And often just patterns of thinking (not programming patterns) which one learns over time on how to learn/solve new problems. But it does in fact help to just try. Even if you fail. capsulez wrote: moreover i lost all data of this project because of my brother accidentally format the hard drive . You should learn about source control AND backups then. You use both. They complement each other and help to insure that loses are minimized.

Mediator use isn't strictly mandated to achieve the same thing. Some alternatives - Pass an interface. - Refactor discoved common code into its own grouping.

That's what he gives as a reason, but IMHO he just wants to put his mark on the team/company. V.

A better solution would be to setup a mirror server in India which gets (and sends) a backup every night to the uk server. In this case the uk-server should be the master and the India-server slave. We used a similar principle on a previous assigment and that worked quite well. This still ensures that you have the latest sources and can use the benefits of VSS, but keeps it all structured.

THAT is what I was searching for - +5 & a big thank you regards Torsten I never finish anyth...

I completely agree with you and know where you are coming from. I too 'back in the day' enjoyed every day. Today is a bit different though. We use to be able to learn a language and be pretty sure that we could compete for 5 to 10 years and we could master our craft. Today sadly it is not the same IMHO. Everyday MS gives us 14 new things that we MUST learn... **RANT OVERTED** I have loved everyday of my life as a developer/architect for the past 25+ years. I have no intention of changing just trying to get a feel for where to bet my training time over the next 10. Thanks JD

Thats's great. Thank you for the post!

Leslie Sanford wrote: I was wondering what the best practises are for stored procedures. Basically, I'm still struggling with a kind of code explosion that occurs when writing code that's related to the database. In the end, what I need to do is move data into and out of the database while sometimes performing transformations and doing error checking along the way. I've found over and over again that it takes a lot of code to do this. Learn to use existing frameworks. Dynamic ones or generated static ones. Database code is often something that is very amenable to those types of implementations. Myself I have been write database layer code generators for years. Additionally other common functionality is easily assigned into the same layer generation types. For example one can generate field generation code that validates such things a existence, length and even pattern for use in things such as GUI code. Some of this is something that you are more likely to gain an advantage by learning to write your own code generators. Leslie Sanford wrote: I'm curious if stored procedures are a good way to abstract out of code such things as queries, inserts, updates, etc., and move them into the database itself. Yes. For the same reason that one create any layer code - to abstract the user from the implementation. Leslie Sanford wrote: I'm finding that database programming is largely procedureal in nature, so I'm not finding my experience with Object Oriented programming and patterns to be of much use. Relational databases have a very long and successful history. For a reason. So avoid the inclination to even attempt to make it OO. There are in fact ways to do that and it is unlikely that it will lead to positive versus negative results. You start with a data model. Then you use stored procs and the database layer to translate the relational model into an OO model. Just as you do with any other translational layer. As a final note don't get to wrapped up in where the "best" place is for business logic. As an example don't avoid uniqueness keys in the database simply because that is expressed as a business rule. The database can implement that just as well, and probably better for standard business cases, versus attempting it in the database layer.

Thx