Tag Info

New answers tagged

-2

The thing that defines polymorphism is not classes but interfaces. I'm using the term "interface" loosely here, as it can have different meanings in different languages - in Rust it has to be an actual trait(Rust's version of interfaces), in Java classes can serve as interfaces, and in Python interfaces are not an actual language construct but merely ...


3

it feels like somewhere in my code there will have to be something that checks the type or knows about each type even if it is just in an IOC container configuration. The Command Pattern A nod to @Stephen comment. The command pattern decouples the "request" from the requestor. Quoting the linked site: encapsulate a request in an object ...


3

Without the full context it's hard to know the right thing to do. It seems to me though that the ISomeInterface implementers need to do something differently, depending on the implementation. That leads me to believe that your second approach is correct. The thing is, each ISomeInterface implementation can have its own list of dependencies. One could ...


6

short answer: you don't. You can get user input without using a Scanner instance. For example: https://docs.oracle.com/javase/tutorial/essential/io/cl.html or http://alvinalexander.com/blog/post/java/java-source-code-read-command-line-input


33

The answer is "because a scanner has state." Looking at the code for java.util.Scanner, you will see a number of private fields such as a buffer and its associated information, a Matcher, a Pattern, an input source, information about if the source is closed or not, the type of the last thing matched, information about if the last thing was a valid match or ...


3

First of all, I wouldn't approach a clean architecture in PHP. One of the main goals of clean architecture is to allow the user interface to be considered as essentially a plugin to the application, allowing you to change between types of UI easily. By going with PHP you are restricting yourself essentially to web-based interfaces. If you are familiar with a ...


4

Passing in the data structure will prevent a potential bug that can occur when a the constructor of a base class calls an abstract method defined by the child class. This potential bug occurs when the child class has a member variable that is initialized in the constructor. Then, the implementation of the abstract method assumes that member variable has ...


0

You are simply lacking something called ORM - either via a Framework or (only in some use cases recommended) handcrafted. Via ORM you define the Entity Relationships via code (e.g. 1 Order <-> n OrderPositions). And if you are using a framework the magic begins: you are able to resolve in one coded query all/most relationships which are needed - Little ...


0

So by the sounds of it you have an anemic domain model http://www.martinfowler.com/bliki/AnemicDomainModel.html This is a problem because you have objects that aren't actually doing anything other than holding data, but you have all the overhead of classes and objects without any behaviour. If you can't figure out what your objects are doing other than ...


2

Ask yourself this, if you separate out the members into separate classes, are the classes doing any meaningful independent work? If the classes are co-dependent, and can do nothing without access to the other members then its probably a bad idea to separate them out. On the other hand, if one class can meaningfully lessen the workload of the other class or ...


0

As always, it depends. I don't see why would it be wrong. I had classes with as many fields, maybe even more, in a project which scrapped data from a website, so one page was one object (lots of data + some calculated values to speed up things across multiple runs). They were perfectly related to each other. If fields contained in one class have little to ...


15

I guess it comes down to which is the greater evil, too many Objects or too many fields in an Object. It depends. The greater evil is having classes do too many things or too many classes for one thing. In your example, it looks like you have three distinct groupings that have nothing to do with each other. So those shouldn't be the same class. But if ...


5

