Tag Info

New answers tagged

5

First off, the premise is flawed. You most definitely can modify classes at runtime, e.g. in Ruby: class Foo; end foo = Foo.new foo.bar # NoMethodError: undefined method `bar' for #<Foo:0xdeadbeef4815162342> class Foo; def bar; 'Hello' end end foo.bar # => 'Hello' Python: class Foo: pass foo = Foo() foo.bar() # Traceback (most recent call ...


1

Neither is inherently better than the other. Use whichever one is more readable. In your example, where you can get all the values immediately and construct the object in a single object literal expression, I see absolutely no reason not to do just that. If getting each property was a non-trivial exercise, or there are many properties the final object may ...


1

There is no "correct" way of doing this as either will work just fine. It depends entirely upon what makes your code the easiest to write, understand and maintain. If I already know the values of object properties at the time of declaration of the object, I find it generally makes the code a bit more self describing if I just put the known properties ...


2

For the most part, you can write very Java-like code in JavaScript, but it's usually simpler not to. There are two pretty major factors that affect your design: dynamic typing and functional-style callbacks. Dynamic typing means you don't use interfaces, and you don't need to create a lot of those little classes that do nothing else but implement ...


2

This sort of problem is well-suited to dynamic typing. That will give you the most straightforward solution, with the obvious trade offs. If you wish to use static typing, you'll have better luck if you don't centralize your pipeline construction. Your stages are the ones who know the most about the types of their dependencies and results, so you should ...


-2

You might be able to model this using a workflow engine. You can model each of your stage as a workflow step and also parameterize each step. Depending on the engine chosen, manual action can be configured against each step. The following post might help you decide if it is relevant to your use case: ...


3

There's no direct way to do what you're describing. However, you have a few options which will hopefully achieve what you want: Have an interface which contains only the accessors, and not the mutators, and make sure your return type is of the interface rather than the concrete class. Have a way of cloning a class- this might be an external method, or a ...


3

You can make the objects immutable: public class Developer { private final String name; public Developer(String name){ this.name = name; } public String getName(){ return this.name; } } Then there will be no issue with returning the reference. Otherwise you can map each developer to a unmodifiable view of itself: ...


2

This is issue of following the Law of Demeter. In first case, the Main class knows about all the other classes. If it has dependency on all of those classes, then you have to check if Main works properly if you change any of those classes + the one that is using it. If you needed to mock dependencies of Main class, then you would have to mock all of those ...


3

"Red arrows mean it create pointed class as a object and call the method of it." So you did not separate creation from usage? This is pretty much opinionated, but one "recommended" way of creating OO programs, especially when multiple classes are involved, is to make use of dependency injection. One central aspect of DI is: if one object needs another ...


1

I am still years away from fully grasping the distinction between an abstract class and an interface. Every time I think I get a handle on the basic concepts, I go looking on stackexchange and I'm two steps back. But a few thoughts on the topic and the OPs question: First: There are two common explanations of an interface: An interface is a list of ...


3

Short answer: No. Long answer: Think back to the Single Responsibility Principle. An object (or method, or module) should only have one reason to exist. That reason may be large or small, but it is cohesive. A memento exists to manage temporal state. In other words, track state as it changes, to allow moving backward and forward through those states. The ...


0

A question very close to my heart! (see my OOP vs ADM question) Yes I believe that it IS procedural, but only if your UserService Modifies User. for example, consider an Order which has many Items Order.AddItem(Item item) would be OOP surely? but Order.SetItemPrice(Item item, decimal price) where Item has Item.Price, breaks the encapsulation ...


1

I do not see any problem. You have two distinct objects: User and UserService. Both of these have two distinct roles / responsibilities. 1) The User object represents the User in your domain. It responds to questions / messages like age? or firstName?. It is its duty to answer these types of questions. 2) The UserService is distinct from the User. It ...


2

What you are describing is called an Active Record pattern. As Jack points out, there are multiple problems with this pattern, especially in relation to separation of concerns, domain modeling, and testing. If you are using active record, you are assuming the classes are exactly the same as tables and rows in your relational database. This limits your ...


5

One of the principles of object-oriented design is that each object (class) should do only one thing. The User class should know everything about being a user, but that doesn't include knowing where users are stored - that responsibility is for another class (your UserService class). The UserService class should know all about storing users, but it doesn't ...


1

The Wikipedia article for State Pattern has a Java example that illustrates two states, involving two different methods. Those methods can be arbitrarily complex, so I consider a two-state solution (no pun intended) perfectly valid. interface Statelike { void writeName(StateContext context, String name); } class StateLowerCase implements Statelike { ...


2

In some respect you are right: They both refer to the same domainobject, which is called order. But you are wrong in as far, it is not a real duplication than a different representation - originated from different purposes. If you want to persist your order, you e.g. want access to each and every column. But you do not want to leak that to the outside. ...


0

(Disclaimer: I only saw it being used in this way. I might have misunderstood the real purpose of doing so. Treat this answer with suspicion.) Here is another missing bit: the conversion between Order and OrderModel. The Order class is tied to your ORM, while the OrderModel is tied to the design of your View Model. Typically, the two methods will be ...


7

The purpose of the View Model is to provide decoupling in two ways: by providing data in the shape that the View requires (independent of the model), and (especially in MVVM) by pushing some or all of the View logic back from the View to the View Model. In a fully normalized model, Customer would not be represented in the Model by a string, but rather by an ...


16

So am I missing something important here? YES While these look like the same thing, and represent the same thing in the domain, they are not the same (OOP) objects. One is the Order as known by the data storage part of the code. The other is the Order as known by the UI. While it's a pleasant coincidence that these classes have the same properties, ...


1

I think in this case just need some encapsulation and specification pattern: Encapsulate the list in a container, expose only needed methods: public class EntryList { private List<LogEntry> _entries; public EntryList() { _entries = new List<LogEntry>(); } public void AddEntry(LogEntry entry) { ...


1

If you really want to use a design pattern here, you should look at the Visitor pattern. However, as you are iterating only over one data type (LogEntry), I don't see a need to create a separate class for each calculation. I would keep my design simple and use a single class that contains all those calculations as members: public class LogStatistics { ...


3

Is the top-down design methodology I am describing here a valid approach? Does it have a name? Yes, it is called top-down design, and there's a decent Wikipedia article. In particular, you're describing an informal variant where you figure out what you want the library to do and how you want it organized based on how you intend to use it. do teams ...


8

You're describing Acceptance Test-Driven Development. The basic principle behind ATDD is that each software requirement is accompanied by an acceptance test that, when executed, provides proof that the requirement has been satisfied. Acceptance tests are created when the requirements are analyzed and prior to coding. They can be developed ...


0

1) For the sake of clarity, I decided to go with the public call to getConfig(). 2) The config object's responsibility is to get and store data from the db. Therefore, it would be better to have a separate class do the work of bootstrapping the config tables. My code now looks something like: protected override void OnStart(string[] args) { ...


0

Don't confuse OO classes and ontological classifications. You might naively want to classify a mermaid as both human and fish, but the description of the problem suggests that its swimming behaviour results in the composition of its two parts. OO classes are a means of combining state variables and behaviours which operate on those variables, they package up ...


3

A Mermaid is neither a human nor a fish, so I would not try to shoehorn these classes into an inheritance hierarchy: Class Mermaid{ /*some data members go here */ public: void swim() { /*functionality */ } }; Implement "swim" as you like. If you want to reuse some code in all 3 implementations of swim, you could easily do this by creating a fourth ...



Top 50 recent answers are included