Search Results

Search found 5 results on 1 pages for 'vorac'.

Page 1/1 | 1 

• Public versus private inheritance when some of the parent's methods need to be exposed?

  - by Vorac

  Public inheritance means that all fields from the base class retain their declared visibility, while private means that they are forced to 'private' within the derived class's scope. What should be done if some of the parent's members (say, methods) need to be publicly exposed? I can think of two solution. Public inheritance somewhat breaks encapsulation. Furthermore, when you need to find out where is the method foo() defined, one needs to look at a chain of base classes. Private inheritance solves these problems, but introduces burden to write wrappers (more text). Which might be a good thing in the line of verbosity, but makes changes of interfaces incredibly cumbersome. What considerations am I missing? What constraints on the type of project are important? How to choose between the two (I am not even mentioning 'protected')? Note that I am targeting non-virtual methods. There isn't such a discussion for virtual methods (or is there).

  Read the article

• Who owns the code, who owns the algorithm, who owns the idea?

  - by Vorac

  This question got me thinking what products of the programming effort belong to the employer, and what don't. The two extremes are (0) the code - it apparently belongs to the employer and (1) the learned personal and technical skills. But what is in between? Who owns the pseudocode/algorithm? Who owns the general idea of the algorithm? Who owns the know-how that such an algorithm may serve some useful purpose (e.g. on this site questions are values, as well as answers)? Also: Who owns an idea on the web?

  Read the article

• Factory for arrays of objects in python

  - by Vorac

  Ok, the title might be a little misleading. I have a Window class that draws widgets inside itself in the constructor. The widgets are all of the same type. So I pass a list of dictionaries, which contain the parameters for each widget. This works quite nicely, but I am worried that the interface to callers is obfuscated. That is, in order to use Window, one has to study the class, construct a correct list of dictionaries, and then call the constructor with only one parameter - widgets_params. Is this good or bad design? What alternatives does the python syntax provide?

  Read the article

• Interface design where functions need to be called in a specific sequence

  - by Vorac

  The task is to configure a piece of hardware within the device, according to some input specification. This should be achieved as follows: 1) Collect the configuration information. This can happen at different times and places. For example, module A and module B can both request (at different times) some resources from my module. Those 'resources' are actually what the configuration is. 2) After it is clear that no more requests are going to be realized, a startup command, giving a summary of the requested resources, needs to be sent to the hardware. 3) Only after that, can (and must) detailed configuration of said resources be done. 4) Also, only after 2), can (and must) routing of selected resources to the declared callers be done. A common cause for bugs, even for me, who wrote the thing, is mistaking this order. What naming conventions, designs or mechanisms can I employ to make the interface usable by someone who sees the code for the first time?

  Read the article

• How to design an interface, where things need to be called in a specific sequence?

  - by Vorac

  The task is to configure a piece of hardware within the device, according to some input specification. This should be achieved as follows: 1) Collect the configuration information. This can happen at different times and places. For example, module A and module B can both request (at different times) some resources from my module. Those 'resources' are actually what the configuration is. 2) After it is clear that no more requests are going to be realized, a startup command, giving a summary of the requested resources, needs to be sent to the hardware. 3) Only after that, can (and must) detailed configuration of said resources be done. 4) Also, only after 2), can (and must) routing of selected resources to the declared callers be done. A common cause for bugs, even for me, who wrote the thing, is mistaking this order. What naming conventions, designs or mechanisms can I employ to make the interface usable by someone who sees the code for the first time?

  Read the article

1