|
I think it might be worth pointing out that there is a format where you don't need to play the plain-text document games. You can use BSON constructs to bridge these concerns, such as is used in:
LiteDB - A .NET NoSQL Document Store in a single data file
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Vunic wrote: This document works like an accumulator. For example, lets assume a requirement like this :
I need to store all the users taking part in discussions in CodeProject.
So, I need to capture the User ID & have a counter against each of them.
Your requirements are incomplete.
What happens when a user is deleted?
What happens if the requirements change and now statistics on two different sequences (monthly and weekly) are needed?
This has the current stats but what if someone wants to compare the states from last year to today?
|
|
|
|
|
I have a WPF app. In it there are Companies. Companies can be of different types. For example, there are Builders, Lumber Companies, Electricians, etc. Some of the companies, like Builders, will be loaded into a Navigation bar on app startup. So I need to be able to query companies for those that are builders.
However, One thing I'd like to do is to allow the user to Add/Edit/Remove company types as they see fit. This presents a problem: How do you allow the user to maintain a lookup table of company types, yet in the code determine which are of a certain type?
One possibility is to use the following lookup table structure:
CREATE TABLE Lookups
(
Id INT NOT NULL IDENTITY PRIMARY KEY,
Caption VARCHAR(MAX) NOT NULL,
Category VARCHAR(MAX) NOT NULL,
AppCode VARCHAR(MAX) NULL,
[Description] VARCHAR(MAX),
IsSystem BIT
)
If a Company Type is required for the app to run, then set IsSystem to true and provide an AppCode like "company_type_builder".
This would allow me to query for companies that have their type set to that Lookup Id. The lookup types that are set as IsSystem cannot be removed by the user.
If I decide not to use a lookup table and make the company type fixed in code, then an enum would suffice.
What are your thoughts on this?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
modified 28-Nov-17 12:57pm.
|
|
|
|
|
If the user needs to add/edit/remove company types, then you have to use a lookup table. An enum is hard-coded, and whilst it can store values that aren't defined, they will only ever show as numbers.
Rather than having undeletable types, why not have a flag indicating whether the type should be shown on the navigation bar? That way, you give the user more control over the application.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I'm curious, do you use varchar(MAX) for every text field?
And I can't improve on Richards answer 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
In this case yes. Once I get further into the design I may make the field sizes more fixed. For now I don't really know how big these fields need to be.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I studied the design patterns book written by the Gang of Four when it first hit the shelves in the mid 1990's and I have referred to it and used patterns on only a few occasions since then. It never really caught on with me and became an automatic go-to while I'm at the design stage.
Do you use design patterns on a regular basis?
In your view, has it fallen out of favor in the industry?
If you use patterns regularly, do you have a source or sources of new patterns?
TIA
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
MikeTheFid wrote: Do you use design patterns on a regular basis?
Yes, and you probably do too. People tend to forget that a design pattern is just a formal name and description of a solution to a problem that crops up frequently. It's a convenient shortcut for conveying a solution to the problem; it's quicker to say "use a factory" than to describe how a factory works - but ultimately you would end up writing the same code.MikeTheFid wrote: In your view, has it fallen out of favor in the industry?
Nope. As evidence, I would point to Angular (which uses MVVM heavily) and ASP MVC (the clue is in the name).MikeTheFid wrote: If you use patterns regularly, do you have a source or sources of new patterns?
Code Project, GoF, articles, peers and many, many other sources.
This space for rent
|
|
|
|
|
MikeTheFid wrote: In your view, has it fallen out of favor in the industry?
You'll find patterns throughout the .NET framework, from strategy to decorators.
MikeTheFid wrote: If you use patterns regularly, do you have a source or sources of new patterns?
There is no single authority, so you'd always have multiple sources. If you have the patience, then YouTube is an option. I prefer books, like Manning | SOA Patterns[^] 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
The "patterns" are out there and are being used; whether the "users" realize it or not.
What did NOT happen, was that we'd all be sitting around "talking patterns" (like architects talking about "flying butresses" and the like).
The odds of finding 2 people in the same room who CAN talk patterns is zero.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: The odds of finding 2 people in the same room who CAN talk patterns is zero.
I would not state that during an interview
At Cadac (previous employer) there's an architect that will take over the whiteboard and start explaining how the group of devs is going to build an application; it is assumed that everyone is at least up to date on the most used patterns. You're a developer, after all, and the factory, singleton or decorator aren't a new idea.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
That was ONE person doing the "talking" ... "previously".
And most "architects" rarely "implement"; they usually impede.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: That was ONE person doing the "talking" ... "previously".
The way you phrase that so carefully makes me feel uneasy, and I have no clue why 
Gerry Schmitz wrote:
And most "architects" rarely "implement"; they usually impede.
That's the task of the manager, not the architect.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: You're a developer, after all, and the factory, singleton or decorator aren't a new idea.
Yes, but does that really relate to what GoF defines?
Following is the GoF definition for "Factory Method" (there is no "Factory").
"Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiations to subclasses."
Lets look at "Abstract Factory". The GoF definition.
"Provide an interface for creating families of related or dependent objects without specifying their concrete classes."
When you and/or the Architect says 'Factory' in a design discussion is the idea that it will follow, exactly, the first definition above?
If it helps note that the GoF also says the following about a "Factory Method"
Use the Factory Method pattern when
- a class can't anticipate the class of objects it must create
- a class wants its subclasses to specify the objects it creates
- classes delegate responsibility to one of several helper subclasses and you want to localize the knowledge of which helper subclass is the delegate.
As for myself I am rather certain I follow neither. I expect that I use "Factory" to mean what GoF documents in the "Factory Method" to be 'ConcreteCreator' and I might use "Abstract Factory" in implementation (if I use it at all) as something that more closely resembles what "Factory Method" is. But not exactly.
|
|
|
|
|
jschell wrote:
Yes, but does that really relate to what GoF defines?
I'd seriously wouldn't know, I don't go there often
jschell wrote:
When you and/or the Architect says 'Factory' in a design discussion is the idea that it will follow, exactly, the first definition above?
No, just the generic idea, otherwise he would specify exactly what the requirements are. If he doesn't, then it is up to the developer to choose the most appropriate solution - which usually means going for the simplest thing possible (whilst still only returning an interface).
..but when in doubt, simply ask 
jschell wrote: As for myself I am rather certain I follow neither. I expect that I use "Factory" to mean what GoF documents in the "Factory Method" to be 'ConcreteCreator' and I might use "Abstract Factory" in implementation (if I use it at all) as something that more closely resembles what "Factory Method" is. But not exactly.
Depends heavily on what is required; do you want a static factory, a singleton, or would you prefer an object? If it has to be combined with an object-manager pattern, then I'd think that the object is preferred. Do you want one object, or do you want multiple objects? In the first case, all objects created in the factory will be available over the manager globally. In the second case, only those objects are available that the specific factory created (in that thread).
Point is, you don't want to explain how a "single point of creation in code" can save you from having to update a 1000 references in code where there's normally a "new"-keyword. That's the problem that a factory solves, with the trade-off that one introduces a tiny bit of overhead (in terms of execution).
It is not just something you learn to impress during the interview, they're simply descriptions of a way to solve something. Lots of "developers" here would struggle with a undo/redo pattern, while others simply request a memento-pattern.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
All true, but in terms of the OP the specifics of what is in GoF doesn't seem to really have been all that useful useful.
|
|
|
|
|
Seems like a collection of formalized descriptions of some common patterns, but without much explanation.
I don't think the website is meant as a source to learn those patterns; that is what their book is for
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Seems like a collection of formalized descriptions of some common patterns, but without much explanation.
Ok, but I was actually referencing the book. The copy of the book sits on my shelf above my computer. Been there for years.
|
|
|
|
|
Quote: The "patterns" are out there and are being used; whether the "users" realize it or not.
Patterns like the "copy/paste"- pattern and the "do it fast and Dirty"- pattern 
|
|
|
|
|
Or brain patterns: scales; fretboards.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
As has been amply pointed out, people do use code libs whose structure is based on the instantiation of design patterns whether they know it or not.
My question was more about "do you use patterns," but I get and agree with your point.
Once one has an understanding of the more common patterns, one starts to see them everywhere; kind of like buying a make and model of car you've never owned before and then suddenly seeing them on the road everywhere.
Thank you to those who responded. You have been helpful and have convinced me it's time to reacquaint myself with the subject. I also appreciate the links.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
MikeTheFid wrote: I have referred to it and used patterns on only a few occasions since then. It never really caught on with me and became an automatic go-to while I'm at the design stage.
Because the reality is that most of those patterns have little usage in the vast mess that is implementation.
Not to mention of course that singleton, which is the only one used a lot, tends to be used incorrectly a lot as well. So that didn't help much.
MikeTheFid wrote: Do you use design patterns on a regular basis?
In the generic sense, not the book, yes.
MikeTheFid wrote: If you use patterns regularly, do you have a source or sources of new patterns?
My head. And not as rigorously as GoF defines it.
I looked at several of the follow on books to the GoF and found that most were really struggling to find patterns. That along with how seldom I had seen (even then) most of the patterns in the GoF didn't really bode well. Further experience seems to have supported my determination that although the idea was valid it just wasn't prevalent enough to attempt to normalize it.
|
|
|
|
|
jschell wrote: Not to mention of course that singleton, which is the only one used a lot
The decorator is used throughout the .NET framework (streams), as well as the command-pattern, factories (DbFactory, ThreadFactory), strategy-patterns, object-managers..
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: The decorator is used throughout the .NET framework (streams),
Yes I stand corrected. It is used in other frameworks and languages as well. Perhaps percentage wise used more correctly as well.
|
|
|
|
|
Hi All,
I want to create software for education like wordshark and numbershark but not sure what language to use java or C#
Thanks for your help
Ch
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
