Tag Info

Hot answers tagged

8

There is an old, old ongoing debate about the best way to do dependency injection. The original cut of spring instantiated a plain object, and then injected dependencies though setter methods. But then a large contingency of folks insisted that injecting dependencies through constructor parameters was the correct way to do it. Then, lately, as using ...


7

It annoys me that object-oriented design education focuses almost exclusively on designing object hierarchies and almost completely neglects the structure of the other, often larger, side of object-oriented programs: the calling code. The answer is to put the interface on only one subclass, and structure the calling code so all the calling code either ...


6

If you really want something that works well for you, then I suggest you get used to the idea of "unnecessarily complex"... that's the nature of dealing with Microsoft Office file formats. I (sort of) like your idea of "blocks"... I would make sub-classed block objects, like Table, with Columns and Rows independent of the notion of cells. Then use your ...


6

The question is a bit vague (e.g. what exactly do you mean by a third party?), but to try and answer anyway: I think you're looking for the Observer pattern. The intent of the pattern is to allow entities to be notified when the state of some object changes, while decoupling the two sides. I.e., the observers don't know anything about the subject except ...


6

You are missing option 3 (and more). Don't have a DefaultTokenizer. There is no value, and it leads people to make choices that reduce maintainability later. Additionally, the problem can be solved with sensible documentation. Reasons not to have the Default: you actually can't change it later, because people expect the default to be a specific ...


5

This design makes several non-trivial assumptions: The user's input will not depend on the results of pure or impure computations. The impure computations will not depend on the result of pure computations. The program logic will not loop; it will run only once. My other comment on your structure is that you do not need to separate the pure and impure ...


4

When you swim at the shallow end of the pool, everything is "easy and convenient". Once you get past a dozen or so objects, it is no longer convenient. In your example, you have bound your billing process forever and a day to PayPal. Suppose you want to use a different credit card processor? Suppose you want to create a specialty credit card processor that ...


4

As long as calculatePay() is as simple as in your example, and as long as it does not need any parameters more than members from Employee, I would leave the method where it is. But when calculatePay() becomes more complex, and it needs information from outside the Employee class (like information from the employer, about taxes, actual date, etc.) I would ...


4

I think the problem is that your state machine class is too specific for the protocol. If it was generic, the table of actions would be provided by the protocol class to the state machine class. Those actions would just be std::function<void(ServiceClass*). Clearly the protocol class has access to the service class, as the protocol defines which service ...


4

Interpretations like the one from a string representing a note to a note object is the very reason for a controller, and therefore should be placed there. The underlying idea behind the Model-View-Control pattern is to maintain a domain model free of system details. This separation of concerns allows the model to focus on the domain only and let surrounding ...


3

You are doing it correctly. The thing is called a mixin and is rather common. Quick search shows e.g. What are Mixins (as a concept) or What is C++ Mixin-Style?. They are a case of the Curiously Recurring Template Pattern, name of which even comes from the fact that it is, well, recurring. In your case actually using full CRTP would let you avoid the ...


3

Let's have a look at the Simple Factory The intention for the Simple Factory is straightforward: It produces instances of concrete classes. Sticking to your example: you have a Pizzeria with methods like order(): public enum Pizzas { QUADDROSTAGGIONI, SALMONE, ROMANA } public class Pizzeria { public static Pizza order(Pizzas type){ ...


3

No, not really. It's clearly got two independent paths. It would be better to separate them into two (possibly overloaded) functions to better decouple them. Better yet, I would look to eliminate the name specific behavior unless it's really that common. What happens if you want to find errors since Thursday? What about errors that contain the word ...


3

You may have more joy dividing your interfaces by behaviour and deciding on the types later. interface IConnectable Connect Disconnect interface IDataTransferrable GetData SetData interface IPlayable Start Pause Stop class TypeA : IConnectable, IDataTransferrable class TypeB : IConnectable, IDataTransferrable, IPlayable And ...


3

