Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One of the Best Bits of Programming Advice I ever Got

objology.blogspot.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: One of the Best Bits of Programming Advice I ever Got

#81

Post by 5hoom »

Meh.

I'm working on a video game at the moment, and have read lots of advice like this. My old game engine experiments all used 'Entities' to describe objects in the game world, and these 'Entities' were created, deleted and invoked by an 'EntityManager' (kind of half factory & half controller). Every game tick, the EntityManager calls a 'tick' method on all the current game entities and facilitates communication between them. For the most part, all entities are created/destroyed at the same time (game-level loading/unloading).

Trying to avoid architecture mistakes, I've come up with all sorts of tortured designs to do away with the concept of any kind of 'manager'. It is probably my inexperience with various design patterns, but all these alternatives were overly complicated and difficult to use. I would end up with a mess of objects & functors all needing pointers to each other & stepping on each others toes.

It then occurred to me that my 'manager' was in fact mapped to the real-world concept of 'a manager', being someone/something that is given orders from upper-management (game-level data, user-input, etc.) 'hires' & then assigns tasks to 'workers', hands the results to upper management, then 'fires' the workers when they are not needed ;). The metaphor works.

So I'm back to the 'manager' pattern and things are moving ahead quite nicely, even if some OO purists might frown. Should I call my 'EntityManager' 'EntityBoss'? Gets rid of the 'er' at least...

Re: One of the Best Bits of Programming Advice I ever Got

#82

Post by kscaldef »

glhaynes wrote: post #65
pgroves wrote: post #30

Earlier quoted context omitted.

Agreed. The reason I end up with some '-er' classes is to separate out immutable definitions and the classes that work on the definitions. In your example, by making the FlowchartShape a simple definition class, you can then write that to a file or send it over the network as a snapshot of the state of the -er classes. If the article's advice was taken, you'd end up renaming WebServer to be WebPage, but then would ha…

It doesn't seem like it'd be any more difficult to write the FlowchartShape to a file or send it across the network if it had additional methods on it to manipulate and use its state, so I'm not sure what's gained by making two+ separate classes... what am I missing?

    what am I missing?
That it's quite possible that you don't want the guy on the other side of the wire to call those methods on the object. I find I quite frequently want to share a data model between my client and server code, but I certainly wouldn't want to expose all the stuff that the server does to those objects to the client directly.

Re: One of the Best Bits of Programming Advice I ever Got

#83

Post by chipsy »

5hoom wrote: post #81

Meh. I'm working on a video game at the moment, and have read lots of advice like this. My old game engine experiments all used 'Entities' to describe objects in the game world, and these 'Entities' were created, deleted and invoked by an 'EntityManager' (kind of half factory & half controller). Every game tick, the EntityManager calls a 'tick' method on all the current game entities and facilitates communication bet…

Similarly, my game has Managers for entities, collision components, and renderable components. With each one of these, I don't want to try to dump all of the data in one place where the access patterns become strained, I want them to be "managed" from afar, where there's an interface to easily query or update them.

Re: One of the Best Bits of Programming Advice I ever Got

#84

Post by glhaynes »

kscaldef wrote: post #82
glhaynes wrote: post #65

Earlier quoted context omitted.

It doesn't seem like it'd be any more difficult to write the FlowchartShape to a file or send it across the network if it had additional methods on it to manipulate and use its state, so I'm not sure what's gained by making two+ separate classes... what am I missing?

what am I missing? That it's quite possible that you don't want the guy on the other side of the wire to call those methods on the object. I find I quite frequently want to share a data model between my client and server code, but I certainly wouldn't want to expose all the stuff that the server does to those objects to the client directly.

In my experience, it seems like the vast majority of the time in which that would be the case, one isn't doing a native ("binary") object serialization such as would require the receiver to have the object code for the serialized class(es), but instead using some sort of intermediate format like JSON or XML or the like. But I suppose there might be instances... I just hate to throw away such a fundamental OOP concept as bundling of data and the methods that operate on that data unless there's a really good reason.

Re: One of the Best Bits of Programming Advice I ever Got

#85

Post by vl »

mcherm wrote: post #15

I am unconvinced. Any absolute deserves close scrutiny, and "real nouns only" is an absolute. In this case, it fails my test. I find that many things I work with (especially huge Java libraries) tend to have convoluted and difficult-to-understand webs of classes with the most confusing pieces named things like "FooManager" or "FooController". So the author of this piece is reacting to a genuine excess. But Travis is…

>The REAL goal is to find a collection of abstractions that is powerful enough to accomplish what the program requires but as simple as possible (and as local as possible) to allow humans to comprehend (and maintain) it.

