|
Are there any schools of thought on whether it is better to code a new design from the top down, or the bottom up?
Top down means writing the highest level code first, then filling in the details later. Bottom up means to implement the low level code first, then tie it all together later.
Which are you more likely to choose?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
My instant reaction to this is from the bottom up, starting from the data structure, build that first and work up from there. Then I thought what about one contract that started with a one page invoice and grew down.
When I was consulting I would look for both ends at the start of a project, what have you got and what do you want. Then I would start at the database, DAL and lastly the UI and reports so I am a bottom up person.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Richard Andrew x64 wrote:
Which are you more likely to choose?
I never made a choice, and end up doing both. That's under different management-schools, different companies, different schedules.
It always starts the same; there's a problem, and it's usually something I can't solve in a single hit. So, the problem gets divided into smaller problems. Divide and conquer. It's what I did at my first job (Waterfall, Delphi) and am doing now (Agile, C#).
Planning a sprint, the problems are named. Sometimes one needs specific bottom-up functionality (often when interfacing) and we start with that - building a prototype, preferably in a test-project. Other times you need to implement an abstract idea, and you come back to fill the gaps later.
Both, constantly.
Richard Andrew x64 wrote: whether it is better to code a new design from the top down, or the bottom up?
It is better to talk and nail the problems. If one of the gaps in the app is logging, then have someone bottom-up a logger, AND someone top-down in the app in the places where the logger needs be injected, and building a factory.
Top down requires "magic dust"; you fill in the non-working gaps with that dust, and as long as you can remember the magic required, things works fine. Problem is when there's suddenly a gap you cannot fill (often with a deadline creeping nearer).
Bottom up makes stuff easy to test; you write a bit, test it. Write a bit more, test some more. Change a dot, test it to pieces.
As soon as you're coming in the vicinity of a deadline, you want to make sure that all the prototyped blocks fill the gaps nicely.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
When design in my hand I always start with the large picture.
I brake that picture into peaces around work processes from the point of user, than break down those processes to simple steps.
After that I map the steps to some that developer can understand.
After that I build the data structures.
From all that info I crate the layer map.
That's the point where I start to write actual code - bottom up...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
I like to bounce back and forth between the two. This helps me reduce the amount of impedance mismatches you run into when you finally start trying to mate everything together. Also it gives the added benefit of increasing the number of opportunities to refactor which leads to less code rot. This approach does require devs with full stack expertise.
|
|
|
|
|
There is no single, straight-forward answer to this question, as it depends entirely on the application you are building. Is it a large, enterprise application? Are the requirements / designs clearly defined? Are you using a new development technology?
For larger applications you may want to ensure you have the right architecture in place, before going into the more detailed elements. For a smaller application, using Agile / TDD you may want to get something up and running quickly and then refine it over time through unit tests and re-factoring.
There is no silver bullet here. Use your experience to see which approach feels the most sensible.
|
|
|
|
|
what are the good design pattern for a device that implementing image processing ??
|
|
|
|
|
..it doesn't work that way. Patterns aren't sorted by "device" or "application" - they're applicable in almost ANY of them.
Regardless whether you're writing an email-client on a Pi, a game in XNA, or a desktop - you probably have multiple kinds of singletons in there. You'll find the basic patterns in most applications.
You did not state what platform the image-processing is going to do. I'd recommend abusing the graphics card for that, obviously. I guess I'd first be looking for a managed version of DirectX.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hello, can you please describe a data access model for a modern, greenfield enterprise app?
Back in 2000, a Bll and Dal were created for each domain entity. Business logic was in the Bll and data access logic was in the Dal. App code would instantiate a Bll and call one of its methods which would in turn instantiate and call a method on a related Dal.
This is a proven and effective model and is still a solid fundamental model for basic applications. However, over the last 5 years, there has been increasing emphasis on design patterns like the provider pattern, inversion of control and a general emphasis on testability.
So based on all the trends that have emerged, or become more recognized or expected over the last 5 years, can you please describe the data access model that you would propose for a modern, greenfield enterprise app?
Pretend you're a principal consultant at a consulting firm and you want to demonstrate the value and sophistication that your firm can bring to the table. Please make a data access layer proposal that would help support this goal.
|
|
|
|
|
So, I take it from this that you're a principal consultant at a consulting firm, and that you want us to do your job for you. It's your job to write this proposal, not ours - after all, it's not as though you're going to pay us for something that's quite a substantial bit of work.
What is clear from your description is that you don't understand how these patterns fit together - and if you don't, how are you going to be able to justify the different parts of your design when you're challenged by the client.
|
|
|
|
|
I see that you was able to climb really hi in the last 3 years - until 3 years before all your questions were mediocre at the best...
If you got a principal consultant job by telling stories, you are in grate danger. Even someone should answer your question (no to likely, as it an article long answer), you will not understand and will not be able to present it, specially if questions will rise!
So if you do not know your job it's better move along before some dirt will stick to your name...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Member 3919049 wrote: Pretend you're a principal consultant at a consulting firm and you want to demonstrate the value and sophistication that your firm can bring to the table.
In my experience of such people they charge a lot and produce very little. Judging from your question you are well suited to the role.
|
|
|
|
|
Member 3919049 wrote: Pretend you're a principal consultant at a consulting firm and you want to demonstrate the value and sophistication that your firm can bring to the table. Please make a data access layer proposal that would help support this goal.
No Problem. We sell workshops that result in a concept for this. You can buy one if you like. I bet there are some other consultants ready to be payed here, too. 
|
|
|
|
|
Well my take is that this looks like a homework assignment.
|
|
|
|
|
Are there any alternatives to MS Access around yet?
From what I can find things like SQLLite, Firebird, SQL CE etc are fine for local usage, and the others like SQLExpress, MariaDB all require servers (or at least software installed to host them).
I can't find one that has Access's standalone ability, as our current situation is access databases on LAN/WAN shares. So if there is something that can replace that?
The clients are likely to be C# WPF.
|
|
|
|
|
cjb110 wrote: From what I can find things like SQLLite, Firebird, SQL CE etc are fine for local usage,
That's the category that Access falls in.
cjb110 wrote: I can't find one that has Access's standalone ability
If you want a database-file without a server, you'll be looking at either access, or a single-file database like SQLite. If your data is accessed by multiple people from several workstations, then you DO want a server.
There's a button in your Access-IDE that upgrades the entire database to Sql Server. Install Sql Server Express (it's free) on a PC that the users have access to.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
 Your answer is exactly what I was expecting.
We've an internal issue in that getting new virtual servers are a long and overly expensive process and brings up 'which dept pays for this' problem. So I wanted to make sure that there wasn't alternatives...
|
|
|
|
|
You're welcome
|
|
|
|
|
cjb110 wrote: I can't find one that has Access's standalone ability
CSV files? 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Per your other answer - where would you put Access if that was your solution? It would need to be somewhere all of the clients could reliably access it.
Same thing applies to a standard server database.
As for the internal management issue. Put it on a supervisors computer. No one works til that person starts up their computer. Everyone goes home or takes a vacation when that computer is off.
|
|
|
|
|
Access mdb's currently sits on various SAN locations, along side their other stuff like word and excel files.
A standard server database doesn't does it...but yea I know what you mean.
And unfortunately our various user bases are a bit big for the last idea to be feasible.
|
|
|
|
|
I see.
Maybe looking into clustering with embedded databases???
Not sure that is even feasible given that generally embedded would be one client but there might be one or two out there that supports that.
|
|
|
|
|
|
Please describe in brief. It was asked during one of my interviews.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
