New answers tagged

0

I am not sure, but I think here you could use a pimpl pattern?


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 ...


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 ...


0

No, roughtly speaking, there is nothing wrong in defining a subclass of an inner class, static or not, at least a priori. An inner class has a strong coupling / dependecy with its holding class. Thus, if a class called ANY "uses" an inner class called INNER which is defined as a inner class inside the class called HOLDER, ANY need to know both ...


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 ...


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

First of all, your diagram does not correspond to the narrative: In your diagram, Person inherits from Person2. So Person2 would be an anonymous person without any name. Not very useful. To letPerson2 inherit from Person (in UML-speak we say that Person2 is a specialization of Person), you must have the triangle arrow head on the side of Person. Note that ...


-1

Subclassing in this case is kind of cheating. If there is functionality that you can extract into a separate useful class, that might be a better choice.


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 ...


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 ...


Top 50 recent answers are included