Tag Info

New answers tagged

2

In all cases, I'd prefer #5. In the 1-2-3-4 sample of code, I think that the domain object doesn't have to know DTO objects related to him. Let's say you have public class User { ... some properties ... } public class UserThumbnail { ... some properties ... } A Domain Model object (User) doesn't have to know that a DTO object (UserThumbnail) ...


1

Normally I'd prefer #3 - GetBar is very obvious where its come from and what you're getting, but for this case, mapping classes I would often use the conversion operator. But.. mapping doesn't seem like you're casting, you're really creating something new that is not contained within the object (where I'd use GetBar), just converting it (operator bar). So ...


0

my perspective is that the purpose of an object should be to contain data. Yes, but that's not all. Standard protocol in object oriented design seems to be to include business logic in class definitions. Not protocol. It's central to Object Orientation. Data + Operations. The problems, as I see them, start when processes are bound to an ...


1

There are two points to say about this. In some cases thinking about processes as belonging to objects makes understanding the system indeed easier. The objects become responsible for their own processes. Unfortunately most object-oriented programming languages do not support multi-methods, i.e. the dispatch is only dynamic in regard to one parameter ...


0

I understand that the case of equals is just an example and that your approach is about any logic besides simple getters and setters. I see some serious problems/limitations with what you propose: That "general equals" method should reside in an utility class. That class would need to be changed every time a class is added to the system ( if you will ever ...


2

First, what you are describing sounds quite a lot like functional approach to things. Separating data and functions operating on those data is modus operandi of all functional language. Try looking at Haskell for inspiration. Second thing that I see is that you seem to lack concept of abstraction. If you have identified multiple classes, which have same or ...


0

To me, any given object has a sort of behavioral profile which is the domain and/or scope of varying functions it can participate in. The breadth and character of this behavioral profile will vary widely depending on the object. Object oriented design certainly has some relation with cognitive science, since it is concerned with how the programmer models the ...


0

Don't subclass shelve.Self, instead define a new class with a constructor that that calls shelve.open. Implement the method of interest by calling the actual methods on the returned shelf object.


3

By some definitions, a class is a type (or a structure) that provides implementation and interface (assuming it's not an abstract class) for some specific sub-set of a problem. With that in mind we can say that most sensible way of organizing and naming class would be to divide them logically. In your given example the classes could be: Message Session ...


2

tl;dr - I think you're going to want to inject state objects at each level of state as appropriate. Reason being, as your application scales and you add in more controllers you're going to want to control which controllers talk with which other ones. And the first approach you suggested will position you better to support that. To help illustrate ...


0

What will go wrong if a class object reference would have access to the static member? It is not the reference that matters, a reference is for you to know what instances your dealing with. static members work like this; they are part of a class, but they are not part of an instance derived from that class. I understand this is the way it works. But ...


3

Nothing go wrong for accessing a static member from an instance, in fact this is perfectly posible in other languages like java, you example code compile and runs ok if its in java. Its a check the compiler designers introduce because they think this helps programmers to write clear code with this language. This way only looking at the code you can always ...


-1

static exists so code that is class related, but not tied to a specific object, can be stored in a reasonable scope. Think about serialization, equality checks, casts and the like. Also your house does have access to the field, just that it also needs to address it as BluePrint.BluePrintCreatorName Furthermore you could have a member of the same name in the ...


1

I would recommend using composition instead of inheritance in this scenario. Also, I would reverse the model to match the logical flow of control. A HumanState can contain member variables for the HandStates. In this way, you have a logical composition of elements. HumanState -> --> contains HandState x2 --> contains HeadState x1 --> ...


2

It depends if the default value is the right value or not. I see that pattern way too often when it just happens to be the fastest way to make a particular use case work. It just makes it harder to debug other use cases down the road. What do I mean by the default value being the right value? Well, take an integer field for example. What should it ...


2

My question is whether this violates any general 'best practices' of development or object oriented programming ideals? Sometimes it does. Sometimes, accessing a column that doesn't exist is a clear disconnect between the implied contract that is implemented by the data reader between the calling code and the data source. If it is a clearly a problem, ...


1

No, it is not a good idea in general. It is a very bad idea. For SOME things, it will be OK to return a default value, but this has to be resolved on a case-by-case basis for that particular thing. In order be able to do that case-by-case resolution, you have to provide for the case where it is NOT OK to return a default value. Consider for example an ...


1

Prefer pure functions and immutable variables/objects. Apart from that, keep in mind the limits and the conventions of the language you are using. Don't forget: Readability. Your colleagues will find your non-idiomatic code harder to understand Lack of tail call optimization Lack of laziness Lack of useful optimizations (ex. stream fusion) Lack of ...


10

Mutable state is easily avoidable using immutable objects. In the same way, global variables are usually the choice of the developer (or a poorly implemented framework). This being said, you may also want to use additional functional paradigms in non-functional languages. It's all about the expressiveness of your code. If you see that a list comprehension ...


2

How can I write solid functional code that does not allow side effects even in languages that have mutable state and global variables? The simple answer is, do not use global or mutable variables, or just because you can mutate them does not mean you have to. Consider a class like this: class ImmutableClass { private int myImmutableField; ...


1

First, the recommendations: Use a simple file-based in-proc DB such as H2 DB or SQLite. This is almost as convenient as an XML file - you can keep using the same workflow as you have today. It also future-proofs your software to an extent. EDIT: If you feel that using a relational DB is overkill, I would still recommend using immutable model objects with a ...


0

DDD is about modeling the business cases. It has nothing to do with how the entities and relations are persisted. DDD was actually conceived in time when ORM was not much used and when you read the original DDD book, you will notice they talk a lot about using pure SQL for persistence. That is why Repositories in DDD exist. Just because you don't persist the ...


6

Looks like the purpose of the model is missing from the picture. DDD is not about modelling reality: it's about discovering the model which is the best fit for the specific purpose. Design patterns will eventually follow.


2

As usual, there is no definite answer for how you must model something. Everything that is valid according to whatever modeling language you apply is available and can potentially be used that way. That being said, intermediate states are nothing out of the ordinary. I even have to correct the comment made by @rwong, that a state remains unchanged in the ...


2

Try to think of it the other way around: If you had to drive from A to B and you didn't care about the roads you use or the time you get there, you might just take a Car, Accelerate() it, and Stop() whenever you're there. So, an abstract kind of Car will easily suffice for the purpose. I imagine many people would use that Car while they don't actually care ...


0

Forget about design right now. Your idea for the system is too ill-formed to decide on low-level design details like class inheritance. Instead decide on some exact use cases and implement them. Then implement some more use cases. Continuously refactor the code to eliminate duplication. Introduce interfaces to eliminate circular dependencies. When it ...


2

A player: Stupid, Smart, or Human Player is an interface and Stupid, Smart, or Human are concrete classes OR Player is an Abstract Class and Stupid, Smart, or Human are concrete classes The interface or abstract class Player would contain everything a Player should do. The concretes would implement Player behavior and extend it specific to Stupid, Smart, ...



Top 50 recent answers are included