Hot answers tagged

109

No, an object does not have to represent an entity. In fact, I would argue that when you stop thinking about objects as physical entities is when you finally get the benefits that OOP promises. This isn't the best example, but the Coffee Maker design is probably where the light started to come on for me. Objects are about messages. They're about ...


32

Whenever a developer asks "what's the point of doing this?", what they really mean is "I see no use case where doing this provides a benefit". To that end, let me show you a few examples. All examples will be based on this simple data model: A Person entity has five properties: Id, FirstName, LastName, Age, CityId And you can assume that the application ...


25

When you start a project and have a particular need, you have a choice: Either you implement your own solution from scratch, Or you use an existent library or framework. When implementing your own solution, you introduce several risks: The needs may evolve, requiring you to constantly write more and more code. Ultimately, the code you've originally ...


21

Can classes represent entity-less objects? If not, why they are bad/incomplete/non-OOP-centric? Are there ways they need to be changed/improved? In short, you can do anything, but this specific scenario would be against OOP principles :) What you are describing is sometimes called a "utility" class - usually a sign of code smell. You want to avoid creating ...


20

According to me, passing a persistable POJO, like for instance a bean managed by JPA, is not THE good practice. Why? I see three main reasons: Potential issue with lazy collections. http://java.dzone.com/articles/avoid-lazy-jpa-collections Entity should contain behaviour (in contrary of an Anemic domain model) You may not want to let your UI call some ...


15

Can classes represent entity-less objects? Can? Yes. Should? Probably not - or at least, not how you're phrasing things. Objects actually are best when not representing a physical object directly since reality so infrequently maps nicely to code. But they do need to represent a cohesive concept or code-object. They need to represent a single cohesive ...


14

To avoid ambiguity. Suppose you want to write a website about HTML. You write the line: "To write a literal < you have to write &lt;." Now, to write that down in HTML: <p>To write a literal &lt; you have to write &lt;. ... oops. To make it work, you have to have some way to distinguish the character & from the HTML syntax starting ...


13

One of the reasons I think this discussion comes up repeatedly is because it seems like a serious pain-in-the-ass to take an object with all the data you need and convert it to an object that looks identical or nearly identical to the one you are handing off. It's true, it's a PITA. But there are a few reasons (besides those enumerated above) for doing so. ...


11

A class should model something - otherwise it's pointless. However, what's being modeled may not be a physical "thing"; instead, it may be a representation of something which is not 'real', but which is needed to control the system being modeled. For example, in a traffic light control system you could very well have some sort of ControlSignal class, ...


10

Formally a "weak" entity has the following characteristics. 1. It is existence-dependent on another entity, i.e., it cannot exist without the entity with which it has a relationship. 2. It inherits at least part of it's primary key from the entity to which it is related. i.e. -> A weak entity's primary key must be a composite key that ...


9

The distinction between Entity and Value object should be based around the question: If I have two objects with the same contents (two AdvertisementEvents linking to the same Banner with the same parameters), should I treat them differently or can one be replaced by the other without affecting how the software works? In this case, I would say that you can ...


7

It is best to have checks in both places. Have checks on the client side in order to give direct feedback to the client without having to roundtrip to the server. Have checks on the server side because you can't trust the client (you never know if data has been spoofed, someone hacked your UI or whatever).


7

You are intermixing entities should not access the repositories (which is a good suggestion) and the domain layer should not access the repositories (which might be bad suggestion as long as your repositories are part of the domain layer, not the application layer). Actually, your examples show no case where an entity accesses a repository, since ...


7

You already gave the answer yourself in your comment to the other question: If two Prefix objects with the same content are interchangeable, then Prefix is (probably) a value object. Another rule of thumb is: "Domain first, infrastructure second", i.e., don't let infrastructure concerns (here: primary keys in database tables) influence your domain model.


7

