New answers tagged object-oriented
1
Data and logic do not need to be separated to satisfy SRP. In fact, I do not think you should be doing that, not even for functional programming. Yet, will get to that.
About your code, at method level you are not breaking SRP. However, at class level you are. Let us speak in reasons to change...
You could have to change your code if:
You decide to change ...
1
First, let me quote the complete paragraph from P109 of the book:
" But you’d like a little more quality control...!
So you test marketed the SimpleFactory idea, and what you found was that the franchises were using your factory to create pizzas, but starting to employ their own home grown procedures for the rest of the process: they'd bake things a little ...
4
From OOP and C# perspective the example code doesn't violate SRP. Data and basic operations over it belong together, that's what classes are. The idea to separate data and logic should be applied on higher level in large applications, e.g. business logic should be separate from data persistence.
One can make other remarks on the code, not related to SRP. ...
0
(Picture this in your mind)
get_cheese and set_cheese exposes the cheese. putCheese() and takeCheese() keeps the cheese hidden and takes care of managing it and give the user a way to handle it. The observer doesn't see the cheese, he/she only sees two methods of manipulating it.
1
I believe what you want to have a Normal Dao which will read data from DB and then have a FilteredDao which will get Data and the apply filter and return it.
Composition over Inheritance
You can do this way.
Have class IDAO
public interface IDao {
public String getData();
}
Dao Impl
public class DaoImpl implements IDao {
public String ...
2
Almost all of this shows a fundamental misunderstanding of encapsulation, and how it applies.
The initial response that you were breaking encapsulation is just wrong. Your application may have a need to simply set the value of cheese in the fridge instead of increment/decrement or add/remove. Also, it is not semantics, no matter what you call it, if you ...
6
Getters and setters break encapsulation every single time, by definition. What might be argued is that sometimes we need to do that. With that out of the way, here are my answers:
How is encapsulation preserved by renaming it from get/set to putCheese()/takeCheese() You're obviously getting/setting a value, so why not simply leave it as get/set?
The ...
15
I think you are missing the point. Its not saying you should rename the setter and getter, but to have methods which add and remove items from the fridge. ie
public class Fridge
{
private int numberOfCheeseSlices;
public void AddCheeseSlices(int n)
{
if(n < 0) {
throw new Exception("you cant add negative cheese!");
...
1
You say that you don't want to move the projectsDAO.fetchProjects out of this constructor because then "... almost all of the logic would have to be done before the constructor is called..." but it seems to me that the logic outside this method is exactly what's determining which fetchProjects method to call.
What I mean is that you have logic outside of ...
5
"Classes should be immutable unless there's a very good reason to make them mutable."
Joshua Bloch - Effective Java
"Principles should be followed because you understand what you're getting out of following them. Not because you can quote them from some famous guys book."
Some anonymous guy on the internet
Immutable or not, encapsulated or ...
11
Some thoughts:
Now, as far as I know, it's bad practice to have effectful computations inside a constructor
That depends on what you mean by "effectful."
The purpose of a constructor is to "construct" an object. To do that, you may need to do many things. One of the things you may need to do is set up some state inside the new object. Is that what ...
2
If the idea is that a FilterDao includes all of the behaviours that a regular Dao does, then you can make FilterDao extend the Dao interface. e.g.
public interface FilterDao extends Dao {
you can then extend the implementation to avoid reimplementing methods:
public class FilterDaoImpl extends DaoImpl implements FilterDao {
By the way, most Java ...
0
I don't often add a second answer, but I have another approach that might make more sense and require less code, and I still think my other answer has value as well.
In PHP you can return an array of values and split them out into multiple variables in the caller.
You could add a static method to the Crate class that accepts the arguments to the Crate ...
0
The problem here is that, despite your description of the problem and the name you have given your method, you aren't actually showing a Crate. You are displaying something else altogether. You are displaying a message indicating the result of attempting to create a Crate.
class CrateRequestHandler
{
function handle(ServerRequestInterface $request)
{...
1
With a lot of things defined vaguely, I'll still hazard to suggest a few things.
Where there is a hierarchy (a tree), there are paths. Look at the file system.
If I the number of path steps is fixed, I would just have a tuple of (cabinet_id, shelf_id, box_id, row, col) for each item, and index them in that order. This would allow for efficient range ...
2
There are a number of unknowns in your description, so either of the two solutions (or a somewhat different one) could be best suited.
If the containers are managed in a hierarchy (an item is at a location in a box, the box is on some level on a shelf etc.) designing data structures around these containment relationships might make sense. If all you have is ...
1
As long as no heap memory is allocated, creating objects in C++ (when no calculations are performed in the constructor) isn't more expensive than calling a function and assigning individual variables, as can be seen in the following compilation result: https://godbolt.org/z/n016Fw
If the constructor performs mathematical computations then it depends on the ...
2
I’d look into the Object Pool pattern that basically does the recycling you mention yourself.
It’s actually how both Android and iOS handle the problem of “staggering” while scrolling on a list of items e.g. a newsfeed or product list.
Close relatives are the Prototype and Flyweight patterns.
Among these three and some sort of factory and depending on the ...
1
To me, I'll create another value object called CrateCreation to model the creation of your crates and let showCrates accept the list of CrateCreation objects instead of the list of the actual Crate objects. The CrateCreation object holds these pieces of information:
The original input values.
The actual Crate object if the creation is success.
Sample class:...
0
OP here. I saw my problem as a need to postpone exception handling messages. Namely, exception handling interrupts the flow of the program to deliver an exception message right at the point of failure. I needed to postpone this reporting until the time of the view layer takes effect.
In other words I needed a way to store the exception messages and ...
1
You are correct in asserting the Crate object should always be valid. This is a business class that should be enforcing its invariants — which it currently does. The problem lies with taking user input. You must allow user input to violate business rules and constraints. You will need at least 2 other classes:
A "view model" or "parameter" object that ...
0
So what you are asking is for it to be impossible to compile code which produces an invalid crate at run time.
This is not as impossible as it sounds, but you are going to have to use a strongly typed language. I'm not sure you can do it in PHP
for example, lets say for a second we allow a 0 size crate. you could change the construction parameters to ...
4
Yes, your Role class is violating the Single Responsibility Principle, because it has knowledge how to delete an account. That knowledge should be reserved to the Account class itself.
The knowledge the belongs in the Role class is which accounts a user with a particular role is allowed to delete. And a single user can have different roles.
For example, ...
3
DeleteAccount should not be in any of your examples because a role is not an actor, it is a property. A role has a bunch of rights linked to it. It is just a convenience, it allows you to assign a set of rights to a person. With these rights that person is then allowed or not to initiate a delete operation. The delete operation itself should be a method on ...
1
It looks like it is a utility class. It's common to just name is WhateverItIsUtil but you need to ask yourself if they would be better placed in the class they are used on.
Also, I don't think you should name it a verb. Many might also name it a SomethingManager.
Obviously if you need to share the methods with many classes then you might feel stuck with ...
1
I have a third option for you: Genomes are data. I mean, have value semantics. However, let me go over your pros and cons first.
On Method one
This way we will have the option to derive from Mutation class later on to implement various kinds of mutations.
The idea that you are thinking about deriving from the Mutation class suggests to me that you want ...
1
Method 2 is the default design to have based on the most basic object-oriented principle that behavior should live where the data is. It is also the most maintainable, the simplest one.
So I would go with that, until Method 1 is absolutely needed. You are allowed to refactor things later. So go with the simplest design first and introduce indirections/...
5
In approach 1 you can apply a strategy pattern to support different kinds of mutation.
[Con's] More classes
This is not really a downside. Classes organize instance members. You probably have the same number of instance members in either approach. We should not seek to minimize classes at the expense of conflating concepts.
[Cons] ...
4
Up to now, you've only described attributes, no responsibilities at all. This isn't actually object-oriented, and the SRP isn't applicable. Start by looking at what you want to do in your application, and what roles the crate plays in it. Attributes come later as needed to fulfill these roles. If you find that the Crate object's only responsibility is to ...
5
There's nothing inherently wrong with your design, although as @RobertHarvey points out in the comments, you might want to treat price separately, as that can depend on a lot of things besides the crate itself. That's dependent on your business rules in regards to price, though.
Your Crate class does have one responsibility - describing a crate. Dimensions ...
1
An object model != data model. What's more, anything that is similar, let alone based on a data model is not an object model.
So there should be no objects for tables, no properties for columns. It's not needed anyway. If I understand you right, the previous application was an Access application, by which I assume it was just a dumb entry frontend for a ...
0
I'm gonna go against the answers here and claim that instanceof in this case is okay.
Let's forget about PHP for a sec, this is what it would like in TypeScript:
type PublicAccount = {
type: "public";
publicAccounts: List<any>; // IDK the type
}
type PrivateAccount = {
type: "private";
privateAccounts: List<any>; // IDK the type
}
type ...
3
Initialization code is what constructors are for. Don't make me call a method every time I construct a new object. That makes me wonder what the method does that required me to call it (nothing), and feel like you're not smart enough to call it yourself.
If you like, you can break it off into a static function for code organization purposes. Remember to ...
2
No, introducing this temporal coupling is not a good idea. Constructors should create a ready to use object, or no object at all (throw an exception). So usually, a constructor will do little more than checking invariants and performing initialization.
By extracting part of the setup into the connect() method, you have made the object's API a lot more ...
0
Why are the accounts in two different tables? Don’t they have many columns in common, if not all of them? Can’t you put common columns in a common table and then join to an ancillary table for the differences? If you need referential integrity, can’t you use one of the ancillary tables or use a two-column constraint (second being accountTypeID)? Or use a ...
Top 50 recent answers are included
