|
Julia4u wrote: You should work in a petrol station. You don't even know how to communicate with ladies.
You don't even know how to act like one.
Julia4u wrote: Stop being on Code Project all the time and doing nothing....
How would you know this unless you're on Code Project and doing nothing by simply watching them?
Julia4u wrote: Seriously telling you all do not come in front of me ever because my first reaction would be a tight slap on your face.
Yeah, all the real ladies I know get violent at a moment's notice.  Oh wait, there is that other type too that does get violent quickly... I call them bitches.
Julia4u wrote: Good Bye Code Project and stupid loners.
I'm gonna go tell my girlfriend I'm a loner; I wonder if she'll agree with you.
|
|
|
|
|
Nice one there Mr Falcon. Made me chuckle. 
|
|
|
|
|
Why thank you Mr. O'Hanlon. :bow:
|
|
|
|
|
How are you doing there good sir? Haven't heard from you in a while.
|
|
|
|
|
Pete O'Hanlon wrote: Haven't heard from you in a while.
Yeah, I've been playing CP hooky. I've been hanging out on the Trugger list though, which has a few select CPians on it to get my fix however.
Pete O'Hanlon wrote: How are you doing there good sir?
Short story is broke. Less short story is, broke but I'm doing something about it.  What's going on in thine neck o' thy woods?
|
|
|
|
|
Jeremy Falcon wrote: I've been hanging out on the Trugger list though
Trugger? Don't think I know that one - I'll have to look into it.
Jeremy Falcon wrote: What's going on in thine neck o' thy woods?
Just been spending too much money. This week has seen birthdays for the wife and the daughters and my wedding anniversary.
Jeremy Falcon wrote: Less short story is, broke but I'm doing something about it.
Excellent. That's good to hear.
|
|
|
|
|
That's very lady-like of you.
So the creationist says: Everything must have a designer. God designed everything.
I say: Why is God the only exception? Why not make the "designs" (like man) exceptions and make God a creation of man?
|
|
|
|
|
I'm on a project where I'm designing an extremely graphical and highly interactive application that interfaces with legacy applications. Right now I'm putting together a detailed design document for other developers to review.
I got into a discussion with other developers where I asserted some statements that, on the surface, don't make too much sense, but I still think are true. Specifically, "Although we agree that good design might be necessary for good code to be produced, good code is necessary for good design to be produced as well".
In other words, you can write up a design that looks good on paper and matches all the requirements, but until you've physically coded this design (or something very similar to this design), it's hard to say for sure that the design was really all that good.
As smart as we might be, the cold reality is that no one is smart enough to make an initial design up front for a complex application until they've actually built something similar to verify that the design was, indeed, a good design. Just about any design can look good on paper to an entire review committee, but only designs that are based off past successful implementations of similar ideas can really be confidently considered "good".
Has anyone else ever been forced to come to this conclusion before?
|
|
|
|
|
jesarg wrote: Has anyone else ever been forced to come to this conclusion before?
Yup. Part of the biggest challenges when designing an application is being flexible and open to the fact that the code phase will result in your design being revisited and updated. Anybody who thinks that the design is finished before the code is doesn't really understand the dynamics of a software project. Effectively you can view this design phase as:
Design what you want it to be
Code it to be what it is
Update the design to say what it is
Or to put it another way - the simple fact of coding an application will throw up issues that the designer just didn't think of which will result in the design being updated.
As a final thought - you've done your design. You've done your development and now you're ready to show it to the client (assuming you haven't developed it using RAD). They come in, love the product but want one or two "minor" changes - the design will change. So don't think you've finished with the design.
|
|
|
|
|
jesarg wrote: As smart as we might be, the cold reality is that no one is smart enough to make an initial design up front for a complex application until they've actually built something similar to verify that the design was, indeed, a good design. Just about any design can look good on paper to an entire review committee, but only designs that are based off past successful implementations of similar ideas can really be confidently considered "good".
Has anyone else ever been forced to come to this conclusion before?
That's happened to me in nearly every project that I've worked on, and so far, the only consistent design principle that seems to make the most sense is to keep it simple. Good design comes from continuous refactoring, and by the end of a project, a lot of my designs tend to be emergent rather than something intentional. More often than not, I usually prototype my ideas using standard structured programming techniques (without using any OOP mechanics, such as inheritance).
At first, the idea starts of as a very long and ugly static method in a single class, and then I usually use Fowler's classic Refactoring techniques to cut the size of the method down until it's broken down into static methods. At that point, it's still fairly useless since my code is still written to work with a particular prototype case, so the next thing I do is I refactor the static methods into interface dependencies and move the static implementations over to classes that serve as default implementations of those particular interfaces. The idea is to take the most straightforward approach to writing an application, and then refactor and generalize it so that you can extend it. TDD takes the same approach with its "test first" mantra, and this style of development has yet to fail me. (BTW if you want to look at some samples of my design work, click here.[^])
Now that I think about it, writing good code and having good design principles is like trying to sculpt a melting ice block in the middle of the desert. If you spend too much time thinking about what the design should look like, you'll end up with nothing but a puddle of water. If, on the other hand, you know exactly what you need to chip away in order for the ice sculpture to take shape, then all you have to do is constantly reshape it until the sculpture emerges from the ice block, and hopefully you can get it done before the ice melts...
|
|
|
|
|
jesarg wrote: "Although we agree that good design might be necessary for good code to be produced, good code is necessary for good design to be produced as well".
"A chain is only as strong as its weakest link."
|
|
|
|
|
I've been going around in circles trying to design a new toolkit to create a certain kind of application with. What I think I'm realizing is that it's sometimes best to design classes in such a way so that they make the fewest assumptions about the environment in which they will be used.
What this means from a design standpoint is that when designing a class to represent a specific concept, you do so in isolation; you make the class as cohesive as possible as a standalone entity.
So where do you go once you have your finely crafted class? How do you integrate it into a context in which you are working?
I think the adapter design pattern is the answer. Adapt the class so that it's interface is fitted to the rest of the application.
This is a kind of bottom-up approach. And it may not seem sensible at first. But I have repeatedly found myself getting entangled in too many details when I try to consider the overall picture when designing a specific class. I'm having better luck designing classes so that they make sense on their own without any scafolding to support them. I leave the other details for later.
|
|
|
|
|
In situations like this, I would tend to look at using something like Test Driven Development and Inversion of Control and not actually design my classes in isolation - this is just acting for trouble.
|
|
|
|
|
Pete O'Hanlon wrote: In situations like this, I would tend to look at using something like Test Driven Development and Inversion of Control and not actually design my classes in isolation - this is just acting for trouble.
Thanks, I've never given TDD a very close look.
I agree that designing in isolation is not a good approach generally speaking. It may be that what I'm learning, though, is that if you have a set of low-level classes, it may be better if you can design them to make the fewest assumptions possible about the higher-level classes that will use them. Kind of postponing dealing with certain details for as long as possible. This may help reuse.
What I'm struggling with is keeping higher level policies from getting entangled with the low-level algorithms that do the work.
Anyway, just thinking out loud.
|
|
|
|
|
What I'm struggling with is keeping higher level policies from getting entangled with the low-level algorithms that do the work.
if higher level polices are dependent on low-level algorithm and if low-level algorithm are changing...or if you want to make higher level polices independent of low-level algorithm then go for Strategy or Template Method.
|
|
|
|
|
I am looking for componet library in C# vb.net for grnral business development.
All pointers will be appreciated.
Tapas Shome
System Software Engineer
Keen Computer Solutions
1408 Erin Street
Winnipeg, Manitoba
Canada R3E 2S8
http://www.keencomputer.com
|
|
|
|
|
Take a look at Rocky Lhotka's CSLA toolkit.
|
|
|
|
|
Is there any good documentation, except his books, on that? I built my first (and only) nation wide client server system based on the original CSLA, from the "VB6 Business Objects" book. I came short with child objects having child objects, but he has long since addressed that, and I am more than willing to give CSLA a try.
Pits fall into Chuck Norris.
|
|
|
|
|
He keeps his website up to date - has a very active forum on it, and (if you use CodeSmith) you can get fairly up to date CSLA templates to generate your code.
|
|
|
|
|
Hi,
Anybody please help me with this issue,
i am having two list views. Both these are having scroll bars.
What i want is that, i have to make only one scroll bar for both the listviews, so that if i am scrolling the scroll bar of the first listview, both should get scrolled...
i have seen in one application that its possible, that is not in c#, its purely VC++.
So please i need a help for this.
Thanks in Advance,
Roger 
|
|
|
|
|
|
|
|
Pete O'Hanlon wrote: The C# forum.
And if that doesn't work, you can go here[^].
|
|
|
|
|
As in I have always worked on CRUD systems. I have googled for a list of systems but haven't been able to find much. I guess i'm just getting bored of the usual n-tier front end to a DB stuff, and want to know what else is going on.
Any help much appreciated.
Cheers.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