The important figure is complexity, not pure object/member count. You can have a simple class with roughly up to 20 members (that's already really smelly, though), and you can have a much too complex class with only five. Anyway, just grouping members by type won't help. The questions are: Which members have to work together? And, which sub-services can ...


5

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 ...


0

Given that you're using Rails, the most common way to achieve what you're trying to do is to use a before_save or before_create ActiveRecord callback. class Model < AR::Base before_save :normalize_attributes private def normalize_attributes # Whatever logic you need end end my_object.attr_a = get_the_stuff_from(ref_one) my_object.attr_b = ...


1

If memory serves, the reasons for developing the technique of encapsulating members with accessor/mutator pairs are due to some historical problems associated with maintenance and quality control. As a programs grows, is maintained, and new features added, some of the particular problems are: A bug emerges where the value of the member is incorrect, but ...


11

The problem you are addressing is quite fundamental. I have experienced the same problem when I worked for a company that made a large J2EE application that consisted of several hundred web pages and over a million and a half lines of Java code. This code used ORM (JPA) for persistence. This problem get worse when you use 3rd party technologies in every ...


7

The problem you facing is an old one: code for persistent objects often looks similar for each class, it is simply boilerplate code. That's why some smart people invented Object Relational Mappers - they solve exactly that problem. See this former SO post for a list of ORMs for PHP. When existing ORMs do not suffer your needs, there is also an alternative: ...


2

The benefit of immutability is that it doesn't matter as much what you do with your references to it. Globals, static classes, and singletons are much less problematic than their mutable counterparts, because you don't have to synchronize mutations and track the order dependencies that creates. However, they still have the issues with mocking out for unit ...


-2

(This entry is a wiki. Please feel free to improve this answer) Here is argumented how using static for immutable might be preferable, and related concepts. Constants themselves are defined as global. Objects that wont change not only during runtime, but wont have alternatives values (like a filesystem path might change depending configuration) a priori ...


4

Fundamentally, there's no problem described in the question that actually needs a solution. You've given no reason for a Foo holder to exist, or what it should be able to do. So really, FooList is completely useless. If you need a Foo, there's a language feature for that- new Foo(1). There's no reason for any additional holding to be baked in to the Foo ...


7

The problem is that you've effectively created a global variable for accessing these objects, the Foolist class. This has drawbacks for things like testability and is in general just poor design. Global state doesn't help make code easy to read and the consuming classes can never be isolated from the Foos (look up mocking) d when testing. Avoid the static ...


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) ...


4

The service shouldn't make any decisions or you end up with a anemic domain model. Your license aggregate should make the decisions. If the license aggregate needs to call a web service you pass an instance of a helper for that service to the method on the aggregate. It can them choose to use them if it so wishes.


0

Ideally the bank application should worry more about the account than the customer. For example, the bank should have methods like addAccount() : which will add account and create a customer implicitly if it is the first account of the customer and deleteAccount() : which will delete the account and delete the customer implicitly if it is the last ...


1

At first glance, your 'clear' approach does look compact and clean, but if you were to unravel the statements... // PHP? public function effective() { $nonGroup = !$this->org->isGroup(); $hasParent = false; if ($nonGroup) { $hasParent = ($parent = $this->org->getParentOrg()) instanceof OrgModel; } $inherits = false; ...


3

This seems to disregard the nice and simple: return complicated_test_1() && complicated_test_2() && complicated_test_3(); This is certainly simpler than either of your options, and I assume you rejected it because: the complicated_test are not single function calls, but themselves Boolean expressions But this is a self-inflicted ...


1

Should, for example, each tile store the data of its reward or there should be a reward manager for checking how many tiles are consecutive next to each other to give the reward to the player? How I would do it You have a Reel object that can be spun randomly You have a number of Reward objects that have a threshold required to win, and a prize amount ...


1

I am trying to understand how to design classes which take an input, do some processing, and return a result. There is a principle in object orientated design called "Tell, don't ask" What this generally means is you tell an object to change itself, you don't ask an object for data that you then manipulate some where else. So when thinking about how ...


0

If removeHeaderFooterText is an atomic operation, then the solution is simple. Your class for implementing the algorithm will have one public entry point. In pseudo code, it would look something like this: class HeaderFooterFilter { public removeHeaderFooterText(pages); }; No caller should ever be concerned with how removeHeaderFooterText works. All ...


3

Before discussion, notice that When given a business use case, object-oriented programmers can usually arrive at some consensus about how the surface design (the partitioning of responsibilities between classes, and the publicly accessible methods and properties of these classes) should look like. On the other hand, when given an algorithm, ...


2

There is nothing wrong with writing pure functions as statics in object oriented programming. Given your example, it does not appear necessary to make instance fields out of the intermediate results. However, you should be prepared to refactor when and if necessary, into a real object. Several reasons you may need to do that are: You choose to define ...


2