I like to think that practicing OOP in some sense is a process of defining new language and then using this language to programs something. This can be said about almost any programming in general, but in OOP you can see bad abstractions very well.

The real problem of OOP is that most "average" programmers are bad at defining languages. From my unscientific observations in any large C++ project only few developers actually produce usable class hierarchies. Same applies to large Java projects to somewhat lesser degree - Java has better defined patterns and more extensive standard library.

Re: One of the Best Bits of Programming Advice I ever Got

#86

Post by 5hoom »

chipsy wrote: post #83
5hoom wrote: post #81

Meh. I'm working on a video game at the moment, and have read lots of advice like this. My old game engine experiments all used 'Entities' to describe objects in the game world, and these 'Entities' were created, deleted and invoked by an 'EntityManager' (kind of half factory & half controller). Every game tick, the EntityManager calls a 'tick' method on all the current game entities and facilitates communication bet…

Similarly, my game has Managers for entities, collision components, and renderable components. With each one of these, I don't want to try to dump all of the data in one place where the access patterns become strained, I want them to be "managed" from afar, where there's an interface to easily query or update them.

Yeah, from my own experience the 'manager' metaphor is just easier for understanding the flow of execution & adding-new-features/maintenance.

Everything is in one place, and when the systems do need to communicate it is usually in pretty well defined ways (eg. physics manager ticks--> passes collision data to entity manager which ticks--> passes scene data to render manager which draws the screen, etc)

I'll go with whatever pattern works best in the name of Just Getting Stuff Done (with my own limited brainpower).

Re: One of the Best Bits of Programming Advice I ever Got

#87

Post by microtonal »

cousin_it wrote: post #71
microtonal wrote: post #50

Earlier quoted context omitted.

This doesn't look like good UI code to me. It replaces a mutable counter (that could potentially be changed anywhere in the program) by a definition of the counter that describes all possible changes it can have during its lifetime: counter = accumD 0 $ ((+1) So, we have a counter that has an initial value of one. Over time, 1 can be added and 1 can be subtracted, namely when repsectively an eup or edown event occurs…

> Being able to capture all possible 'state mutations' of a value in one assignment is good. I think there's a duality here. If there are 20 buttons, each of which can affect some of 30 counters, then the Haskell code would say "this counter is affected by these buttons", while imperative/OO code would say "this button affects these counters". It's not obvious to me that the former way of organizing code is better.

You are still missing the point. In imperative programming there is no guarantee that the counter isn't modified in some place else or wrongly. In the end it's just an integer that allows all kinds of mutations.

The possible value changes in the Haskell FRP example, on the other hand, are completely described. There is no other manner in which the value can change.

Re: One of the Best Bits of Programming Advice I ever Got

#88

Post by Nick_C »

MartinCron wrote: post #66
pestaa wrote: post #41

Earlier quoted context omitted.

Is there a collection of suggestions from Stephen King? I love picking up small pieces of advice from respectable writers, and he is undoubtedly one of them.

Someone else mentioned Stephen King's (enjoyable) book. If you're after more "small bits of advice from respectable writers" you should look into Lawrence Block's books, specifically "Telling Lies for Fun and Profit" which I keep coming back to whenever I'm stuck.

> Lawrence Block

My favourite crime author, by a long way. Who else can write about a killer and make him a sympathetic character.

Re: One of the Best Bits of Programming Advice I ever Got

#89

Post by thesz »

j2labs wrote: post #32
Kototama wrote: post #5

Even better: don't use objects at all. Use a functional programming language.

Functional programming and objects are not orthogonal as you suggest.

Yes, they pretty opposite.

Objects should have identity and can be distinguished by identity alone. They are not referentially transparent because of that. In "x = new O(); f(x,x)" you cannot substitute "new O()" into both occurrences of x.

Functional values do not have identity and you cannot tell apart 2 and 1+1. Functional values are referentially transparent. In "x = 1; y = x+x" you can change x to 1 in the definition of y.

Re: One of the Best Bits of Programming Advice I ever Got

#90

Post by MartinCron »

Nick_C wrote: post #88
MartinCron wrote: post #66

Earlier quoted context omitted.

Someone else mentioned Stephen King's (enjoyable) book. If you're after more "small bits of advice from respectable writers" you should look into Lawrence Block's books, specifically "Telling Lies for Fun and Profit" which I keep coming back to whenever I'm stuck.

> Lawrence Block My favourite crime author, by a long way. Who else can write about a killer and make him a sympathetic character.

Who else can write about a killer and make him a sympathetic character.

That's easy, Donald Westlake writing as Richard Stark. Though Block is probably my favorite crime author as well.

Post reply on HN