No. (Title edited to ask the opposite question!) eg: Public class MyRepository { public MyObject GetObject(string id) { //get data from the DB and build an object } } or Public class MyService { public MyObject3 ProcessData(MyObject1 obj1, MyObject2 obj2) { //perform a process which is not a sole responsiblity of obj1 ...


7

In the DDD perspective, Category, Product and Property are entities: they all correspond to objects that have their own identity. Option 1: your original design You made Category the root of a single aggregate. On one side, this makes sense, because the aggregate shall ensure consistency when its objects are modified, and Product must have the ...


7

By definition, entities have an identity. This fact, by itself, does not imply that you must have an Id property on your entity objects. If you never need to reference or compare the entity outside of your aggregate, there is not really a need for it. Usually however, it makes sense for every entity to have an Id. Where does the Id come from? Unless you ...


7

It looks like this goes all the way back to SCRIPT which was invented in 1968. roughly speaking, SCRIPT became SCRIPT/VS which became GML which became SGMLguid which became HTML Here is the origonal paper introducing SCRIPT: http://web.mit.edu/smadnick/www/papers/J002.pdf Why choose &? well imagine you are in a terminal window. you have no mouse. you ...


6

Here is one rule of thumb (but don't follow it blindly! Understand why you must use it!) for the direction that your dependencies must follow Always depend in the direction of abstraction and stability What that mean is that the dependencies that everyone depend on must be dependencies that change the less. Everyone depend on them, thus they're costly to ...


6

If you can give the class enough useful functionality to justify the added complexity of not being a string, then do it. For identifiers like ISBN and ISIN, I suspect this is not the case. For an identifier class to be useful, I'd expect it to look something like this: class ISIN { fromCUSIP() fromRawISINString() toString(ISIN::FormatType) ...


6

I would say go for it. I would argue that the advantages outweigh the disadvantages in this case. The extra code is likely to be pretty minimal and the persistence issue can be solved pretty easily be providing some sort of converter between your new Class and the type the database expects (I've never used Entity Framework but I know this is relatively ...


6

Yes, most places I've worked at use some of those libraries. It is tempting to see them as bloat, I for one dislike Entity Framework and tend to 'hand crank' my repositories. But, in fact the Microsoft libraries are very well written and are often complicated because they handle stuff you haven't thought of, or don't need yet. This is especially true of ...


5

I don't know if your status example is real code or here just for the sake of demonstration, but it seems odd to me that you should implement Status as an Entity (not to mention an Aggregate Root) when its ID is a constant defined in code - Constants.Status.OutstandingId. Doesn't that defeat the purpose of "dynamic" statuses you can add as many of as you ...


5

The repository pattern: Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. The Data Mapping layer that you've chosen is Active Record. Ergo, the Repository is that software pattern that provides an additional layer of abstraction between your Active Record pattern and your business domain. ...


5

I think that visualizing something in the real world is helpful when coding classes but not necessary. In fact, depending on how literal you want to be, many objects we work with don't have physical representations at all. For instance--consider MVC architecture. In the real world there is no Model or Controller even though they are generally represented ...


5

Does an object have to represent an entity? Question: Which entity does a Logger represent? Not metaphorically - literally. When explaining OOP to students it is helpful to explain objects with analogies to the physical world. Alan Kay - one of the fathers of OOP - wrote the following: [...] The original conception of it had the following parts....


5

The point of using frameworks compared to hand-rolled solutions is to save work and to reduce risk. A hand rolled custom solution might be more focused and have "less bloat" compared to a generic framework, but it will also: Have more bugs - which only you can fix Have worse documentation, no books or tutorial etc. You cannot google for solutions to common ...


5

As I see it, you can solve this in one of two ways: Category is a special type of product This means for any given product in your database, it contains a foreign key pointing to the very same table product. A product is a product only if there exist no products whose foreign key is equal to the id of said product. In other words, if it has no products ...


5

In any data format, the escaping mechanism must be escaped itself. The escape character is a special character. For example, I want to display this text: Ampersands are escaped like &amp; If I write this HTML as <p>Ampersands are escaped like <code>&amp;</code> it will be displayed as: Ampersands are escaped like & So ...


5

There is no "correct" answer here. It's really about finding the tradeoffs you're happy with. Sharing one model across layers trades coupling for development speed. It will allow you to get your code working faster, but it inherently couples all your layers together. A change to the model in the Service layer will affect the models the API consumer sees. ...


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