I would suggest to avoid using this as a formal name in C, because this is a C++ keyword. You could use e.g. self (or me or recv, or ipse -it is self in Latin) instead of this If you code your C code without using C++ keywords, you are much more likely to be able to use your code with a C++ compiler. In particular, quite often a C header file foo.h (with ...


7

If they are supposed to be singletons, and you really want to do things in your (conceptual) style, you might want to use Context object. (First and foremost: apologies. C is not my native language; C++ is.) Basically, struct Context { Engine * engine; Window * window; // any other things that are considered singletons // according to ...


2

if it is the same, it should look the same This is not how naming works. Your are the same however people call you. Granted, you have a name on a birth certificate, but that is not sufficient. You are John Doe, yes, but the one who lives at such and such place, who was born that year. Someone might call you son, and someone else dad, whereas I call you ...


-2

Object Oriented Modeling, its used to represent the real world in a Software Application. In other times, a single account, had only, and only one customer, assigned. These days, several customers, can be assigned and removed from an account. There are many ways to model an application, so there is not really a "100% bad" or "100% good" way. Your example ...


3

This seems like a classical Has Many/Belongs To relationship type. What we usually do is kind of a merge between your 2 options, where: A Customer has a list of the many Accounts he has. An Account has a reference to the Customer it belongs to. That being said, @James Anderson is accurate as he states the importance of customers rather than the account ...


6

Oh Dear. Your design is how bank applications were designed in the 1970s. Myself and several thousand professionals have spent decades undoing this design error to get systems looking more like option 1. Banks deal with customers the account is just a mechanism for dealing with some of the customers money. More importantly the stack of regulators who ...


1

This is a very similar approach I've take using Amazon SQS, with a few differences to overcome a few potential downsides; if a message becomes available just after you check, you'll be waiting 100 seconds before taking another peek, which is not particularly responsive. If many messages arrive in quick succession, you may not be able to keep up with them ...


2

In general, when you are doing object oriented programming, you want your data and behavior to be together (in one class). You also want to achieve high cohesion with your classes. This means that most/all of your methods use most/all of the attributes in your class. This will help you achieve the single responsibility principle. Low cohesion means that ...


1

Classes are often used for concepts, to hold together all the attributes of the concept and the interactions that are possible. When deciding what to do however, it's purely a matter of what works best, and what design is the best. When you are deciding what to do I'd go about it this way: If the calculation is part of the (to be) object, make a class for ...


3

You don't expose what the user doesn't need to know. If the main interface is just DList, then you should not expose DListNode to the user of your class(es). You may make DListNode a private class, which is manipulated internally by DList only. In the case of iterating through your list, e.g. next(), you may move this to an enumerator or iterator like ...


1

You can add an attribute myDList to the class DListNode and implement a method like next in the following manner: public DListNode next(DListNode node) { if (node == null) return null; if(node.getMyDList()!=this) throw // ...some exception here if (node.getNext() == this.sentinel) return null; return node.getNext(); } That ...


1

Your major problem comes from the user passing a node that do not belong to the list, as you said in your comment: [...] if the user passes node of list1 to list2 by saying list2.someMethod(nodeOfList1) You could try to avoid letting the user manipulate nodes, in which case you would need an indirect way to access them, but this pushes the problem ...


4

You can consider allowing your callers to pass in DoubleDuple. (To save some typing, below I will use Vec2 in place of DoubleDuple.) Example: public class Vec2 { public final double x; public final double y; public Vec2(double x, double y) { this.x = x; this.y = y; } public Vec2 add(Vec2 other) { return new ...


2

Object-oriented programming can be interpreted as message passing: objects are independent actors to which we can send messages (that is, we can invoke methods on that object). E.g. here I send the panel object a layoutYourself message: panel.layoutYourself(); Some languages make this message sending more visible by using special message send operators. ...


0

First of all, have you tried to ask your co-worker what would be the benefits of his approach ? From my point of view, the only advantage of having a singleton (and basically object methods) is to ensure that later on, you will be able to extend those functions (or to mock them), and change the behavior of code that relies on it. This is especially useful if ...


3

C#3+: internal class DataServiceAdapter : IDataService { public bool Method() { return Using(s => s.Method()); } public int Method2(string arg) { return Using(s => s.Method2(arg)); } private static TRes Using<TRes>(Func<SpecifiDataService, TRes> func) { using (var something = new ...


2

I would leave them completely separate. Services and servers (notice I carefully separate the abstracted hardware and the abstracted software) are separate things. I would let each Service object have one Remote (or VMInstance or whatever you want to call it) property, possibly passed in a contructor, that could potentially be changeable (service ...


0

It seems to me like "remote" is a property of an object, not something which defines it. In other words, have you thought about using composition rather than inheritance? For example, an AWSRemote is really a VM and a Remote, and a DB2Server could either be a specific VM or a physical machine, either locally or remotely. A DB2Server constructor could for ...



Top 50 recent answers are included