|
|
To design a UX-UI website:
1) Recognize the problems that your users face.
2) Write user stories
3) Create a list of interfaces
4) Determine design trends
5) Establish a prototype
|
|
|
|
|
I have a class A whose instances contain a few class B's, and a few class C's. The objects are all constructed from database records, one record representing a single A, B or C. The objects are read from the database and created at application startup.
The problem is that I can't decide between different instance creation strategies.
-- Should I call a single method of class A, and have A construct all of its contained B's and C's?
-- Should I have a separate factory class construct all three classes and set which objects are contained by which other objects?
-- Or maybe a factory class that constructs A, and in turn A constructs its B's and C's?
Which pattern is most preferred? Perhaps one I haven't mentioned?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I tend towards "builder" classes: static classes with static methods that construct these "object graphs" (that reside in memory / data class / repository). And may also serialize and deserialize them. They often run async.
Sometimes I build top down; sometimes bottom up (summing). "Adapters" let me step "outside the box" instead of thinking "how can I build 'myself'".
I sort of patterned it after the .NET table adapter and the concept of the "fill" method (which in that case fills tables and data sets).
(So: "option 2")
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
modified 17-May-23 23:56pm.
|
|
|
|
|
Thanks for the reply, Gerry. What's the theory behind your preference? Is there one, or do you just like to do it that way?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Some of the object graphs I build contain thousands of entries; and 4 levels deep.
I'm wiring up a hierarchy. There is no container; the hierarchy is an illusion; what "level" should build the tree?
An "adapter" builds the tree (a recursive structure of entities imported from a csv type text file; then serialized to binary).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I agree here; the static factory has the advantage that you can easily track and modify the way an object is created. Instead of modifying a lot of new This() and new That(A, B) statements, you have a BuildA(). And you can modify the behavior's of all BuildA's at a single point.
To make a short story longer, a practical example is adding a logger in a factory;
A short tale on two patterns that live in .NET[^] 
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Richard Andrew x64 wrote: few class B's, and a few class C's...Which pattern is most preferred?
Unless there is more information than what you posted then you are spending time on something that is not worth spending time on. Any way that you do it is going to be sufficient.
|
|
|
|
|
jschell wrote: you are spending time on something that is not worth spending time on
I understand this point. One solution I told myself was to pick the way that I think I can do it with the fewest difficulties.
I thought I would post the question because it is one that I have quite often, and I'm wondering if there's a best practice. So the question is not really a waste of time.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
We are working on a Java dashboard app with different charts using React JS.Can you guys please suggest best library to use. Can we use any reporting tool like BIRT, Jasper Reports, Pentaho etc with React JS? Please suggest if we can use react based libraries like Recharts,React Chart JS 2 or Bizcharts? Which approach is better? Need to make REST API calls also from UI.
|
|
|
|
|
That question is way too broad.
Can you use libraries - yes.
Which one is best - that is why they hire architects to understand the domain, to design the enterprise, to determine needs, to research existing solutions and then to design features.
|
|
|
|
|
Any know of a framework for updating apps? It must meet the following requirements:
- The system must be controllable from the server side.
- The system must allow for mandatory updates (stopping the user from using it until updated).
- The system must allow Line2 to set a grace period for updates (allowing a given amount of time or usage before the update becomes mandatory).
- The system must allow for optional updates.
I have looked at NetSparkle and Windows.Squirrel, and the both don't seem to have any way to force the update. They allow you to check for and trigger an update, but it's not enforced.
One option we're considering is placing a manifest file on the server, downloading that first, then determining the update type based off that.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: The system must be controllable from the server side
Not sure what that is supposed to mean.
Actually pushing from the server would be possible but only in all of the following is true
1. The client has an addressable IP. From the internet that means a public IP address.
2. The client must be running. So certainly one can never go on vacation and leave the computer off.
3. The client must be on the network. So no taking the computer somewhere with no coverage.
4. The client has software installed and running which is expecting that push request.
All of the above is why the client requests updates from a server rather than the other way around.
|
|
|
|
|
This is needs to be supported by the client software which should check with the server and then take the appropriate action, I doubt there is a framework for your client. The server should certainly maintain the state for each client ie. optional, non financial.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Hello,
I have a project to develop a classified ads website. A project has already been created but, the technologies used are obsolete.
My question is the following: if you, you deviate to make this project, what technology and what tools will you use for each step?
Knowing that the project will be online on a cloud server infomaniak.
What I have tried:
I already have an idea but, I would like to take different opinions before launching.
Thank you!
|
|
|
|
|
My first step would be to ask for more detailed requirements. And also what is the exact market space they are attempting to target.
|
|
|
|
|
Pointer to Implementation (PIMPL) pattern can help when working with a dynamic link library as it helps maintain a stable ABI at the cost of an extra indirection in almost every data access.
My question is, do you see any merit to using them in a static link library? My gut feeling is no, but maybe you can sway me.
Mircea
|
|
|
|
|
Mircea Neacsu wrote: when working with a dynamic link library as it helps maintain a stable ABI
Not the only use case but that statement sounds like protectionism intended to defeat other programmers. So basically not trusting them. So not something that I engage in.
Mircea Neacsu wrote: in a static link library
Presuming C++ the library type has nothing to do with it.
Over time and hopefully rarely one comes up with a case where there is a 'lot' of information that is needed to fully declare the functionality that a class needs. The normal idiom for doing this is to put it all in the include file. Even though there is no need for the user of the class to be exposed to all of that.
So one moves most of that extra information either into the class file itself or even uses a secondary include file (if one finds it emotionally difficult to put it in the class file) which is only included in the class file.
Using an actual redirect is not required. It is fluff. And probably only hurts to make maintenance more complicated. A void pointer works as well and then using it is just a cast which has no runtime impact.
And if performance is a problem with the redirect, as in an actual measurable impact rather than something that is hypothetical and unrealistic, then seems likely to me that there is something wrong with the design that lead to the class in the first place.
|
|
|
|
|
jschell wrote: Over time and hopefully rarely one comes up with a case where there is a 'lot' of information that is needed to fully declare the functionality that a class needs.
The key word here is "rarely"  . Yes, I know this "God class" anti-pattern and I agree it is something to avoid, but the situation I ran into is just mindless application of a design principle. Every class, no matter how small, had it's entrails taken out and replaced with PIPMLs.
Also, for good measure, all classes have only private or protected constructors and objects can be created only through static member factories. Of course, that means all objects live on heap, not on stack and this is again, anywhere and everywhere!
What was that saying that to a man with a hammer everything looks like a nail 
Mircea
|
|
|
|
|
Mircea Neacsu wrote: is just mindless application of a design principle. Every class, no matter how small, had it's entrails taken out and replaced with PIPMLs.
Which is wrong.
Not a unique event though. Someone, I believe on this site, years ago mentioning an application where every class was required to have an interface and factory.
Fallacy of that of course is that one then could of course insist that the factory must also have an interface and factory and that then recurses.
I have seen multiple times where people suggest that code should be written so code injection can be used at run time to load the various parts of the application. Yet they are unable to explain in realistic terms how that will in any way be cost effective.
|
|
|
|
|
A simple question with not that simple answer. Do you bind your dto classes directly to the UI (web page, rest API deserialization etc...), or you use a middle layer of object/properties between the dto and the UI?
Thanks!
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
A "DTO" be definition is a (Data Transport) "middle layer" (Object).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Data transfer objects. It's an architectural pattern in .Net Core, Java etc.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
As always, "it depends".
If the data is simple enough and the view doesn't need any additional data for other UI elements, like filling in options for a dropdown, you could get away with using the DTO's in the UI. If your UI is more complex, you'd be better off building a view model to hold the data and any additional information needed to build out the UI.
Typically, I don't use DTO's to do anything other that talk to the datasources.
|
|
|
|
|
Thanks!
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
