Hot answers tagged

10

If you honestly, truly need a component as general as a JButton, then you should just use inheritance. "Favor composition over inheritance" doesn't mean "never use inheritance." However, people made that buzzword phrase because 95% of the time when beginners think they need inheritance, they don't. 95% of the time, you don't actually need a component as ...


9

Is it better to expose or hide dependency in OOP? It's best to do both. Before I explain that let me explore the problems with your proposals. Let's say I have an object A, which is too big(having too many methods and variables). So, I break it down to smaller objects. This is good. Always break objects down until they have only one ...


8

The first approach is much, much better than the second approach. The most important quality of software is readability, since the number of times we may write and re-write a line of code is much smaller than the number of times we may read a line of code. (Do you ever write code and then never read it again? I hope not. And before you re-write a line ...


7

I agree that it is totally okay if a class has only one method, but recently I have read many blogs saying this is bad OOP and rather procedural coding. If a class has only one method, it's usually Execute(), or something equivalent. The question you have to ask yourself is, what are you encapsulating by using a class, if you only have one method? That's ...


7

This is a more well-formed transcription of my initial comment under your question. The answers to questions addressed by the OP may be found at the bottom of this answer. Also please check the important note located at the same place. What you are currently describing, Sipo, is a design pattern called Active record. As with everything, even this one has ...


6

Stop worrying about efficiency and start concerning yourself with creating a good abstraction that is applicable to the domain and complete to the client/user/caller's needs. To do this, we first identify what capabilities client/user/caller needs. Generally speaking, for a good abstraction, all these capabilities need to be found together or else the ...


6

It's not really a question of which is preferred. They are different solutions to different problems. You would do this if a C is an A and a B: public class C implements A, B { ... } You would do this if a C shares some of the behavior of A and B, but is not an A or a B: public class C { private A a; private B b; } This decision should be ...


5

You could call the class a Facade for the database and key/value dictionary. A facade is a class which encapsulates operations which consist of multiple complex calls to different objects behind a single object with a much simpler interface.


5

In most cases, there won't be a noticeable difference (unless you have the obvious case with method parameters named the same as member variables). But beware of templates! template <typename T> struct Base { int i; }; template <typename T> struct Derived : public Base<T> { int get_i() { return i; } }; This will cause a ...


5

There's a couple of ways you can do this: You can use isinstance to determine what the object's class is: if isinstance(foo, bar): do_something() elif isinstance(foo, baz): do_something_else() else: default_behavior() However, this gets unwieldy quickly with a large number of possible classes, and isn't good OOP. The OOP way would be to use ...


4

But I know that throughout my application, the tolerance will be constant. This is a bit suspect because such tolerance is usually very algorithm specific. I've had to deal with much pain because someone thought that it they could get away with using a constant tolerance everywhere. But assuming, that you really do want this, I might do: public class ...


3

You are trying to create a layered design. In the top layer are inputs & outputs that interact with the elevator riders: the inputs are the button panel in the elevator and the displays of what floor it's on along with the up/down indicator and button pressed indicators. Further there are up/down call buttons on each floor (and a duplication of the ...


3

This is just Robert Martin being a bit flowery in his writing. Prior to Martin's work, a simple change in the program meant replacing all 32 EEPROM chips. By using pointers to functions, each of the 32 chips became independent of one another. That's all it means.


3

Instantiating and collecting small, short-lived, temporary objects, is perfectly fine. It is what modern garbage collectors are good at. Modern (generational) garbage collectors are built on a couple of assumptions: most objects die young, most objects are small, most objects don't escape, most objects are immutable, older objects don't contain references ...


2

Virtual inheritance Virtual inheritance is a technique to solve the problem of the diamond of death that can arise when via multiple inheritance you can inherit the same base class several times. For example, suppose you have a class Person, and two derived classes of it: Student and Employee. Now you can have a class StudentWorker that inherits from ...


2

According to the Open/Close Principe (OCP): Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. Let's examine your static factory architecture under this perspective: Imagine that we want to extend our design horizontally with a subclass ProductThree. How could the makeProduct() ...


2

The reason you don't see static factory methods listed in the GoF book is because this pattern doesn't use polymorphism in any interesting way. Your diagram suggests this, but most languages do not support the structure it shows. Specifically, a static method cannot also be virtual. There is no instance object to dispatch on. It is not possible to override a ...


2

While there is some logic in having the methods that do some operations with bill history in the CustomerAccount (or Bill) class, one might argue that having them there breaks the SRP. You could say that CustomerAccount class should be responsible only for maintaining the account data (adding, deleting or modifying that data). Reporting could be seen as a ...


2

I think the worst part of the interface is the fact that there is temporal coupling. Clients of the interface are expected to call methods in the right order, and this order isn't enforced by the type system, so it can only be infered by trial-and-error or by pre-existing domain knowledge. My initial thought is to keep a clean separate interface for the ...


2

First create an employee struct containing the properties of the conceptual employee. Then create a database with matching table structure, say for example mssql Then create a employee repository For that database EmployeeRepoMsSql with the various CRUD operations you require. Then create an IEmployeeRepo interface exposing the CRUD operations Then ...


2

If Cycle belongs to a particular ScholarshipProgram only, then it should belong to the ScholarshipProgram aggregate. If a Cycle can be part of two or more ScholarshipProgram, Cycle should be its own aggregate root. In any case the aggregate root is your entry point. In the first case that means that ScholarshipProgram would have the methods to manage Cycles ...


2

A grayscale bitmap can be colored just fine. Some other image file formats will have to be re-encoded if they suddenly stop being grayscale. If the user tries to turn your grayscale image into sepia tone you have to decide wether to let them or to tell them no. Similarly, you will have to decide how to react when requested methods are not valid with your ...


2

Premature Over-Engineering For example, I assert that you do not need any of those interfaces. If needed later, make them later. An interface (the C# keyword kind) is for giving common behavior to unrelated classes and then handle objects polymorphically. Think more carefully about what constitutes a more specific class. Think of what a shopping cart IS. ...


2

I don't see where a conceptual object is involved in performing string-to-binary conversions. That's a process, and using an object for it doesn't make sense in the general case. That being said, there are reasons for wrapping a process up in an object. But these primarily have to do with state. For example, if multiple executions of the process will update ...


2

Consider separating use from construction. Foo foo = new FooInjector(f1).build(); Now making Foo immutable is trivial. Now I can look at Foo's behavior without being distracted by f# construction. Sure Foo has a long constructor to handle but that's hidden in FooInjector, not spread throughout the code base. If you find many classes (besides just Foo) ...


2

One approach that might fit is a finite state machine. There are tools that help you build and visualize them but you can also model it with standard OOP practices.


2

What composition over inheritance really has to say here is that it would have been nice if JButton has been designed with composition polymorphism so your CutomButton method could have been passed into it. It wasn't. If the client needs access to everything JButton provides (dubious) you now have to create a bunch of boilerplate delegation methods if you ...


1

I don't see that it matters. All the processing is internal / private to the foo class. It's one massive side-effect anyway; the constructor is setting Foo object state. If Foo cannot trust itself then what's to do? Don't hold state and re-calculate all the fx objects every time? Nonetheless I like the 1st option not because of side-effect management but ...


1

The way I interpret your idea: You have about 200 strings that you want to search for in your target .txt Find any of these given strings Give the user(?) som kind of feedback Replace it with some other string Both strings returned in step 2 and 3 are mapped to the exact content of the string found in step 1, i.e: 'a' found -> print 'a_feedback', ...


1

Your quote is still true today: Dealing with large numbers of interrelated types while still preserving modularity in the design of large systems is very difficult, and is an area of much current research. Programming very large object oriented systems -- thus with more and more interrelated classes and dependencies -- caused mainstream language ...



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