Our code has a method whereContractEndIsAfterOrEqualDate(), and I do not really like the "AfterOrEqualDate" part because it is so long.
Is there a better name for such methods?
The Laravel PHP framework has validators that have the same name: https://laravel.com/docs/5.5/validation#rule-after-or-equal
I would prefer something more logical/semantic way that expresses the real behavior of this control like isContractDateExpired() if this is a boolean method.
By this approach you are fixing the method's name to reveal it's intention from the objects context itself. From the upper level perspective accessing and calling this object it may not be important to declare how to check the date if it is before and equal to a date or not. This approach allows our objects to be more domain-driven and more autonomous.
How about:
.contractValid()
.contractExpired()
?
!beforeDate() might be cleaner
Related
I'm learning DDD (Domain Driven Design) and reading Clean Architecture. I found out about Value Objects and have been reading more about them and have implemented some in my application which could be found https://gist.github.com/Tyler0722/73ec826be814b8e54b9f6ae6ae836409.
Value Objects are created by calling the factory method which performs validation and follows the separation of concerns principle. The problem is I have two Value Objects where the validation logic is duplicated. Username and QuizTitle where the only difference is MAX_LENGTH which violates the DRY principle. I was wondering if anyone knew anyway I could make this DRY.
If you want to remove repetition you must be very careful.
The first question you should ask yourself is
What is the same and what is different?
Maybe you will find the same or similar structure like
check the props
create an error result or a success result
If you found out what you think the same is you have to ask yourself more questions:
Do the things that are (look) the same have different responsibilities?
Do they change for the same or for different reasons?"
These are the questions that are about the single responsibility principle. Sometime things look the same by accident. They look the same but are different, because they change of different reasons. If you eliminate the "duplication" in this case you will have more problems then you solve.
E.g. if you consolidate the validation logic of QuizTitle and Username into one method and later you get a change request for the QuizTitle validation you can easily break the validation behavior of Username. I guess it should not change if the QuizTitle validation changes.
You might also want to read the good article by Martin Fowler about Avoiding Repetition
My suggestion is to not do it. In this case it's just not necessary.
But if you want to do it anyway, you can build a Validation class with static functions. At my work we use Webmozart/Assert and if you take a look at its implementation you will understand what I mean. In my opinion there are very handy. Also you can pass the MAX_LENGHT as an argument.
Well, I agree with Darius Mann, that these value objects have similar business logic is ocasional, if they are different concepts in your app, keep them separated and independently, it is my opinion.
A diagram I made in the Microsoft Paint program to better understand PHP Objects.
Ok, so I have been reading up on php objects recently and they are becoming quite confusing the more i get into interfaces and encapsulations. I also seem to be confusing classes and objects, but now I am fairly certain that (as my diagram shows) Classes are actually "bigger" than objects, if you will- that objects are just new instances (or occurrences) of a class. I am aware of the crudeness of my drawing, but can anyone out there tell me if i am on the right track? I also referred to "interface" between properties and methods because, as i understand it, interface is the process by which methods (or functions within an object) can alter properties in some way. Correct me if i'm wrong.
In the book I'm reading "Learning PHP, MySQL & JavaScript: with Jquery, CSS, and HTML5" by Robin Nixon (5 Stars), I was given an example on creating and interacting with an object. I tried to alter the code (which was originally created to deal with 'Users' on a social media network) to instead echo out to the browser that 2 objects in the "Married" class would be Maj Kanaan, the Husband ($object1) and Wife Kanaan, his Wife ($object2), but with 3 properties: first_name, last_name, and title (husand or wife). However after trying several different things i came to believe that arrays should be used in this situation or at least the __construct method, but i am missing something big here. Can anyone help? Please and thank you. I really have no code to post as an example because everything i tried was way off so i just deleted it all. All i have in my feeble explanation. Hope someone is able to work with that. Thanks again!
-your friend Maj
"Classes are actually "bigger" " not certain where you are going with that but no. Quoting a title a professor forced on one of my early programming classes "Objects have class". Classes describe objects, objects are instances (actual manifestations of) classes. Classes are just a blueprint that don't do anything at all. Objects don't exist without that blueprint. You might find Differences between object and class in php useful.
Interfaces are actually templates for classes. A class can implement an interface. It's not really a go between methods and properties, but defines a set of properties and methods that a class that implements it should have defined. Most of the time one wouldn't need to use an interface unless you are working with libraries or similar shared code.
I was recently studying an online course. it was recommended that to reduce coupling we could simply pass the ID from the customer object to the Order object. that way the Order did not have to have a full reference to the Customer class.
The idea certainly seems simple and why pass a whole object if you don't need all its attributes?
1) What do you think of this idea?
2) How would I express the relationship between the Customer class and the Order class in UML if only an ID is passed. This isn't just an example of aggregation is it? Doesn't composition and aggregation require more than just passing a value?
Thanks!
First of all you need to be clear about what UML actually is. On the one hand you have an idea and on the other side there is some code running on hardware. Ideally the latter supports the first in a way that brings added value to a user of the idea. Now, there are many possibilities to describe the way from idea to code. And UML is one of them. It is possible to describe each step on this way but for pragmatic reasons UML stops at the border of code, namely programming languages.
Now for you concrete question: Any object can be seen as an instance. That is some concrete memory partition with a fixed address. Programming languages realize instances by allocating memory and using the start address as reference. And since this reference does not change the object can be identified by its address. Clearly then, an association will just be the a pointer. And an association class will hold two (or more) such pointers.
Honestly, the very first time I started with OO I was also confused and thought that it's a waste of resource to pass those large objects. But since it's just a pointer it's really easy going.
Again, things can get more difficult if you need to persist objects. In that case you need an artificial key you can save along with the object and you will likely need tables to map artificial key to the concrete instance address.
The answer to this question depends on a number of factors, which I started listing in a comment attached to your question. I will assume that you are either using UML to create a Domain Model, or you are describing an implementation done using a statically typed language.
If you are using UML to create a Domain Model, you are obfuscating the semantics when you use an ID to "link" classes. Just draw and annotate the association and you're done.
If you are describing an implementation done using a statically typed language - types exist for a reason. Using generic IDs to link things means that the information that the system needs most become more indirect, and therefore more opaque (which is bad). In your case, the Order object still must acquire a typed reference to a Customer object to do anything with it.
For example, the Order may acquire a reference to the Customer by invoking a lookup by the ID, but it must cast the reference to an appropriate type to invoke anything on the Customer object. So you haven't reduced the coupling from the Order to the Customer. You just buried it somwhere else.
While implementing a find (or search) method in a repository class, is is better to accept a domain model or is it better to implement specific find methods?
For example we have a Person class with the attributes name, id.
In the repository we could have a find method that accepts a person as a parameter. That method will use the given model to search for an existing person.
The other approach is to implement a find method per attribute (find_by_name, find_by_id).
Since I will be implementing this in Python I could also implement a method accepting keywords. This will resemble the accept-a-model approach: find(name='harry')
As a side question, when the find method concerns an indexed value (id), is it better to use get_by_id() (which implies indexes) or find_by_id() (which is more abstract).
Personally I would implement specific find methods. A repository is a collection-like abstraction of the persistence mechanism and its interface should be written in the semantics of your domain.
Although queries like find_by_name or find_by_id are valid, very often one would need queries of the type find_vip_persons which could be a combination of several properties of the Person aggregate root (e.g. salary > 10000 & age > 21). Especially in cases like these I would avoid a generic query method, since the domain logic (i.e. what makes a person a VIP) could easily become scattered everywhere in your code base.
Although I'm not very familiar with Pythons keyword arguments and could be wrong here, I would assume that the 'accept-a-model approach' you're considering doesn't allow for more complex conditions like the VIP example from above anyway (i.e. comparison operators).
If you want use a generic repository interface and reuse queries at different locations in the domain, then you should have a look at the 'Specification Pattern'.
Regarding your 'Find vs. Get' question I'd say it doesn't really matter. I would probably use 'Query' instead, but that's just a matter of personal preference.
Use findBy(attribute) is preferrable in semantics and more meaningfule if there is not many specific query requirements.
personRepository.find_by_name(name); //is easy to read
personRepository.find_by_age(age); //
personRepository.find(person); //this one is at odds and confused
But if there are too many specific query methods on the repository, it's also a pain. In this case, you need a criteria. Pretty much the same way you use your find_by_person now, but more natural in semantics.
criteria.nameEq = 'hippoom';
personRepository.findBy(criteria);
criteria.worksFor = 'XXX company';
criteria.ageGt = 25
personRepository.findBy(criteria);
Which is a better approach, create child entities first, then pass to the aggregate root to add them, or have the aggregate root create them? For example:
Order.AddOrderLine(new OrderLine(product, quantity, ...));
Or
Order.AddOrderLine(product, quanity, ...);
Which is a better approach? I'm sure this is purely subjective, but I want to see which has more pros vs cons.
Ok, so basically my opinion is that you should create an object before, because:
creating of the object is itself a separate concern, which can be a fairly complex by the way. And if, for instance, constructor of the OrderLine will be changed later you will need to change an Order type too. This is bad, cos you will need to change the Order only because of some changes in the OrderLine. So interface of the Order Root shouldn't depend on the OrderLine.
the second approach may be hard to test if you method will contain some additional logic exept of only calling this.OrderLines.Add(orderLine);
Edit
After discussing this with a friend of mine, I came up with the following opinion:
Order Root should control lifetime of his child, because this will be more clear for other person who uses this API and will minimize the possibility of an inappropriate usage. And also will better reveal intent.
Using this approach also allows us not to worry about validating incoming OrderLine, because if we are responsible of the OrderLine creation then we can create it properly.