New answers tagged object-oriented
1
I think you have two very different cases here:
A null-check. This should throw as soon as possible, because it is a bug in your program. That string will never become non-null, there is no way to recover or change. This is just wrong and should be caught immediately. There is no point in continuing with this broken class if the file is null. Please throw ...
6
Let me step away from your actual File I/O example, as you have noticed by yourself, this introduces aspects to your question you did not intend to ask here.
My answer to your general question is: don't take the idea "limiting constructor logic" too literal!
If the constructor of an object cannot initialize the object properly, throwing an exception is the ...
0
You use an abstract class if you want to use it as the baseclass for one or more non-abstract classes. Usually your abstract class will have quite a few method implementations already there. You will end up with a class hierarchy, with the abstract base class at the bottom hierarchy.
You use an interface to describe which methods a class should have. You ...
0
In this case, would it be acceptable to do a check for file existence in the constructor?
No.
Frankly, it's not acceptable to do the null check in the constructor.
(Why? Because very few people know what the behavior is when you throw from a constructor. Is the object created? Can you use it safely? What about if the constructor is in the middle of a ...
10
I deeply believe in fail fast myself. In addition to promoting system integrity it helps debugging devs by getting them as close to the cause of the issue as possible so they don't have to slog through file after file trying to figure out where a bad value came from.
However, file I/O is not something you should pretend you control. You don't. You're never ...
0
Seems like the provider class should expose a method that actually does the providing and error checking.
Then your class and constructor can be nice and simple (or just take in whatever other dependencies are needed) and not have any side effects. This also lets you add other methods to the class to support different data types or functionality without ...
0
I have never heard of fail fast as a software design principle. I view fail fast as a project or organisational strategy where one wants to learn of project failures as early as possible so one can course correct or abort while limiting the cost of having gone in the wrong direction. It's a risk mitigation strategy when there are a lot of unknowns.
I will ...
0
Abstract class contains abstract method (Only declarations) and concrete method (Implemented method).
Interface contains only and only abstract method(declarations method).
Where to use and when to use.
Suppose if you have a interface
Interface engine{
getEngineSpeed();
getEngineRPM();
getTypeofEngine();
}
Now lets you have 3 different ...
18
Coupling
ClassA relies upon the interface only, delegating this responsibility of passing the classB object elsewhere
This is the idea. If you are separating ClassA from ClassB by the use of an interface ISomeInterface...
ensuring (ClassA) doesn't know ClassB
Then you do not want ClassA to ...
21
Your confusion is probably caused by focussing on meaningless class and interface names, with no real usage scenario behind it. So better let us make a concrete example (I prefer C#, but it is not really different in other languages like Java).
The IComparable interface in the .NET framework looks (simplified) like this:
interface IComparable
{
int ...
1
Unfortunately, there is no one size fits all answer.
Monkey patching is not generally a good idea as it places logic in places people don't think to look, especially new people who are looking at the API docs and trying to figure out where the split method is. However, there could be a very good reason to do it. For example if you think you're going to use ...
0
If I remember right ADTs are abstract types. This means they are not expressed or implemented in any language. Java interface is already a specific representation of some possible abstract Iterator written or depicted on paper, on desk or as part of UML diagram for example.
But java.util.Iterator is definitely a very close representation of what possible ...
1
So, may I state that an Iterator is an abstract data type?
An ADT is a collection of data and a set of operations that may be performed on that data. An iterator is composed of a set of data to iterate and a set of operations for performing that iteration. Importantly, those operations do not define how the operator is performed. So an iterator - in general ...
2
There's an equivalence between your getSomething method and an abstract class. Both are examples of the Strategy Pattern.
public abstract class SomethingGetter<R, MSGIN, MSGOUT> {
abstract MSGOUT query(MSGIN in);
abstract List<R> getResults(MSGOUT out);
public SomeClass<R> run(MSGIN query) {
//some logic here
...
6
A Tale of Abstractions
There's a lot of confusion about this on the Internet, but the term is quite technical, and according to the Cook paper (referenced in the answer liked to by Greg Burghardt), it essentially boils down to this.
OOP Objects (and the related static typing mechanisms, including classes, abstract classes and interface types) and ADTs ...
2
A. They're used to describe the API of various classes.
Correct.
I struggle with the correctness of the phrasing. It's not wrong, but it is essentially a confusing tautology. But they had to avoid calling it "the interface" to not give away the answer, and I'm struggling to find a better (and similarly terse) alternative.
B. They're used to avoid ...
0
call the Client.Send(ReplyMessage) function directly from the Handle()
This goes against the principles of loose coupling and separation of concerns, so what you called centralized approach is IMO a cleaner design:
Client.Receive(request)
response = message.Handle()
Client.Send(response)
message is a Message attribute of Client whose concrete class (one ...
1
As written i.e. you always need to send a reply, then the centralised approach is probably slightly neater. I can see two potential benefits:
the common workflow (receive, handle, send) is all in one place;
the handle methods, the main locus of variability, may be easier to test independently from the architecture.
The first benefit is fairly minor given ...
1
Its unclear to me exactly what you are trying to do. I would have this:
public function add(Package $p)
{
$this->packages[$p.name] = $p;
}
class Package
{
public $Name
public $Style
public $Categorized
}
0
If someone else needs to call a method, it must be public. If nobody else needs to call it, you make it private. And the opposite of course: Only code inside your class can call private methods; anyone can call public methods.
Imagine your boss tells you what your class needs to be able to do, and how and with which interface this functionality is called. ...
0
If you want either inherit these methods in derived class or reuse by other classes then declare them as Public. And if you protect it from being used by any other class then declare them as Private.
Because methods that are private can only be called by methods within the same class or within the same "module". Methods are not commonly made private; usually ...
0
I'd say the problem here is the concept of the FieldGrid as an array of Tiles.
You limit yourself to a classic implementation of the game where the UI, an ascii display, is tightly coupled to the game itself
Fine if that what you want, but then you don't really need the Snake class. The snake is just the collection of SnakeTiles.
A more modern design ...
2
You are at the right place for a review of your design. But this is not a code review site, so don't expect an in-depth inspection here.
Overview
What strikes me first looking at the classes is that:
there is no relation between the Snake and either FieldGrid or Tile: it feels hard to believe that both could be as independent as this diagram suggests, ...
28
The problem
The purpose of having these result classes derive from the same interface is so that the interface becomes what the consumer knows and works with. The consumer doesn't care about the specific implementing classes.
However, your interface doesn't contain anything. You're using it as a marker interface. If I, as a consumer, receive an ...
5
This is a long but very interesting question, where you have exposed your step by step research.
To summarize the problem:
IService does some processing and returns an IOperationResult
Different post-result actions need to be performed depending on IOperationResult
Actions cannot be implemented polymorphically in IOperationResult because concrete ...
5
It seems to me that you are massively over complicating your life in this example by not using Exceptions instead of your IOperationResult interface.
Simply throw a ValidationException or APIErrorException in your Service and handle with try catch as usual.
Furthermore, say you did that, I would then say you should not be exposing the internals of your ...
0
Like others mentioned, on one hand equality is just a mathematical concept satisfying some properties (see e.g. Albuquerque's answer). On the other hand its semantic and implementation is determined by the context.
Regardless of the implementation details, take for example a class representing arithmetic expressions (like (1 + 3) * 5).
If you implement an ...
4
I'm not sure that the visitor solves the "expression problem". But your understanding is correct:
You can derive new visitors based on the abstract visitor. This allows to define new operations that will work on all visited elements.
But if you add to the visited's object structure an element of a new type, you'll need to update the abstract visitor and ...
0
I think this is an interesting question, that not many people are aware of even asking.
From a general software perspective, I like to see it as follows:
Behaviour drives state, and state can potentially drive behaviour
It is a two-way relationship, because certain actions can trigger certain flows to be executed, while within some flows, certain actions ...
11
Behaviour is decisions being made.
State is decisions being remembered.
When OOP people talk about behaviour what they mean is the gooey sticky part of the code base that has to be changed every time a business rule changes. Rather than state what this is usually contrasted with is dry structural cerimonial code that exists mostly because the system or ...
4
There are multiple layers to the answer.
On the technical level, state is simply the instance variables of an object, and behavior are the methods. Both of these can be extended to other granularity units, like a group of objects or the whole system. Should be clear from the context.
On the semantic ("meaning") level, specifically for object-orientation, ...
5
If I'm understanding correctly, you want to support some operations on the inner array, but not others. If this set of supported operations is general enough for a D2ArrayWrapper to make sense, then I would suggest using an interface.
For example, let's say you want people to be able to read cells and rows from the array, but not write them:
interface ...
0
Three out of two of your classes don't have behavior. In an object-oriented setting this is not ok. Objects without behavior are just data records, which are unwelcome in OO.
Regarding boundaries, those are for external systems (mostly), there is usually no reason to introduce them inside an application. I.e. if you want to present your object on the ui, ...
1
To get a different allocation than everybody the same portion, you can extend the IFighter interface with a Share property, which indicates (in a double) what portion of the gold should be given to that party member. A value of 1 should be the default and if everybody has a share of 1, then they all get an equal portion (give or take the left overs after ...
2
You are trying to use the entity-control-boundary analysis to design an MVC architecture.
Indeed, all the classes in your diagram belong to the „logical domain“, so are entities in the ECB logic, and model in the MVC.
The boundary classes would be the GUI classes that interact with the user. They are indeed missing in the original diagram.
But be ...
3
I would not put any "setter" for Gold into IFighter, and only implement a setter for this property in the Person class, not in the Group class.
The amount of Gold for a group is the total sum of all the gold of all group members, that makes sense. But when gold is assigned to a group, how it is distributed specificially to each person is specific game ...
1
Your question is very general. So will be my answer.
The easiest way would be to write the implemented method to cover the special cases. It it's complex, you may delegate the execution to more specialised function (that can be outside the interface). But if it were that simple you wouldn't probably ask.
Another way could be :
to implement your ...
0
The method that implements the interface will do exactly what the code that you put into the method does. So if you want the instances of your class to do something different when the interface method is called, you just do it.
Some interface methods are explicitely defined to work that way. For example, in iOS a UIViewController has an interface method ...
4
What do you guys think about using interfaces just for
Adding a language element to a program makes it more complex. What we should strive for is the least complex program to fulfill all the requirements. Because that should be the easiest to write, to understand, modify, bugfix and generally speaking "produce and maintain".
So if I can go and remove your ...
1
If your question is if
instance variables that are updatable from the interface
are candidates for becoming extrinsic state, whilst
class variables + instance variables that are not updatable from the interface
are candidates for becoming intrinsic state of a flyweight object, I would say that it may be sometimes the case, but not necessarily:
...
0
Your understanding is basically correct. An example of the proper use of Flyweight model would be with Java Swing's JTable and the cell renderer (example). The idea is that there are a finite number of cell renderers. Information from the table is passed in to the renderer to calculate what should be done there.
In this example, all the extrinsic state ...
0
Equality is subtle to get right and its importance is deceptively far-reaching. Especially in languages where implementing an equality operator suddenly means that your object is supposed to play nice with sets and maps.
In the overwhelming majority of cases, equality should be identity, meaning an object is equal to another if and only if it is the same ...
1
It depends.
Is it a good idea ... ? It depends. It can be a good idea, if you are developing an application that will be used only once, for instance,
in a univercity assignment (if you are going to throw the code away after assignment reviewed), or some migration utility
(you migrate the legacy data once and don't need the utility any more).
But in the ...
0
As others have mentioned, the exact semantics of object equality are a part of the business domain's definition. In this case, I don't think it's reasonable to have a "general" object like Address (containing number, street, city, zipcode) to having a very narrow definition of equality (which, as others have mentioned, works in Brazil but not in the US, for ...
2
Although many answers were given, my opinion still isn't present.
I was once taught that the equals method should only be doing an exact comparison between the objects
Apart from what rules say, this definition is what people assume from their intiution when they talk about equality. Some answers say equality depends on context. They are right in a sense ...
3
Prefer early composition over late inheritance:
The class of an object has to be known at creation, and most languages do not allow to change it later. So, if you create a transaction, it IS a Transaction (inheritance);
If the object has to change afterwards, it must be via its state: the transaction may HAVE some properties/behaviors depending on the ...
2
There are a couple of fundamental ideas behind this.
Object-Oriented Purity
The first fundamental idea is that in Object-Oriented Programming, we program by composing systems of autonomous objects that collaborate by sending messages to each other.
However, an if statement is not a message send, therefore, it is not Object-Oriented.
Dynamic runtime-...
42
It is in the context of the university assignment where the task purpose is to explore and understand operator overriding. This seems like an example assignment that has enough implied purpose to make it appear as a worthwhile exercise at the time.
However, if this was a code review by me I would mark this up as a significant design flaw.
The problem is ...
3
An equality operator will claim that two objects are equal if and only if they should be considered equal, due to whatever considerations that you find useful.
I’ll repeat that: Due to whatever considerations that you find useful.
The software developer is in the driver’s seat here. Apart from being consistent with obvious requirements (a=a, a=b implies ...
25
Equality is a matter of context. Whether or not two objects are considered to be equal is as much a question of context as it is of the two objects involved.
So, if in your context it makes sense to ignore city and street, then there is no problem to implement equality solely based on ZIP code and number. (As was pointed out in one of the comments, ZIP ...
Top 50 recent answers are included
