11
Behaviour is decisions being made.
State is decisions being remembered.
When OOP people talk about behaviour what they mean is the gooey sticky part of the code base that has to be changed every time a business rule changes. Rather than state what this is usually contrasted with is dry structural cerimonial code that exists mostly because the system or ...
8
Your question seems to be based on a misunderstanding. Fowler does not "dislike temps" in general. Quite the opposite, he provided a specific refactoring for introducing such variables, he called it
Extract Variable (a.k.a. "Introduce Explaining Variable")
Of course, he also gave the inverse operation a name:
Inline Variable
From this I hope it gets ...
5
I don't see much value in reduction of temporary variables as a goal unto itself, especially if those variables are being used to clarify the code.
Consider these two code examples from refactoring.guru:
void renderBanner() {
if ((platform.toUpperCase().indexOf("MAC") > -1) &&
(browser.toUpperCase().indexOf("IE") > -1) &&
...
5
In OOA&D, what recommendations should be followed in order to produce an accurate conceptual Domain Model?
I'd recommend grabbing a copy of Domain-Driven Design by Eric Evans, it's an excellent book that walks through the process of talking to domain experts and distilling ideas into a software model. One of the central ideas in the book is to develop a ...
4
I have run into this problem many times. When the fields used are expected to change like this the best plan is to stop pretending you have a class. What you have is a key value collection.
Single inheritance only works when change grows in one dimension. That is, our base class had these 3 fields. The child needs those 3 plus these 2. That all falls apart ...
4
Wouldn't a forEach be same as if here?
As far as branching goes yes. Loops have branches.
If you seriously need to avoid branching (maybe because of some branch prediction optimization issue) the branchless fix is the null object pattern where you create a class that has a DoSomething() method that does nothing, quietly.
Do that and the code becomes:
...
4
There are multiple layers to the answer.
On the technical level, state is simply the instance variables of an object, and behavior are the methods. Both of these can be extended to other granularity units, like a group of objects or the whole system. Should be clear from the context.
On the semantic ("meaning") level, specifically for object-orientation, ...
3
I would not put any "setter" for Gold into IFighter, and only implement a setter for this property in the Person class, not in the Group class.
The amount of Gold for a group is the total sum of all the gold of all group members, that makes sense. But when gold is assigned to a group, how it is distributed specificially to each person is specific game ...
2
This will not work in view of C++ object lifecycle and the construction logic. Here is what happens:
you construct a MyClassDerived
Before the (empty) MyClassDerived constructor body is invoked, first the base object is constructed and then the member variables (with their default constructor unless you use a mem-initializer).
The MyClass constructor is ...
2
I wouldn't consider this to be a violation of the open-closed principle: because the trait is sealed, the relevant entity isn't just Person, but Person together with its implementations, and isn't open for extension either way!
2
Short answer: No. There is no unified mechanical process which produces a good object-model. Modelling is a creative and social process, it usually involves talking to-, and understanding other people, during which you come up with different ways to decompose a problem.
Just to be clear, it is not even close. Even judging the outcome is completely ...
2
If you find yourself needing to add more data to your full inheritance stack over time, you should ask yourself whether inheritance makes sense in the first place.
It is odd for base classes to be extended that often. It defeats the purpose of inheritance and violates the O in SOLID.
You can mask that problem by wrapping everything up in an argument bundle ...
2
There are a couple of fundamental ideas behind this.
Object-Oriented Purity
The first fundamental idea is that in Object-Oriented Programming, we program by composing systems of autonomous objects that collaborate by sending messages to each other.
However, an if statement is not a message send, therefore, it is not Object-Oriented.
Dynamic runtime-...
2
It's a typical case of reading something and getting it completely wrong.
Temporary variables in their simplest, least ugly, most understable, most maintainable, most efficient form are local variables, introduced exactly at the point where they are needed, going out of scope immediately when they are not needed anymore.
Your code systematically removes ...
1
To get a different allocation than everybody the same portion, you can extend the IFighter interface with a Share property, which indicates (in a double) what portion of the gold should be given to that party member. A value of 1 should be the default and if everybody has a share of 1, then they all get an equal portion (give or take the left overs after ...
1
Patient variants have different data according to the simulation, right? So why not use composition with an IPatientModel that will be associated with the IModel used by the simulator?
If your IPatientModel instances are like documents, you could use the composite pattern (but maybe it's speculative overdesign).
1
You are having problems with your Patient class because your software doesn't have a singular concept that can be called "Patient". Thus, you can't create a single cohesive class for that concept. Each mathematical model has a different view of how the concept of a Patient should be modeled and thus they require different properties.
In a situation like ...
answered Dec 29 '19 at 13:28
Bart van Ingen Schenau
55.1k10 gold badges89 silver badges143 bronze badges
1
Your intent is to create instances of Activity based on Timesheet object input. Some properties of the created Activity are derived from Timehsheet data.
At a first sight, there is no need for a special design pattern here. This is business as usual. Design patterns are not a mandatory step to design software. It's just some frequently known challenges ...
1
From my POV there are two approaches which I would call analytical and synthetical (coming from 18th century philosophy) or perhaps more modern: top-down and bottom up. I find the former terms more describing because they indicate what you are doing: Analyzing things vs. putting things together.
I) The Analytical Way
When you enter your domain you have ...
1
Fundamentally, we want to design abstractions that are useful to their consumers (often us, ourselves).
I generally advocate thinking more about how these abstractions are going to be used (rather than, say, about their implementation details). Good abstractions are easy to use.
Let's also speak to the many different kinds of abstractions we can ...
Only top voted, non community-wiki answers of a minimum length are eligible