The question is: Who instantiates the Controller? If it's created outside the FloodGate instance, you can wrap it there and pass the wrapped instance into the FloodGate. If it's created by the FloodGate internally (which seems strange to me, but I'm not into your domain), you could either change that and pass it in (e.g. as a constructor parameter) or add ...


3

The "instantiate my own collaborators" approach may work for dependency trees, but it certainly won't work well for dependency graphs which are general directed acyclic graphs (DAG). In a dependency DAG, multiple nodes can point to the same node - which means that two objects use the same object as collaborator. This case can in fact not be constructed with ...


2

There is no clear notion of the term »component«. You could use it in many different ways. But if you go to the root of the word (in terms of linguistics) you have »componere«, which is itself a »compositum« of »cum« (with) and »ponere« (put). So if you put something together you have a »composition« of individual parts. There are two main aspects for ...


2

I would use composition to model this problem. There are more classes this way, but the classes are better segregated. A person has a role. A role has a salary. If the company changes the way that pays are calculated it requires changes in the PayCalculator. If the definition of a person is changed, it only requires change in the Person class. If a ...


2

The classic approach for decoupling two components is by defining a clear interface between them and let them communicate only by this interface (opposed to giving direct access to any internals). So in your case: create an interface class (in C++ typically an abstract base class) for your service class, defining the interface you want to make public. Any ...


1

Without the knowledge of your actual domain and problem you're solving, it's hard to model the resources. Anyway, from the description, it seems like there is a collection of messages and a few views how one can look at them - by group, by sender, by recipient or by a combination of them. Potentially, a single resource for the messages with some query ...


1

Truthfully, it doesn't really matter. There isn't much difference between a presenter-first design where the presenter subscribes to events on the view (observer pattern) and a view-first design where the view calls methods on the presenter instead of raising those events (potentially using command pattern, such as in MVVM). So long as you inject an ...


1

If you want to modell your classes by the single responsibility principle (SRP), you have to make up your mind what these responsibilities are. When you want to use your Employee class in a salary payment application, then the CalculatePayment method is perfectly right in that place. The Employee represents an employed person which for sure has a name. ...


1

Firstly, I believe following OOP SOLID Principles, calculatePay() method should not be an employee objects responsibility... Am I right in thinking this way? Yes and no. That behavior should not be the responsibly of the employee, but not because of any programming or design principle. It is because no company in the world lets their employees ...


1

For your first question, Strategy Pattern might be best solution. Each concrete strategy would be related to concrete employee type. But you should have separate employee types if different employees have different behaviors. For your second question, it is similar situation as I answered here : Is this a violation of the Liskov Substitution Principle? If ...


1

Let's explore the differences between using an interface vs a base class: If I'm using an interface, that means I need to also implement the, for example, connection logic for each class which wants to connect to the DB. That is a huge pain. However, if I just subclass a base class (which already provides connection method), then I don't need to keep on ...


1

I really don't think that the podcast's discussion of "components" is directly in the context of the composite pattern. They are talking about component-based software engineering. I suppose this is one of the pitfalls of the ambiguity of software development terminology. But, putting that aside to discuss the composite pattern, there's a nice explanation ...


1

To your first question: it is quite normal that each command contructor may have a different signature with different dependencies, so constructing the commands cannot be done fully generic. Using a DIC can indeed mitigate this. For more complex scenarios, you could also use the "abstract factory" pattern, where you have one factory class per command, all ...


1

I've not used Google Guice, but I've taken a great deal of time migrating old legacy N-tier applications in .Net to IoC architectures like Onion Layer that depend on Dependency Injection to decouple things. Why Dependency Injection? The purpose of Dependency Injection isn't actually for testability, it's actually to take tightly coupled applications and ...


1

I would think of the problem in the opposite way. Instead of "soft delete" think of it as an archive flag. You should never plan on restoring the record, since you will either have to circumvent your rules for new records, which may have changed since this record was created, or allow the record to slip past your "new record" business logic and possibly ...


1

TBH I wouldn't move it to a separate database or table as that would just be an extra layer of complication. In my last job, who developed and maintained enterprise solutions for large clients, we would leave the records in place, just using a bit field/boolean to hide it from the user. A user with higher privileges could come along and then undelete a ...



Only top voted, non community-wiki answers of a minimum length are eligible