152
votes
Accepted
When to *not* use SOLID principles
My Principle of Applying Principles:
Principles, patterns, and practices are not final purposes. The good and proper application of each is therefore inspired and constrained by a superior, more ...
- 14.5k
23
votes
Are "need to call objects in parent object" and "avoid circular dependency" reasons to avoid "Tell, don't ask"?
Ultimately, you're pushing all the program logic into class Manager. Everything else is only a dumb interface. As the program develops, Manager gets bigger and bigger, until it's an unmaintainable ...
- 9,463
14
votes
When to *not* use SOLID principles
Even when a certain situation does not require those principles, following SOLID to a certain degree does not automatically lead to "worse code" (at least, it does not automatically make ...
- 201k
11
votes
When to *not* use SOLID principles
SOLID principles (and most of software engineering, really) are about human factors. The goal is to enable working on a codebase in the face of unforeseeable future requirements changes.
Therefore, ...
- 108k
6
votes
Are "need to call objects in parent object" and "avoid circular dependency" reasons to avoid "Tell, don't ask"?
The point is to reduce how much Manager knows. Also, SystemMoniter should only know its things. it shouldn't need to know about Leds, Speakers, or the Screen. And actually, neither should the Manager.
...
- 373
6
votes
Accepted
In poltergeist, whats wrong with "solely to trigger or initialize several other objects"? Isn't it is a good use of encapsulation and reuse?
First, let me say the Wikipedia article about Poltergeist, as it is written today in Sept. 2023, isn't very clear. It lacks an example, suffers from some overgeneralization and oversimplification, and ...
- 201k
4
votes
When to *not* use SOLID principles
All of these concepts in SOLID have disadvantages.
S - This one is mostly safe, unless you are restrained from an address or storage space perspective. Think embedded software.
O - Can come with a ...
- 634
4
votes
When to *not* use SOLID principles
I do not think I can add anything new, as there are already a couple of really good answers, so I will merely try to put it another way around.
The idea behind the SOLID principles is to have clean, ...
- 41
3
votes
When to *not* use SOLID principles
The SOLID principles are also called the principles of object oriented programming. Since no other answer has mentioned it before, let me do it.
You don't apply SOLID to any other programming paradigm,...
- 259
3
votes
How encapsulating what varies can help us?
As always the question for the "best" software design depends on the specific context and requirements, therefore there will likely be no definite answer, but lets introduce some concepts ...
- 278
2
votes
Accepted
How encapsulating what varies can help us?
It is the nature of an example that it is simple and that a reader can easily grasp its entire content without needing an elaborate explanation.
It is the nature of real production code that things ...
- 45.5k
2
votes
When to *not* use SOLID principles
S: Good for the most part, but be careful not to over-fragment your code and scatter functionality all over the place.
O: Applicable to enterprise OOP. Probably you should just avoid inheritance, in ...
- 255
1
vote
Are "need to call objects in parent object" and "avoid circular dependency" reasons to avoid "Tell, don't ask"?
The problem I see here is a good old fashioned coupling problem.
Your 'bad' does too much. Then in 'good' you delegate to something else that also does too much. This is not progress.
public class ...
- 103k
1
vote
Is it necessary or "class obsession" (opposite to primitive obsession) to create classes for non-business fields?
If you want to put the dialog showing logic in another class then do it like you mean it.
public class MyActivity extends Activity{
onResume(){
welcome.considerShowingDialog();
}
}
...
- 103k
1
vote
When to *not* use SOLID principles
As you are mostly looking for examples where skipping aspects of SOLID may be OK, or where sticking to it too much might be problematic, let me suggest this:
The more your code base has the character ...
- 5,664
1
vote
Where to put factories that depend on the application layer?
Instead of separate factory, you could create a static factory method inside the cart class.
This method takes in a collection of CartItem entities and returns a new Cart instance. Give it a ...
- 4,480
1
vote
Where to put factories that depend on the application layer?
I have to say your question is not easy to understand - a little bit of context about your domains would be good. From my limited knowledge about domain driven design, I would think, that the Cart in ...
- 278
1
vote
How to structure a cart with cart products object
Actually, you get to choose. Whatever makes the most sense to you.
This is one of the beauties of properly separated code. You are able to define what your persistence CartProduct (i.e. the table ...
- 45.5k
1
vote
Accepted
How to structure a cart with cart products object
There are multiple ways to structure this, which are independent of Domain Driven Design. The Ubiquitous Language mentioned in DDD guides you in naming things. Within the realm of e-commerce, products,...
- 34.3k
1
vote
REST - Adding a new field
There is no relation to how information is given on a REST API and how information is stored in a database.
It is entirely normal and accepted that a REST API presents data from multiple database ...
- 72.4k
1
vote
From the perspective of OOP, taking performance into account - should a database connection be a static field, an instance field, or a local variable?
For a tiny program that you write just to learn to program, it doesn't matter. In fact, it is probably worth experimenting with all the kinds of variables, while learning, just to get familiar with ...
- 111
Only top scored, non community-wiki answers of a minimum length are eligible