I've done things wrong, I confess, now I'm paying the consequences with an endless refactoring.
I'm trying to adpopt a new working paradigm.
I'll expose a concrete case, to make myself clear.
The application is about Recipes. User adds a new recipe, the application takes the information of that recipe and calculates the time it will take to cook it. Then the data is stored on a database, so you can read it again in the future.
Paradigm i've chosen so far:
1) Recipe: object to interact with the UI only has properties:
PublicProperty Ingredients as list(of Ingredient) 'Meat, potato, etc.
PublicProperty CookingWays as List(OfString) 'Frying, Roasting, etc.
2) Class to interact with the database
PublicSub Register(Rec as Recipe )
'Process that inserts the data stored in Recipe to Database
EndsubPublicFunction GetObject(Rec as Recipe, id asLong) as Recipe
'Process that fills a Recipe Instance with the data from DataBase
3) A Class Factory. I call a method of this class inserting as parameter as string and get a new object.
PublicFunction Instatiate(Recipe asString)
EndsubPublicFunction Instatiate(Recipe asString, id AsLong)
Dim rec as recipe = Instantiate("Recipe") 'New empty recipe
Persister.GetRecipe(rec, id) 'I get a recipe object filled with information from database
4) Overload methods in the Validator Class and throw an exception if something isn t correct.
PublicSub Validate(Rec as Recipe)
'Logic validation for recipe. If it doesn't pass throw exception
EndsubPublicSub Validate(Ing as Ingredient)
'Logic validation for ingredient class. If it doesn't pass throw exception
5) FormManager: this class takes "objects" (like recipes or ingredients) and depending of what we want to (insert new, modify existing) shows the form
PublicFunction Insert(Rec as Recipe) as Recipe
RecipeForm.Action = "Insert"
Dim Val asnew Validator
EndsubPublicSub Insert(Ing as Ingredient) as Recipe
IngredientForm.Action = "Insert"
Dim Val asnew Validator
Endsub'Each form is built to change its appeareance and behaviour according to the action to perform. For example sets a title like "New Recipe" or "Modify ingredient".
6) RecipeManager: it will do te magic, uses all the other classes
PublicFunction CreateRecipe AsInteger'User set the recipe, it is stored in database and returns cooking time.
Dim fac asnew Factory
Dim Rec = Fac.Instantiate("Recipe")
Dim f asnew FormManager
rec = f.Insert(Rec)
'When the form is closed if the user said:
'-"Cancel" : returns nothing.
'-"Save": Calls the Validaror class, if it's ok => returns the Recipe object with its properties.
If Rec isNothingThenExitFunctionElseDim per asnew Persister
EndSubPrivateFunction GetTime(RecipeToAnalyse as Recipe) asInteger'minutes to make the meal
'Complex process that calculate the time
Now analysing the Principles:
1) Single responsability: Okey. Every class do the thing they were made for. 2) Open Closed Principle: If I'd like to add functionality tomorrow, lets say I want to add a property to the recipe which is called ToolsNeeded. It tells you what knifes bowls or microwave you need to cook it. I could make new subclasess like:
-RecipeWithTools: Inherits Recipe and adds the property ToolsNeeded
I overload new methods to this classes:
-FormManager: Shows an extra textbox where you write the tools.
-Validator: Check object RecipeWithTools has value in the ToolsNeeded property.
-Factory: Instatiate(RecipeWithTools) and Instatiate(RecipeWithTools, id):
-Persister: adds method Register(RecipeWithTools, Select): Register(RecipeWithTools, Insert): Register(RecipeWithTools, Delete): Register(RecipeWithTools, Update)
Stays the same:
-RecipeManager: stays the same because nothing was changed in calculation function. The Create Method is called with "RecipeWithTools" String so the factory knows it has to return a RecipeWithTools. The form manager knows it must show the textBox for the ToolsNeeded. The validator knows it has to check if the objects has the ToolsNeeded.
3) Liskov Substituion: In the new derived classes i could use the Recipe class instead of the RecipeWithTools and everything would be the same.
4) Interface segregation principle: Not using interfaces here, I understand I replaced them with inheritance. ¿It's Okey?
5) Dependency inversion principle: Eh... No clue.
On the other hand I think i have three layers separated here:
Business Logic: Recipe, RecipeManager, Factory y Validator.
Data Layer: Persister
1) What do you think of the model?
2) Should I use an interface if i think that in the future RecipeManager is going to work with objects that have common things with a Recipe, but are not a recipe? If not, when would that be?
3) Can anyone explain to me how would principle 4 and 5 apply here?
It has more documentation than usual. It also shows that you put an effort into your design decisions
2) Should I use an interface if i think that in the future RecipeManager is
going to work with objects that have common things with a Recipe, but are not a
recipe? If not, when would that be?
A recipe for concrete, for instance; it is rather similar. Sand, water, cement, tweedeledeet, concrete
If the recipe-making is further expanded into a hierarchy of subtasks, you could put all kinds of generic procedures in there; ingredients can vary from resources to any raw material or tool.
4) Interface segregation principle: Not using interfaces here, I
understand I replaced them with inheritance. ¿It's Okey?
If it works for you, then yes; oke is not 'ideal', but already a better starting point that lots. I'd still recommend programming against an interface; it would give you some more flexibility during maintenance, since anything that adheres to the interface would be permissive. Do read on, since..
Really the key point of SOLID design is to properly abstract your objects. Signature and implementation should not be the same thing. There is a bit of code overhead involved, but when you find you need to scale an application you'll be grateful.
In that interest, generally you want to define interfaces and build your objects off of them. This way, if you need to add functionality later, you can build another interface to fulfill that requirement, add it to the appropriate objects, and act on that interface rather than on the objects themselves. This prevents changes from breaking functionality that worked before, and the spaghetti code that inevitably follows. Now, you can use an abstract class instead, but it's not as good a solution for exactly those reasons.That is also a large part of the point of the Interface Segregation principle, you can always add interfaces to a class and link functionality via those, rather than changing the current (working) signature. You can even add interfaces to interfaces if needs require.
The last principle, Dependency Inversion, carries the previous to its logical conclusion. Don't act on an object, act on an interface. If you need to cast something, cast it to an interface. No other class should care how an object performs a task, just that it performs it.
For instance, if I'm using a SQL server and want to switch to Mongo, my previous SqlRepository object will need to be swapped out in every place that I declared it in code with a MongoRepository. Even if I did a bulk REGEX replace on the name, potential second order effects are very likely. I might have a method or property in the SqlRepository that I didn't replicate, or that I didn't replicate with the exact same signature. This could easily break my application.
If instead I acted on IRepository, from which I implemented both SqlRepository and MongoRepository, I would not have to change any other thing in my application just because I swapped out the repository type, except, perhaps, the inject point. The interface would force me to match my signatures, and the expected input would generate the expected output. This way I add a class, change one single word in my dependency injection mechanism, and now my application uses a completely different data backend that is not even remotely compatible with the old one.
Now I know this isn't a bullet-point list of SOLID principles, but really that mnemonic is just a way to catalog all these ideas and hang a label on them. I hope it helps.
After suggestions for algorithms, products or anything else in the arena of high performance name matching.
Background - we allow our clients to upload a list of names to our systems, and then we screen those names against a list we hold on our side looking for matches. Ballpark figures are ~500K uploaded records being compared against >5M on our side.
We've currently got a couple of ways of doing this, from a Sql DB & Entity Framework (no giggling at the back), to a full on in-memory dictionary with all possible parts of every name broken out and indexed (I said no giggling).
I'm looking for high performance, high accuracy matching, and it would be nice if I could also do things like distance matching (probably using Levenstein), but the core matching needs to be as fast as possible.
I'm considering an in-memory Sql instance (not ideal), Apache Solr (not sure, never used it) etc and I was wondering if any of you had experience and could make some recommendations
C# has already designed away most of the tedium of C++.
On the various types of match, we have some rules defined around things like aliases, diminutives etc, so we could express those in a rules engine, or if I have to code this up myself, then in the C# - completely agree that if I do end up doing it myself, ordinals etc are the way to go...
I'm not really after advice on the actual matching, more the sort of infrastructure I can put around it to make it as fast as possible...to be honest, if there's something "off the shelf" that would be ideal lol...
C# has already designed away most of the tedium of C++.
A year ago I had a similar problem. We should save requests on a server and each request had an id Guid/UUID.
The solution turned out to be simple and fine. We simply wrote each cipher (in the guid) as a folder. That meant we got a folder hierarchy 32 deep with 16 branches on each level. Now one should think that it would have a terrible performance, but it actually was quite fast on linux with a solid state drive.
Another benefit was that maintenance e.g. backup was easy with this solution.
I know that I'm late to the party, but if you're just checking for the existence of the names why don't you run it against an in-memory hash array? Bootstrap it from your database and order it, then you should just have to hash the records and run a binary search with that. Rainbow tables can be used for good, as well as evil!
I am doing a project and the circuit is ready with me..
I just referred
where the programming code is given as a picture which is not clear
so I need the same programming code. please help in this
This is both a specific question about my quandary and a "philosophical" discussion about making a switch mid-project.
I'm working on a project with lots of different UI "screens"/Windows, and it's getting ridiculous to open and close the windows, as the user moves to earlier "screens". I am however a month into the project, (a few hours every week, as this is a side-project), so I'm afraid I might have to re-design and re-code too much to do the switch. (I'm sorry to say that I haven't used pages before, so I know nothing of the time it would take).
The basic requirements
This is a customer tracking program for a car-wash facility. It needs first a login "screen", which either leads directly to the "user" landing "screen", or brings up options to either open the admin "screen" or the "user" "screen". Admin is just a single "screen", that has information about the users and options, nothing complex. the "user landing screen" is a "hub" leading to "screens" doing things like:
Adding new customers
Reserving a timeslot
Perform a transaction
Looking up costumer information
with every "screen", by necessity, having multiple it's own sub-"screens".
At this point I have 7 windows, some that are on top of others, and some that replaces others. The actual code is divided around willy-nilly, (I'll have to do a clean-up before I'm releasing it). I have had some end-user tests, and it seems that it's a little bit confusing where to go, though I wasn't told that it was confusing. I had plenty of negative constructive feedback on other things, so I think they might be used to fumbling about, (Excel sheets was the previous "system" they had). However, I saw the fumbling about, and it irritated me, that I designed something that's inefficient.
Should I change it to a page-design or keep it as it is?
In general, should anybody change something like this in the middle of a project?
Please discuss, I'm not looking for some specific solution, but rather advice
Your post reads as if you are not sure of all the requirements yet? You are just coding this up as you go? If you are running into problems about the User Interface and usability it is likely you are not sure enough of your problem area. I would expect you to start having other problems with the application in time. Especially if your requirements start shifting.
If you are using WPF then you should have been using MVVM. (Or MVC in Winforms). This should allow you to reorganize the screens without too much effort. If you are going to do it, now would be the time before you've any nasty deadlines to meet.
If your users are struggling with your UI, you have to respond to that otherwise they will just revert back to their old methods - the ubiquitous spreadsheet. Again, take a step back and review all their processes to get an idea of how you should structure the UI.
Get feedback by drawing diagrams of the screens you envisage, perhaps with annotations of validations etc. Then prototype the screens using mocking to provide dummy data. Then deliver the final thing. Something like that ...
Part of this mess is that I keep getting "oh, and could we get this feature"-messages. This all started as just a more "visual" way record information. Also the Excel approach lead to a few situations where a day's or week's worth of records were deleted, having a UI that is "layer 8 proof" is simple enough, tacking on a lot of "stuff", though simple in a website, in desktop development, it's maybe not more difficult, but it isn't the same thing.
I'm basically doing this as a favor, so time isn't critical. or I wouldn't be asking questions, but rather just make a messy program, and do an "update" after having re-done it in some other way.
Since my field of expertise is mostly web-related, the methodology of desktop application development isn't something I've really studied. And so MVVM isn't something I've seen as anything more than the separation of the UI dev team and back-end functionality dev team, and therefore not something a single programmer should focus on, (I might have to spend some time on the Microsoft Virtual Academy or similar).
I have been trying to get feedback on sample layouts and I've requested drawings of what they envision, but it is kinda like that The Outmeal comic about web-design: How a web design goes to hell.
I think I'll redo it all, and make it more MVVM, or at least move everything away from the "code behind", so I make it usable regardless of how I do the UI in the end.
Keep in mind that it is sometimes easier to run multiple instances of an app than to create a "multi-window" app that meets a given user's "multi-tasking" requirements.
It does seems though that you need to spend more time with the user "while" you are developing your app (incremental development with a feedback loop) instead of waiting to be "surprised" by the user's response to your app later on.
I wish I could spend more time with the users. And the couple of times I have been by, it's like they are in presence of a god, (I'm not kidding, you'd think they had seen magic each time I've brought a new iteration of the program), they keep telling me "this is great" and "you do what you feel is the best", so I'm tempted to make it as a console application just to get some actual feedback.
What do you do when nobody has any idea of what they want except in terms of functionality, (and they keep tagging on new requirements)?
But that is our job ... take "functional requirements" and translate them into a workable solution; which could be a combination of manual and automated procedure.
There will always be new requirements; you simply assign them a priority and catalog them while working on the core requirements. If the original analysis was performed correctly, you will have a core functionality around which you build. If a "new" requirement comes along that causes you to rethink your "core", then the original analysis / design missed its mark.
I find that when I truly understand the user's requirements and write the software in such a way that "I" would be pleased to use it, the user's response to the product has always been positive. One still needs to go back to the user at regular intervals to demo the product and get feedback. And if you cannot demo something new at least once a week, then the problem has not been partitioned properly.
Last Visit: 31-Dec-99 18:00 Last Update: 8-Oct-15 12:24