10
Splitting a big class into smaller classes is primarily about separation of concerns. When the independent concerns (some prefer to reflect in terms of “reason to change”) are well identified then only can you reasonably decide about inheritance vs. composition.
The core question is: didn’t we accidentally during the growth period put together too many ...
8
Inheritance can be used as a tool to refactor out a new, smaller base class Bar from Foo, which can be tested, managed or used independently from its derivation. Moreover, it is a tool which allows to write more generalized code in terms of Bar, which is especially useful when there is more than one derived class (but which seems not to applicable to your ...
6
You don't need AdcDriver at all. It does nothing. AdcInt and AdcExt both expose the same interface.
If you want to have an object that accepts AdxInt or AdcExt based on runtime information, you will need virtual somewhere. If not, you can use a simpler template.
class AdcInt
{
public:
float getValue(Input input)
{
// ... implementation ...
5
A chain is a sequence of events that gets the process to the end of the chain. (done)
Each link just passes on to the next link, so a dictionary isn't really needed in that case.
One could certainly create an array/list/dictionary of generic command objects and then have an orchestrator run them.
orchestrator.run(commands)
A dictionary might be needed if ...
5
It seems that there is no room for specifying toppings
The pizza factory from the post you linked is built on the assumption that types of pizza are known and set in stone at compile time. This means that you cannot (at runtime) ask for extra/removed toppings, because that violates the basic premise that a pizza's toppings are defined purely by its concrete ...
5
Are there considerations in choosing to write a class that has one method that acts on its parameters vs writing a class that instead takes the same parameters in the constructor and the methods acts on its fields?
There are two main reasons you'd abstract it away in a class:
Reusability, i.e. you want to use this sublogic in other classes as well
...
4
What about a response object, that contains a boolean indicating validity, and an optional reason string? This way you don't need to worry about looking up enum codes, because the reason is contained within the response object.
public Response validate(Thing thing) {
Response r = new Response();
if (thing.a != "a") {
r.valid = false;...
answered Feb 18 at 18:55
FrustratedWithFormsDesigner
44.8k7 gold badges121 silver badges173 bronze badges
3
This is a misunderstanding of the builder pattern. The whole purpose of the pattern is to decouple the building process from the concrete classes that are built. Let's have a second reading:
The construction process must allow different representations for the object that's constructed.
This is not about having many constructors or not. The terms "...
3
As in any data processing or sequential operations, look for functional programming patterns as a cleaner alternative for design patterns.
Design patterns wise:
strategy pattern helps when you should pick 1 algorithm from a list of algorithms to apply as a transformation. Here your modules can be considered an algo to apply
iterator pattern here would be a ...
2
Cyclic references sometimes have their place, and before rejecting them as a solution, I think it is important to understand why and when they may become an issue, and if this issue really applies to your case.
For example, as you mentioned by yourself, one could solve this problem by introducing an ctor parameter UiMainApplication * to UiMenu. I would ...
2
tl;dr– Argument-validation is a run-time check for the part of the method-signature that isn't checked at compile-time. Prohibiting public abstract/virtual methods is a pattern for ensuring that the exact same code-validation is used, consistent with the requirement that the exact same compile-time checks apply to the same signature-group.
The rationale ...
2
Dependency inversion (of any kind) is simply a tool you use if you need to disentangle dependencies. As you already understand, that's not needed in your use case. Construction of an instance with its composed pieces created right then and there is perfectly fine in many (even most) cases.
Remember: SOLID, DRY, and the rest of the zoo of acronyms are ...
2
You are facing an Open/close dilemma:
The abstract card is meant to be open for extension but closed for modification.
At the same time you want to force all extension to implement the builder pattern, which only takes the currently known construction parameters.
As a result, the extension is less open than it could: what if a concrete implementation of ...
1
As you intend to use the getValue() method from the "end of conversion" interrupt, I am going to propose a completely different architecture.
Conceptually, the interrupt handler for the "end of conversion" interrupt of the internal ADC is part of the AdcInt driver and the corresponding interrupt handler for the external ADC is part of the ...
answered Feb 27 at 12:59
Bart van Ingen Schenau
62.4k19 gold badges94 silver badges156 bronze badges
1
IMSoP is correct in identifying that abstraction without a purpose is meaningless, so we need to know what you intend to achieve. To quote an answer I wrote in the past on the same topic, abstraction without a concrete goal is turtles all the way down.
Your response:
Yes reduce Copy paste mostly. Same methods being pasted around again and again. A good ...
1
There are three different sets of relationships to represent here:
The relationships among the domain entities. If an "Order Line" is always part of a specific "Order", you should represent that directly, not by always passing them as a pair. Similarly, if an "Order Line" has a specific "Product" attached to it, you ...
1
When applying DDD there are two relevant concepts: the Repository and the Aggregate Root (AR).
Whatever persistence technology you use, the AR has to be loaded from storage into memory and persisted back after the changes have been applied to the in-memory model. All changes to the graph of objects inside the Aggregate have to go thru the AR.
The ...
1
Let us assume you don't want to turn SomethingData into a mutable class (of course, a blurry name like SomethingData isn't particular helpful to evaluate such design decisions, but let us assume this makes most sense for this case).
Without introducing a DI container, your solution #1 is the straightforward solution to this I would recommend. The basicInfo ...
1
I would like to be able to use the app's programming language to
dynamically create classes that match our form models, but I do not
consider a good practice do to so. On the other hand, I don't think it
is smart either to recreate OOP at a higher level of abstraction ...
The idea isn't new. In Java, we have libraries addressed to create classes from ...
Only top voted, non community-wiki answers of a minimum length are eligible
