Hot answers tagged

6

If you're aiming for an object oriented design, you should try to co-locatate all behavior with its data. That is pretty much the basic premise behind object-orientation. Note 1: encapsulate != include. If you put data and methods in one class, then you just included both in one class. It becomes encapsulated only if there are no way around your "...


4

Does this follow the standard way for building a RESTful API under this type of scenario Yup, that's fine. As far as REST is concerned, if the identifiers are different, then the resources are different. REST does not imply that two resources with similar identifiers will have similar representations. http://localhost/priceMetrics?startDate=2020-01-01&...


3

This is an interesting use of the implementation techniques behind the visitor pattern. However, is does not reflect the essence of the visitor pattern which is: Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. -- E.Gamma ...


1

I like the solution provided by @blaž-mrak, as it really simple, and allows the front-end to decide what they really want. However, if you where to actually allow requesting several calculations at once, here is an idea on how to do so: By the way your code looks, you probably have some logic in your application that looks kind of like (let's call the class ...


1

OK so how i understand your problem: You have a UI where you can create and edit a "person" and a domain object for Person which implements various constraints on its properties. You dont want the UI to set properties on the domain object, because that would generate errors. You do want to pass all the "person" properties back to the ...


1

I understand where you're coming from, but in this particular case, you're focusing on the wrong thing. The main point he's trying to illustrate in this section is that this should be treated as a code smell (a strong indication of possible unwanted coupling) because there's likely a bunch of other functions in the system that have (literally or conceptually)...


1

but in this way I'd have to update the whole aggregate and also the other appointments, that were not updated. This would be bad performance-wise. Yes, when doing strict DDD, the repository always saves (and loads) entire aggregates. And yes, this would result in rather bad performance with your model. Have a Doctor#schedule method, that would return just ...


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