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 -
I'm old. I know stuff - JSOP
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.
Poorly considered, but it fits well within the current software engineering zeitgeist, so it makes sense that it would get written. That's the fancy way to say: "it's a fad, don't worry about it". And stop reading Uncle Bob.
"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.
I think there is no reason to calculate the Customer one more time
Err...yes that actually is a problem.
You are suggesting that you should program to convenience rather than to design. This it same ideology that leads programmers to start making base classes for everything for functional reasons and ignoring the "is a" design principle (and leading to highly coupled software as well.)
There are other ways to handle redundant functionality versus attempting to insert it in methods for convenience.
in which, many of properties of Object B b will be modified in DoSomething()
To be honest situations like this are the reason why people start bragging that OOP is a problem and you should stick to FP. I mean it's hard to reason about what the B will after it gets processed by DoSomething. The same way what A and C will become.
This is the reason why I'm a proponent of the second option but to return the copy of the input without changing the input itself. Although it seems more functional at least it tells "hey here's new B for you but in case you'll need original values you may use them as well".
Alternatively, you may go with the first option. IMO void return type tells "be prepared that input parameters may be changed unpredictably"
Last Visit: 31-Dec-99 18:00 Last Update: 14-Jun-21 10:28