|
I would assume he already has client isolation already in his current, simple, search.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Hello,
It's same for 'inputs',
get if the type is good, and so the length,
for a enhanced search : history ( by client ?? ) or 'workers background' ( so filtering choice and Db feedback too.
If 'A' really go A*
if 'B' then 'go NOT 'A*'
modified 23-Aug-21 21:01pm.
|
|
|
|
|
How do you desired which of the architectural pattern to work with?
|
|
|
|
|
I reject the premise of the question.
|
|
|
|
|
Why rejecting what you should be able to deal with?
|
|
|
|
|
Experience and knowledge and what you have learnt about the business requirements.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
What if this is your startup and idea, and you've yet to write the business requirement? Your experience level is coming from a lot of books and youtube videos you have read and watch.
|
|
|
|
|
Tabah Baridule wrote: you've yet to write the business requirement
Then why are you thinking about architecture patterns. Get you business plan and requirements sorted and THEN start looking into what platform(s) you will service and the different patterns that will meet your requirements.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
A pattern is where you're repeating the same block of code; it is now a pattern; your pattern. The fact that no one has used it before, or named it, makes no difference.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
|
Many patterns, such as those in the GoF book, aren't "architectural". They're more tactical, although they can help to make an architecture better.
Jim Coplien, who was well-known in the C++ world, got involved with patterns early on. Later, he said that there was too much focus on patterns. The emphasis needs to be on encapsulation, polymorphism, and inheritance. Patterns are the exception when those things, by themselves, don't produce loosely coupled code.
To understand a pattern, you need to have seen what code looked like before the pattern was applied, and after. Then, when you write or find code that looks like the "before" code, you'll know how the pattern can improve it. That's usually how a pattern gets used. How code evolves to satisfy its specifications is what determines which patterns are used; it is wrong to start out by saying which patterns will be used before you have a good sense of the high-level design.
|
|
|
|
|
 Thank you, permit me to share this as a tweet.
|
|
|
|
|
|
The most correct thing previous commenters posted is that you need to handle business requirements first.
The other correct thing is that GoF patterns are mostly tactical.
Given that in my answer I'll assume is that architectural patterns are monolith, microservices, CQRS etc.
With that said I'd start from monolith application since microservices bring a lot of overhead that you might not need until you've pitched a PoC to some investors or might not need it at all if you're not going to have a team of sufficient size or your application won't endure high loads.
Then your application will evolve according to your business requirements and also to a fact that your understanding of business will evolve too.
Say you'll discover that your business problem contains of multiple subdomains. Then you can handle them via vertical slices.
Or you may need to handle spikes in application load. Then you might need to extract some microservices.
In general, my advice is to start with the simplest solution unless you're encounter requirements to act otherwise.
|
|
|
|
|
|
They're primitives; like having bones; not really something you can obsolete.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I guess the writer is correct in that specific scenario, but he has not addressed all the others.
|
|
|
|
|
- "it's not flexible", not if you consider adding an extra case to be a Big Deal, but the alternative is adding an entire new class.
- Even if you are of the opinion that creating new classes is somehow easier than creating new cases, then spend a little time thinking about what would happen when the function signature of that virtual function is changed, or if something about the API used by the subclasses to implement themselves changes. This has the annoying property that the fix you're about to write is highly non-local, you'd have to "hunt down" all the places that need to change - in the best case they correspond to compile errors.
- If a requirement is broken into N cases, but the code is spread out non-locally over N classes, your code does not look like the requirement which makes it harder to check whether it matches.
- "it's not SOLID", maybe, but SOLID is subjective and overrated.
- "horrific", let's not even talk about it.
- The presented "better way" presupposes that we have a convenient instance of the "class that represents a particular reason". How did we get that? Chances are that there's a switch hiding in a factory pattern or something. Moving the problem. And if there is some pattern such as
new AddressChanged().Update(), how about we don't wrap it in a class and just call a method that does that. - Article forgets to point out that in the first place the only domain that was considered is the business logic domain. Even if it makes sense there (which I don't agree with either), it won't make sense anywhere else. There's no way
Math.Min would have its if replaced by polymorphism.
|
|
|
|
|
swampwiz wrote: This article purports
First of course writers have different goals than programmers. Always keep that in mind when reading postings on the web.
From the link
"New requirements come along. Who would have thought? You were so sure nothing would happen"
Wrong, wrong, wrong.
Attempting to write code in case something might happen is a sure way to lead to code that is difficult to maintain.
If you already have requirements, even if it is just from a whiteboard, then your design and implementation should, of course, take that into account. But if you are claiming that you are writing your code to make it easy to add requirements that are unknown then you are at least ignorant of the challenges of maintaining legacy code. Especially if your claim is for something that might happen far in the future.
What actually ends up happening with that hubris is that code must be maintained for years or decades despite the fact that it serves no purpose. The complexity actually makes it harder, not easier, to add new features because it is more complex.
The best you can do now for such future possibilities is to write code that is easy to understand. And to make it clear how the code that you wrote now meets the requirements that you have now. Then that programmer 10 years from now who must add a feature that is actually needed then, will at least be able to understand what your code actually is doing and very likely needs to continue to do even with the new feature in place.
|
|
|
|
|
A keyword won't replace another.
Because of amount of 'features' available as new langages arrive.
Think from the core : Assembly ( or C ),
you can renew an adress , or the value, or call an adress, or a value,
so goto: leads to another 'adress' , It's go there/ do that ....
If statements are 'condition tests' area ,
you want to upgrade your style with a relevant idea,
throwing out the 'overload of logical' and the point is here : renew the keywords you use.
Like you'll have already your idea about the 'How To' :
one essential thing to get clues for relevance : measure / benchmarck / tests / and finally Compare your tries.
There are lots of 'equality' ,
if ( Evt 1 ){ ........... }{ .... }
so it's like :
while( Evt 1 ){
..............
}
while( ! Evt 1 ){
..............
}
will succeed same .. and commit the following .
It's about 'How many laps in loop' 'How many conditions to evaluate',
( or maybe a " loop/if handler " is required )
A code could use if() .. or other manner..
But in a very short and relevant time and process consumming ?
or for one hour over required work time ?
//////////
It's really 'one case' won't solve this questions',
benchmark will do !
benchmark will prove your choice as the best one.
There will never have deprecated keywords.
modified 23-Aug-21 21:01pm.
|
|
|
|
|
I can only suppose that your comment was intended for the original poster and not to me.
Member 14109043 wrote: There will never have deprecated keywords.
That might be specifically true for 'if' but in general that is not true.
|
|
|
|
|
I wouldn't label if statement as obsolete but I found dynamic polymorphism (hidden by the facade of SOLID mnemonic) pretty convenient thing in order for all OOD keywords to find their place. And indeed before entering the thread my guess was that author will make the case that if.. else.. violates the open-closed principle. And my guess was right. Although if I were the author I'd avoid such words as terrible, horrific etc
|
|
|
|
|
For example,
public void DoSomething(A a, B b, C c)
in which, many of properties of Object B b will be modified in DoSomething()
and the caller of DoSomething() will also use the changed Object B b
I would like to ask which of the following approaches is appropriate:
1) just use the B b after calling DoSomething()
public void DoSomething(A a, B b, C c)
2) Return the Object B to emphasize that B b being changed in DoSomething()
public B DoSomething(A a, B b, C c)
3) Or there is a different design of DoSomething(), that means the above method signature won't happan at all in OO world
|
|
|
|
|
I would go for the first choice. As long as the rest of your design is correct then other parts of the application will most likely rely on the b object being changed at this point.
|
|
|
|
|
You could make the method name more specific in this case: DoSomethingToB
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
